Flujo de trabajo voice-first: un día en nuestra jornada voice-first

Soy Shuran, founder de Loqua.ai. Esta es la versión honesta de nuestro flujo de trabajo voice-first: dónde ahorra tiempo, dónde falla y qué hago en su lugar. El objetivo no es performar productividad. El objetivo es reducir la distancia entre un pensamiento y el artefacto que mueve el trabajo hacia delante. Al final de un día como este, la pregunta de teclear o hablar es prácticamente invisible; lo que noto es el trabajo en sí.

Bandeja de entrada a las 8am

Empiezo con Spark Mail y Slack. La voz funciona bien aquí porque las respuestas son sobre todo intención y tono. Dicto la respuesta rugosa, Loqua quita las muletillas y la capa consciente de la app mantiene la salida más corta en Slack que en el correo.

El bloque de bandeja de entrada suele llevarme entre quince y veinte minutos. Unas dos terceras partes de las respuestas se dictan; el resto las tecleo porque necesitan una redacción exacta, una lista de enlaces o una explicación delicada. La división no es una regla. Es en lo que acaba convirtiéndose la mañana cuando dejo de forzar una herramienta a hacer el trabajo de la otra.

Cuando falla la voz: hilos confidenciales en espacios públicos. Si estoy en una cafetería y el mensaje contiene contexto sensible, tecleo. Voice-first no significa privacidad en segundo plano.

Standup

Para el standup, digo tres huecos: shipped, today, blocker. Es uno de los patrones diarios de flujo de trabajo de dictado por voz con mayor retorno porque la estructura se repite y el contenido cambia.

El truco es no divagar. Digo los nombres de los huecos en voz alta. Loqua los usa como estructura. El propio standup tarda unos treinta segundos en escribirse y otro minuto en leer lo que ha publicado el resto del equipo. La voz no ahorra mucho tiempo en cada standup individual; lo que ahorra es el coste de posponerlo, que antes era el mayor lastre del día.

Revisión de código

La revisión de código es mixta. La voz es excelente para explicar la preocupación; el teclado es mejor para la precisión a nivel de línea. Dicto los resúmenes de revisión y los comentarios de alto nivel, y luego uso el ratón y el teclado para la navegación exacta por archivos.

Un buen comentario de revisión por voz dice por qué importa el problema, no solo qué línea está mal. Por ejemplo: "This cache key ignores locale, so Chinese and English results can collide. Can we include locale in the key and add a regression test?" Ese comentario es mucho más fácil de decir que de teclear mientras lees código.

Borrador de spec

Redactar specs es donde el flujo voice-first se siente más cerca de pensar. Dicto goal, non-goals, flujo de usuario, casos límite y criterios de aceptación. Luego edito los encabezados con el teclado. Para una spec más grande, empiezo en Obsidian; para tareas de implementación, paso la versión limpia a Claude Code o Cursor.

El primer borrador dictado rara vez es la spec que enviamos. Es el andamio que hace obvia la edición posterior con el teclado. El truco que reaprendo es que la versión dictada saca a la luz las secciones que faltan más rápido que un esquema tecleado, porque decir "acceptance" en voz alta me obliga a continuarlo con al menos un criterio.

Hilos de Slack

En Slack importa el tono. La voz puede sonar demasiado brusca si el modelo de limpieza solo transcribe. El formato según destino de Loqua mantiene las respuestas cortas pero no frías. Aun así leo antes de enviar; la voz debe acelerar el juicio, no reemplazarlo.

Un patrón que tardé en aprender: dicta la versión cálida, no la eficiente. Slack se lee mejor cuando la primera frase reconoce a la persona y la segunda va al grano. Una respuesta tecleada tiende a saltarse la primera frase. Una dictada normalmente la mantiene, y el hilo está más sano por ello.

Cuando falla la voz: cuando un hilo requiere citar con cuidado o varios enlaces. Eso lo tecleo. La regla híbrida es simple: usa la voz para el argumento, el teclado para las referencias.

Diario de final de día

Al final del día, dicto lo que me sorprendió. Esto no es una actualización de estado. Es captura de memoria: qué me hizo cambiar de opinión, qué fue más difícil de lo esperado y qué no debería olvidar mañana. El destino es Obsidian porque es buscable y enlazable.

Una entrada típica de diario son tres párrafos cortos y tarda unos cinco minutos. El patrón interesante es que las entradas más valiosas son sobre pequeñas sorpresas, no sobre grandes decisiones. Las grandes decisiones se escriben de todos modos, a menudo más de una vez. La pequeña sorpresa — la API que devolvió una forma distinta a la que sugería la doc, el comentario de usuario que contradijo mi modelo — es la que desaparece para la mañana si no se captura.

Cuando hoy la voz no funcionó

Dos ejemplos del mismo día. Primero, un refactor de código denso en un archivo cargado. Intenté dictar el plan de renombrado en el editor y el modelo seguía equivocándose con un identificador porque el contexto visible se desplazaba más rápido de lo que el listener podía alcanzar. Cambié a teclear. La voz era la herramienta equivocada porque el cursor se movía demasiado rápido para que el contexto se estabilizara.

Segundo, un hilo tenso en Slack donde la respuesta correcta eran tres frases y cero adjetivos. Dicté, la limpieza añadió un matiz cortés y el mensaje acabó leyéndose más suave de lo que yo quería. Lo reescribí a mano. La lección es que la voz es buena para la calidez y mala para la frialdad deliberada; cuando necesitas un mensaje plano, tecléalo.

Para detalles más amplios del stack, mira nuestro stack de productividad por voz. Para el argumento detrás del hábito, mira por qué tu teclado es la herramienta equivocada para pensar con IA. Las referencias externas que dieron forma a nuestro flujo de trabajo en Mac incluyen Apple Dictation y los documentos de Linear.