Flujos de dictado por voz: 8 flujos infravalorados para el trabajo diario con IA

La mayoría de la gente prueba el dictado por voz dictando un párrafo. Eso lo subestima. Los flujos de dictado por voz de mayor palanca son los pequeños artefactos repetidos que se sitúan entre pensar y enviar: mensajes de commit, descripciones de issues, respuestas de soporte y notas de handoff. Para la productividad por voz de un developer, la victoria está en convertir una intención rugosa en un artefacto útil sin perder contexto.

Tabla de flujos

Los 8 flujos

1. 1. Voz → mensaje de commit en git

   Di la intención, no la redacción final. Loqua convierte "fixed the privacy toggle focus issue and added regression test" en un sujeto de commit imperativo. Combínalo con las convenciones de commit de Git y tu historial queda más limpio.

   Un hábito útil: echa un vistazo al diff staged primero y dicta el sujeto antes de abrir el editor. El diff ancla la intención, y la versión hablada suele salir más directa que una tecleada. Añadimos un body corto cuando el cambio merece contexto; una o dos frases habladas bastan.

2. 2. Voz → descripción de PR

   Di qué cambió, por qué y cómo lo probaste. Loqua escribe secciones de summary, changes, validation y risk. Es más rápido que mirar fijamente un cuadro de texto vacío de GitHub.

   La estructura que nos funciona: un summary de una línea, una lista corta de cambios con bullets, un párrafo de validation que nombre los comandos que realmente ejecutamos y una nota de risk que le diga al revisor dónde mirar con más cuidado. La voz hace más fácil ser honesto en el párrafo de risk; teclearlo se siente más pesado que decirlo.

3. 3. Voz → issue de Linear

   Dicta reproducción, resultado real, resultado esperado y criterios de aceptación. La estructura fuerza reportes de bug más claros y evita el típico ticket "fix thing broken".

   Tenemos un pequeño contrato interno en el equipo: cada issue de Linear hablada debe terminar en los criterios de aceptación, aunque sean laxos. Si no puedes decir "done looks like…" antes de parar, la issue no está lista. La voz tiende a saltarse ese paso a menos que se imponga el hábito; una vez impuesto, la calidad de los tickets sube de forma visible durante la planificación.

4. 4. Voz → respuesta a cliente

   Di la versión interna y directa; deja que Loqua limpie el tono para Slack, Spark o Front. Es útil cuando la respuesta es simple pero quieres que suene considerada.

   Un patrón que usamos: dicta la respuesta dos veces. Una como se la dirías a un compañero, y otra con un comienzo más cálido. La segunda pasada suelen ser dos frases y casi no cuesta tiempo. El mensaje resultante es más amable de lo que habría sido una respuesta tecleada, porque teclear tiende a derivar hacia la concisión seca.

5. 5. Voz → árbol de brainstorm

   En Obsidian o Notion, dicta las ramas en voz alta. La voz es buena para el pensamiento divergente porque puedes mantener el impulso sin pararte a indentar cada bullet.

   El truco es decir la estructura sobre la marcha: "top branch users, sub branch first time, sub branch returning, top branch tools, sub branch capture, sub branch routing." Loqua mantiene la indentación; tú mantienes el flujo. Editar el árbol después con atajos de teclado es mucho más rápido que partir de un canvas en blanco.

6. 6. Voz → borrador de spec

   Di las secciones: goal, non-goals, flujo de usuario, casos límite, aceptación. Loqua mantiene los bloques H2 y los bullets, lo que hace que el resultado sea revisable por compañeros o por un agente.

   Tratamos el primer borrador hablado como un andamio, no como la spec final. Lo más rápido es dictar cada sección en orden, aunque algunas secciones se lean como notas, y luego volver con el teclado para profundizar en las que más importan. La estructura hace obvio dónde están las secciones más flojas.

7. 7. Voz → comentario de código y docstring

   Apunta el cursor a una función y explica el comportamiento. Loqua preserva los identificadores visibles y formatea el resultado como un comentario o docstring en lugar de prosa genérica.

   El mejor momento para dictar un docstring es justo después de terminar la función, cuando el diseño aún está en tu cabeza. Decirlo te obliga a describir el comportamiento en palabras, lo que a menudo saca a la luz el parámetro que aún no termina de cuadrar. Varios refactors en nuestro codebase empezaron como un docstring dictado que no quería escribirse.

8. 8. Voz → actualización de standup asíncrono

   Di qué cambió, qué está bloqueado y qué viene después. Loqua lo comprime en un hilo corto de Slack o una actualización de Linear en menos de 60 segundos.

   Una regla útil: mantén cada sección en una frase en la actualización hablada. Los standups se hinchan cuando se intenta capturar cada matiz. La voz con una plantilla apretada de tres frases se mantiene compacta y se lee; las actualizaciones largas se ojean y se olvidan.

Ejemplos por voz

Antipatrones a evitar

Algunos hábitos empeoran silenciosamente los flujos por voz. Primero, dictar sin nombrar el destino: el modelo tiene que adivinar el formato y el resultado es prosa genérica. Segundo, decir la versión pulida: pierdes la ventaja de velocidad y el resultado se lee rígido. Tercero, negarse a volver al teclado para ediciones exactas; la voz es excelente para el primer borrador y lenta para la corrección número dieciocho. Cuarto, dictar cada reacción de Slack; la voz es para mensajes con estructura, no para emojis y respuestas de una línea.

Reglas que hacen que la voz funcione

Los buenos ejemplos de flujo de trabajo por voz comparten tres reglas. Primero, nombra el destino antes de hablar: commit, PR, issue, respuesta, brainstorm, spec, comentario o standup. Segundo, di la intención en bruto en lugar del artefacto pulido. Tercero, deja que la herramienta estructure la salida y haz las ediciones exactas con atajos de teclado.

Las herramientas externas también importan. GitHub tiene campos de PR fuertes, Linear tiene estructura de issues y los hilos de Slack fomentan las actualizaciones concisas. La voz funciona cuando el formato de destino es estable.