Programar por voz: código, revisiones y commits
«Programar por voz» suele sonar a circo. El vídeo de 2017 con un dev gritando «open paren if foo equals equals null close paren» es un meme, no un workflow. Yo también pensé mucho tiempo que esa idea estaba muerta.
Commander Flow me cambió la perspectiva. No porque haya añadido un modo mágico de «dictado de código». Sino porque el código no es solo código. El código son commits, tickets, code-review, documentación, comentarios, nombres, chats con compañeros. Y todo lo que rodea al código ahora lo hago por voz.
Dónde la voz cambia de verdad la vida del desarrollador
Mi operación por voz más habitual son los mensajes de commit. Pongo el cursor en git commit -m "...", mantengo la tecla y digo algo como «arregla race condition al cancelar el pipeline, cancelamos correctamente el token cuando se vuelve a pulsar el atajo», y en la terminal aterriza un mensaje listo según conventional commits, porque una vez le di las reglas por voz y se quedaron memorizadas.
Las descripciones de PR son casi igual, solo que más largas. Abro la plantilla de PR de GitHub y dicto como si se lo explicara a un junior: qué cambia, por qué, qué no se toca, cómo probarlo. Unos segundos después tengo un markdown ordenado con cabeceras ## Context, ## Changes, ## Test plan. Antes me llevaba unos cinco minutos; ahora, segundos.
Lo que más me ha cambiado son los comentarios de code-review. Antes me daba pereza escribir revisiones extensas: demasiado teclear para algo que se lee y se olvida. Ahora selecciono una línea, dicto la idea por voz y obtengo un comentario claro y pulido en un par de segundos. Mis revisiones son significativamente más largas y notablemente más útiles, y el equipo lo nota.
Aparte, la documentación. La parte más dolorosa de la profesión. Dicto el docstring como se lo contaría a un compañero y Commander Flow lo lleva al estilo XML-doc, TSDoc o markdown según el lenguaje del proyecto. La documentación dejó de ser un impuesto que pago al código.
«No escribo código por voz. Escribo todo lo que rodea al código por voz. Y descubrí que eso es la mitad de mi trabajo.»
El modo code-comments: una cosa aparte que me encanta
Por eso simplemente digo de viva voz «déjalo como comentario de código» — y Commander Flow:
- No toca los identificadores en latín (variable names, class names)
- Mantiene términos (kubectl, async/await, useEffect, OAuth) en su escritura original
- No añade fórmulas de cortesía (igualmente nadie escribe «estimados lectores» en los comentarios al código)
- Funciona bien con ambos alfabetos en un mismo comentario:
// comprobar que Subscription.IsActive antes de llamar a BillingService.Refresh
Suena a tontería. Pero sin esa indicación de voz, las primeras builds alfa a veces «ennoblecían» mi comentario técnico a un «comprobemos si nuestro objeto de negocio Subscription es correcto».
El diccionario de términos: una función infravalorada
En PolishOptions.Dictionary meto mis propios términos y siglas. Tengo allí:
kubectl,helm,argocd,fluxIDictionary,IAsyncEnumerable,Span<T>ConfigureAwait(false)(entero, como frase, para que el LLM no lo reescriba)- Siglas internas, nombres de servicios internos
Después de eso, el LLM deja de «mejorar» términos específicos y los deja exactamente como los he llamado.
El escenario que me convence cada día
10:30, estoy en el IDE, al lado el chat del equipo, al lado Linear con un ticket. Mantengo el atajo y digo:
«Saqué la lógica de retry a una clase aparte RetryPolicy con backoff exponencial, añadí tests, revisa también el sequence diagram en el ticket antes de hacer merge»
Eso se va a Linear como comentario al ticket. Después: Alt+Tab a Slack, mismo atajo:
«equipo, he subido el PR a revisión, no es bloqueante pero a poder ser hoy»
En estilo Slack, en minúscula, sin «estimados compañeros». Después, vuelta al IDE.
Tres acciones en tres aplicaciones, todo por voz, sin dedos.
Donde tropecé
Puntuación de código que cae en medio del dictado. Si dicto un bloque tipo «esta función devuelve Task<bool>», a veces el LLM «cree» que Task<bool> es HTML e intenta escaparlo. Resuelto añadiendo el término al diccionario, pero al principio sorprendía.
Conflictos de atajos con el IDE. Mi IDE tiene sus propios atajos. Tuve que reasignar un par de veces el de Commander Flow para que no chocara. Ahora lo tengo en Caps Lock, la tecla más cómoda y menos usada. Una pequeña incomodidad, resuelta con un clic en los ajustes.
Los modos más pesados pueden «pensar» un poco más lentos en el IDE. Para un correo, los milisegundos extra no se notan. Para un comentario al código «aquí y ahora» sí. Cambié al modo intermedio en el portátil de trabajo y dejé el más potente para el sobremesa con GPU dedicada. La latencia desapareció.
Lo que entendí sobre el sonido como interfaz de programación
La voz no reemplaza al teclado en el IDE. Lo complementa donde el teclado era la peor herramienta. Teclear if (x != null && y != null): teclado. Explicar por qué hace falta esa comprobación: voz.
Entre estas dos tareas hay un abismo de carga cognitiva, y no se «resuelven igual» con el teclado. Dejé de obligarme a teclear el segundo tipo. Y se nota.
Lo que saco de esta proporción
Programar por voz no es «dictar código». Es un cambio en qué exactamente haces por voz. La lógica la escribes con las manos; todo lo humano alrededor de la lógica, por voz.
En diez años de profesión no he encontrado una proporción más cómoda.
Pruébalo tú mismo
Descarga Commander Flow y mantén pulsado Caps Lock en cualquier aplicación. El reconocimiento se ejecuta localmente, sin nube — prueba gratuita incluida.
