La voz para pensar con IA: por qué tu teclado es la herramienta equivocada

Yo pensaba que la voz era una interfaz de accesibilidad o una función de comodidad. Cambié de opinión después de usar herramientas de IA todos los días. El teclado es excelente para la precisión, pero es un mal instrumento para pensar con IA porque obliga a la idea a pasar por un canal estrecho demasiado pronto.

El cuello de botella del teclado

Una persona que teclea rápido puede alcanzar unas 70 palabras por minuto. El habla conversacional ronda más bien las 150 palabras por minuto, y el pensamiento interno puede ir más rápido que cualquiera de los dos. Los números exactos importan menos que la forma: el teclado te obliga a serializar el pensamiento en fragmentos pulidos antes de que la idea esté lista.

Ese es el cuello de botella del teclado. No es que teclear sea lento en un sentido absoluto. Es que teclear te empuja a editar mientras formas el pensamiento. Con la IA, esa compresión temprana suele eliminar la ambigüedad útil: la salvedad, la alternativa, eso de lo que no estás seguro pero que quieres que el modelo considere.

Lo noto sobre todo cuando estoy cansado. Al final del día, mis prompts tecleados se vuelven más cortos y el modelo se vuelve, en consecuencia, menos útil. Esa misma noche, dictar la misma intención en la misma herramienta produce una respuesta mejor porque la versión hablada aún lleva el contexto que habría editado a mano. El teclado no solo me ralentiza; me convierte en peor colaborador del modelo a partir de cierta hora.

La IA cambia la forma del prompt

Trabajar con un LLM se parece más a hacerle un briefing a un colaborador que a darle una orden. Los mejores prompts suelen incluir contexto, motivo, restricciones, ejemplos e incertidumbre. La voz hace mejores prompts para las herramientas de IA cuando el problema aún está difuso porque puedes hablar el contexto que lo rodea sin detenerte a hacerlo elegante.

Por eso importa la voz para pensar. Puedes decir: "I think the bug is in the cache key, but I'm not sure if the user locale is part of it, inspect that path first and tell me if I'm wrong." Tecleado, eso suele acabar como "check cache bug." El prompt más corto pierde el pensamiento.

La forma de un prompt es ahora parte del trabajo, no un preámbulo. Trata al prompt como el artefacto que estás produciendo, y la voz se convierte en la herramienta natural de autoría: preserva la estructura de cómo entiendes realmente el problema, incluyendo las partes de las que no estás seguro. Un modelo que recibe la forma a medio formar suele devolver una respuesta mejor que un modelo que recibe un comando seguro pero parcial.

Tres momentos que cambiaron mi opinión

El primero fue una sesión de debugging. Tecleé un prompt corto a un agente pidiéndole que inspeccionara una regresión. Se fue por el camino equivocado. Después dicté la versión desordenada: qué había cambiado, qué sospechaba, qué dudaba y qué refutaría mi teoría. El agente encontró el problema más rápido porque por fin le había dado la forma de mi incertidumbre.

El segundo fue escribir. Tecleé un párrafo nítido sobre nuestro stack de modelos y sonaba correcto pero muerto. Dije la misma idea en voz alta mientras paseaba, incluyendo la frustración que nos llevó a la arquitectura. La versión dictada tenía el argumento real. Aún la edité, pero edité desde un borrador vivo en lugar de un esquema estéril.

El tercero fue una respuesta larga e incómoda a un cliente. El cliente había hecho una pregunta sin respuesta limpia; la respuesta honesta implicaba tradeoffs y una pequeña disculpa. Tecleada, mi respuesta pasó por seis ediciones y aún se sentía rígida. Dictada, la primera toma fue más cálida, más directa y solo necesitó arreglar una palabra. Envié esa versión y la conversación avanzó. Ya no me fío de las respuestas tecleadas para mensajes que necesitan algo de tono.

Cómo uso la voz ahora

Uso la voz para pensar en primera pasada, no para la precisión final. Dicto el brief desordenado en Claude Code, Cursor, Obsidian o un archivo Markdown plano. Después paso al teclado para ediciones exactas. Esa división mantiene a cada herramienta en su carril: voz para contexto, teclado para cirugía.

• Antes de codear: dicto el cambio, el riesgo y la ruta de prueba. La versión dictada suele sacar a la luz un riesgo que me habría saltado si estuviera tecleando.
• Antes de escribir: digo el argumento en voz alta antes de hacer el esquema. Si no puedo decir el argumento en dos minutos, todavía no sé qué pienso.
• Antes de las reuniones: dicto la decisión que necesito de la llamada. Entrar a una reunión con una decisión nombrada cambia la conversación.
• Después de los fracasos: dicto lo que me sorprendió antes de que se borre el recuerdo. Para la mañana siguiente, la lección desaparece si no se capturó.

Para contexto externo sobre velocidad de habla y patrones de dictado, los escritos del Nielsen Norman Group sobre reconocimiento de voz y las referencias de palabras por minuto son buenos puntos de partida.

Las objeciones que sigo escuchando

"Trabajo en espacios compartidos." Justo, y es una restricción real. Mi respuesta es que incluso diez minutos tranquilos al día dictando los prompts difíciles es más útil que un día entero tecleándolos. La voz no necesita dominar el flujo de trabajo para cambiarlo.

"Puedo pensar mientras tecleo." Algunas personas realmente pueden. La prueba no es si puedes producir texto tecleando; es si el texto que produces tecleando tiene la misma forma que el pensamiento que habrías hablado. Para la mayoría de nosotros, incluido yo, la versión tecleada es sistemáticamente menos completa.

"Sueno divagante cuando dicto." La primera semana es dura. La segunda va mucho mejor. La habilidad que se aprende no es hablar; es dar forma a un pensamiento hablado para que un lector (o un modelo) pueda usarlo. Vuelve más rápido de lo esperado porque todos la han usado antes, solo que en conversación.

Dónde encaja Loqua

Escribimos Loqua porque yo quería voz para pensar sin aceptar la limpieza manual de la transcripción en bruto. Elimina los arranques en falso, mantiene los nombres técnicos y formatea la salida para la app en la que estoy. La propuesta suave es esta: usa Loqua cuando la idea sea demasiado grande o demasiado frágil para forzarla primero por el teclado.

Para la versión práctica de este argumento, mira nuestra jornada voice-first. Ese post muestra cuándo funciona la voz, cuándo falla y cuándo aún recurro al teclado. El sentido de este post es el porqué; ese otro es el cómo.