Voice Monkeys

Dictado por voz para programadores: habla la prosa, teclea el código

Actualizado:

Nadie en su sano juicio dicta un bucle for. Pero cualquier desarrollador escribe a diario mucho texto normal: el cuerpo de los commits, la descripción de un pull request, comentarios de revisión, tickets, notas de diseño y prompts largos para asistentes de código. Ese texto es justo donde el dictado por voz rinde. Esta guía separa lo que conviene decir de lo que conviene seguir tecleando, trae frases de ejemplo para cada caso y es franca sobre lo mal que lleva el reconocimiento de voz el texto técnico. Incluye además un problema muy de quien programa en español: pensar en español y escribir el commit en inglés.

Decirlo o teclearlo: una regla rápida

La regla práctica: si un compañero podría leerlo en voz alta sin deletrear nada, díctalo. Si lleva identificadores, sintaxis cargada de signos o cadenas exactas, tecléalo. Casi todo lo que escribes es una mezcla, así que dictas las frases y tecleas los pocos tokens que van dentro.

Tarea¿Dictar?Motivo
Cuerpo del commitSíDos o tres frases explicando el porqué, casi todo palabras normales
Asunto del commitA menudoEs corto; el nombre del archivo o de la función se teclea después
Comentario de code reviewSíExplicar una duda hablando es más rápido y suena más amable
README y guías internasSí, la parte de textoBloques de código, comandos y rutas, a mano
Prompt para un asistente de códigoSíCon contexto largo es donde más gana la voz
Nombres de variables y llamadasNocamelCase, guiones bajos y paréntesis salen mal
Comandos de shell, flags, regexNoUn carácter equivocado cambia el resultado
Rutas y URLNoBarras y puntos son pesados de decir y fáciles de colocar mal

Mensajes de commit dictados

Ejecuta git commit sin la opción -m para que se abra tu editor. Escribe la línea de asunto, o díctala y corrige los nombres, deja una línea en blanco y dicta el cuerpo. El cuerpo es lo que solemos saltarnos al teclear porque da pereza, y es precisamente lo que explica el cambio a quien haga git blame dentro de un año.

Un cuerpo que se dice en unos quince segundos: «El reintento se rendía tras el primer timeout porque el contador se reiniciaba dentro del catch punto. Muevo el reinicio antes del bucle y añado un test que simula dos timeouts seguidos punto». Si quieres, teclea luego el nombre del archivo de test.

Cada equipo tiene sus convenciones: muchos piden un asunto corto en imperativo (en inglés, algo como «Fix retry counter reset») y el cuerpo ajustado a cierto ancho. Al dictado le da igual el ancho; reformatea en el editor antes de guardar.

Español en la cabeza, inglés en el repositorio

En muchos equipos de habla hispana se habla en español en la daily y se escribe en inglés en GitHub. Para el dictado eso importa, porque el del sistema transcribe en el idioma que tenga activo. Si dictas un commit en inglés con el Mac en español, el resultado será una mezcla rara.

En el Mac, añade inglés con el botón Editar junto a Idiomas en Ajustes del Sistema > Teclado > Dictado, y cambia de idioma mientras dictas haciendo clic en la abreviatura que aparece junto al cursor o con la tecla del globo terráqueo. En Windows 11, la escritura por voz sigue el idioma de entrada, que cambias con la tecla Windows + barra espaciadora antes de pulsar Windows + H. Cambia antes de empezar la frase, no a mitad.

El caso más difícil es el mixto: una frase en español con términos en inglés, del tipo «el endpoint de pagos devuelve un 500 cuando el token caduca». Ahí conviene probar con frases reales tuyas, porque cada herramienta lo resuelve a su manera. En la guía de dictado en Mac tienes los pasos completos para configurar varios idiomas.

Comentarios de revisión que se leen bien

Los comentarios de revisión tecleados tienden a ser secos, y un comentario seco se lee como borde. Hablados salen más parecidos a lo que dirías en la mesa de al lado. Una estructura que funciona: qué has visto, por qué importa y qué propones.

Para dictar: «Esta consulta se ejecuta una vez por cada elemento de la lista coma así que una página con doscientos pedidos hace doscientas llamadas punto. Podríamos cargarlos de una vez y agrupar en memoria signo de interrogación. Si quieres lo vemos juntos punto». Revisa que salga el signo de apertura ¿, que no todos los sistemas ponen solos. Luego vuelve al comentario y pon a mano las comillas invertidas alrededor del nombre de la función.

Relee cada comentario antes de publicarlo. Un error de reconocimiento en una revisión es peor que en una nota privada, porque el autor tiene que adivinar qué querías decir.

Documentación, notas de diseño y tickets

La documentación es donde más tenemos que contar y menos ganas de teclearlo. Prueba este reparto: dicta la explicación por bloques («qué hace este servicio», «cómo levantarlo en local», «qué se rompe más a menudo») y teclea después cada comando, variable de entorno y bloque de código. Un primer borrador hablado en diez minutos y luego editado suele ganar a un README vacío que espera una tarde libre.

En tickets y reportes de bug, di los pasos para reproducirlo como frases numeradas: «Paso uno coma abre la página de ajustes punto. Paso dos coma cambia la zona horaria y guarda punto. Esperado coma que el panel se actualice punto. Resultado coma sigue mostrando la zona antigua punto». Ordenar la numeración te lleva segundos, y los detalles que al teclear te habrías saltado están ahí.

Prompts para asistentes de código

Los asistentes de código responden mejor con contexto: qué intentas hacer, qué has probado ya, qué no se puede tocar. Teclear todo eso es lento, así que mucha gente escribe una línea y recibe una respuesta genérica. Dicho en voz alta, lleva menos de un minuto.

Dicta el contexto con palabras normales y pega a mano el código o el mensaje de error: un stack trace se copia, nunca se lee en voz alta. Cómo estructurar un prompt hablado, y la trampa de la «nueva línea» que envía el mensaje a medias, lo explicamos en la guía para dictar prompts a ChatGPT y Claude.

Lo que el dictado hace mal (y los pocos apaños)

  • Identificadores. «get user by id» llega como cuatro palabras. En el Mac, la lista de Apple en español incluye «sin espacio activado» y «sin espacio desactivado» para juntar la frase siguiente, y «mayúsculas activadas» para poner en mayúscula las palabras principales. Combinarlo para sacar camelCase es más lento que teclear.
  • Símbolos en cantidad. Apple y Microsoft permiten decir «guion bajo», «barra invertida» o «llave de apertura». La lista en español de Windows 11 incluye incluso «comilla inversa» para el backtick. Para un símbolo suelto vale; para una línea de código es un suplicio.
  • Jerga y nombres de producto. Librerías, servicios internos y siglas son las palabras que más se oyen mal. Tecléalas, o dicta alrededor y rellena el hueco.
  • Exactitud. Una palabra mal oída en un comentario es una errata. Un carácter mal oído en un valor de configuración es un bug. No dictes nada que se vaya a ejecutar o a parsear.
  • Oficina abierta. Hablarle al equipo todo el día al lado de compañeros en videollamada molesta a todos. Pulsar para hablar y un micrófono de diadema ayudan; una sala tranquila ayuda más.

Las listas completas de comandos de puntuación y formato en español, para Mac y para Windows, están en cómo dictar signos de puntuación.

Configúralo para que no estorbe

Un desarrollador salta de app en app sin parar: editor, terminal, navegador, chat. La herramienta que uses debe escribir donde esté el cursor, en todas ellas, con un solo gesto. El dictado de macOS y la escritura por voz de Windows escriben en el cursor, aunque la de Windows necesita internet y la del Mac se apaga tras 30 segundos sin detectar voz. Para Windows tienes los detalles en la guía de dictado por voz en Windows 11.

Voice Monkeys es una opción dedicada pensada para ese gesto: mantienes pulsada la tecla Opción derecha en el Mac (Alt derecha en Windows y Linux), hablas, sueltas y el texto aparece en el cursor, también en una terminal o en el IDE. Un toque rápido lo deja escuchando hasta el siguiente toque y Esc cancela. Reconoce el idioma de oído, así que puedes pasar del español al inglés sin tocar ajustes. En un Mac con Apple Silicon el modelo corre en el propio equipo y el audio no sale de él; si tu empresa tiene normas sobre dónde puede ir el audio de trabajo, compruébalo con ellas. En Linux necesita una sesión X11, no Wayland. Puedes descargarlo y probarlo 7 días. Si escribes sobre todo prosa y casi nunca sales de un editor, quizá te baste con lo que trae el sistema. Para comparar más opciones, mira la comparativa de apps de dictado por voz.

Preguntas y respuestas

¿Se puede programar con dictado por voz?

Las herramientas de dictado generales escriben mal el código: identificadores, paréntesis y sintaxis exacta salen torcidos. Funcionan bien para el texto que rodea al código: cuerpos de commit, comentarios de revisión, documentación y prompts.

¿Cómo dicto un mensaje de commit?

Ejecuta git commit sin -m para que se abra el editor, escribe o dicta un asunto corto, deja una línea en blanco y dicta el cuerpo. Corrige a mano los nombres de archivos y funciones antes de guardar.

¿El dictado funciona en la terminal?

Las herramientas que escriben en el cursor, como el dictado del Mac, la escritura por voz de Windows o apps dedicadas como Voice Monkeys, escriben en la terminal igual que un teclado. No dictes comandos que vayas a ejecutar: tecléalos.

¿Cómo dicto símbolos como el guion bajo o los corchetes?

Di el nombre del símbolo, por ejemplo «guion bajo» o «abrir corchete». Apple y Microsoft publican listas en español; cambian un poco entre sistemas y entre España y México.

Hablo español pero escribo los commits en inglés. ¿Qué hago?

Con el dictado del sistema, cambia el idioma antes de cada frase: con el indicador junto al cursor en el Mac o con Windows + barra espaciadora en Windows. Algunas apps dedicadas reconocen el idioma de oído y no necesitan ese cambio.

Fuentes

Más guías