Cómo usan Verity los desarrolladores: de los comentarios de código a la documentación técnica

Por qué dictan los desarrolladores

La mayor parte del trabajo de un desarrollador ya no consiste en escribir código carácter por carácter. Consiste en describirles a los agentes de IA lo que quieres, escribir contexto para quienes revisan, explicar la arquitectura a tu equipo y documentar decisiones. Todo eso es prosa — y dictar prosa es más rápido que escribirla.

El giro hacia el desarrollo asistido por IA lo ha hecho todavía más cierto. Si pasas el día hablando con Claude Code, Cursor o Copilot — describiendo bugs, pidiendo refactorizaciones, explicando requisitos — eso es entrada en lenguaje natural en grandes volúmenes. Dictar esas instrucciones multiplica de verdad tu velocidad (consulta nuestra guía de velocidad para la técnica), sobre todo cuando la capa de pulido con IA convierte tus ideas habladas en prompts claros y bien estructurados.

También hay un argumento de ergonomía. Las lesiones por esfuerzo repetitivo son comunes en la ingeniería de software, y el dictado por voz les quita la carga mecánica a tus muñecas y manos en las partes del trabajo con más redacción.

Cómo maneja Verity el vocabulario técnico

Las personas Minimal y Formal de Verity ya conservan bien los identificadores técnicos — una referencia a useState o tokio::spawn se queda tal como la dijiste, sin convertirse en “use state” o “Tokyo spawn”. La función de vocabulario personalizado te permite registrar de antemano términos propios de tu base de código — nombres de funciones internas, abreviaturas del proyecto, convenciones de nombres del equipo. Se agregan en Configuración → Vocabulario.

La persona Minimal funciona bien para el dictado técnico: aplica una limpieza ligera sin reescribir tus frases, lo que mantiene intacta la precisión técnica.

Dictarles a los agentes de programación con IA

Este es el flujo de trabajo de mayor valor. Herramientas como Claude Code, Cursor, Copilot y Windsurf son cada vez más la forma en que se escribe código — describes lo que quieres en lenguaje natural y el agente lo escribe. La entrada es prosa: “refactoriza el middleware de autenticación para usar rotación de JWT”, “agrega manejo de errores para la ruta de reconexión del WebSocket”, “explica por qué esta prueba es inestable”. Dictar esas instrucciones es muchísimo más rápido que escribirlas. La capa de pulido con IA convierte tus ideas habladas en prompts claros y bien estructurados, lo que mejora directamente la calidad del resultado del agente.

Aquí hay un efecto acumulativo. Mientras mejor sea tu prompt, menos rondas de corrección necesitas con el agente. Una instrucción dictada que pasa por el pulido sale más precisa que lo que la mayoría escribe bajo presión — oraciones completas, sin abreviaturas, términos técnicos conservados. Esa precisión le evita al agente tener que adivinar, y a ti te evita revisar código que no dio en el blanco.

Algunos ejemplos concretos de cómo se ve esto en la práctica:

• Reportes de bugs para agentes: “El flujo de inicio de sesión falla cuando el proveedor de OAuth devuelve un 302 sin encabezado location. El error aparece en auth/callback/route.ts en el paso de análisis de la redirección. Agrega una protección que regrese a la página de inicio de sesión con un parámetro de error en lugar de lanzar una excepción.” Dicho en diez segundos, pulido en una instrucción precisa con la que un agente puede actuar sin hacer preguntas adicionales.
• Cambios de arquitectura: “Mueve el limitador de tasa del API gateway a la capa de servicios para que cada endpoint pueda definir su propio umbral. La implementación actual usa una sola ventana deslizante para todas las rutas, lo que significa que una ráfaga de callbacks de webhooks puede dejar sin recursos a las solicitudes interactivas.” Este nivel de contexto — el porqué, no solo el qué — es natural de decir y tedioso de escribir.
• Comentarios de revisión de código: “Este diff cambia la lógica de reintentos de backoff exponencial a un intervalo fijo. Eso está bien para la ruta del health check, pero el manejador del webhook de pagos necesita backoff para no saturar a Stripe durante una caída. Separa la estrategia de reintentos según quién llama.” Puedes dictar tus comentarios mientras lees el diff y luego pegar la versión pulida como comentario de revisión.

El flujo de trabajo de “pensar en voz alta”

Hay un patrón de desarrollo que el dictado permite y el teclado no: pensar en voz alta como paso de diseño. Antes de tocar el código, explicas de palabra el enfoque — qué componentes intervienen, cómo es el flujo de datos, dónde están las partes complicadas. El texto pulido se convierte en un boceto de diseño que puedes pasarle directamente a un agente de IA o pegar en un documento de planificación.

Funciona porque hablar y pensar van a la misma velocidad. Cuando escribes un plan, la lentitud mecánica del teclado filtra tus ideas — te saltas detalles, abrevias, pierdes el hilo. Cuando lo dices, sale el razonamiento completo: casos límite que normalmente olvidarías mencionar, restricciones que dejarías implícitas, alternativas que descartarías sin registrarlas.

El resultado es un mejor trabajo del agente al primer intento, porque recibió el panorama completo en lugar de un boceto comprimido. Además, genera un artefacto natural — la transcripción pulida — que sirve como documentación de la decisión de diseño. Dos resultados de una sola acción.

Un ejemplo práctico: estás a punto de refactorizar el sistema de notificaciones. En lugar de escribir un documento de diseño desde cero, abres Verity, presionas el atajo y hablas noventa segundos: “Ahora mismo las notificaciones pasan por un solo canal — el correo. Necesitamos agregar push e in-app. El reto es que cada canal tiene distinta semántica de reintentos y distintos límites de tasa. Creo que deberíamos extraer una interfaz NotificationDispatcher con implementaciones por canal, enrutar todo por una cola de prioridad y dejar que cada canal maneje su propia política de reintentos. La ruta de migración es: agregar la interfaz, poner el correo detrás de ella y luego agregar push e in-app como nuevas implementaciones sin tocar a los llamadores existentes.” Eso sale de la capa de pulido como un párrafo limpio y legible — listo para pegar en un issue de GitHub, pasárselo a un agente o incluirlo en un ADR.

Alternar entre programar y comunicar

Una sesión de desarrollo típica alterna entre escribir código y escribir sobre el código. Implementas una funcionalidad y luego escribes el mensaje de commit. Corriges un bug y luego actualizas el gestor de issues. Revisas un PR y luego dejas comentarios. Las partes de código necesitan teclado. Las partes de comunicación necesitan prosa — y ahí es donde el dictado toma el control.

El atajo global hace que esta transición sea fluida. No cambias de aplicación, no abres una ventana de dictado aparte ni rompes tu concentración. Presiona el atajo en tu terminal para dictar un mensaje de commit. En tu navegador, para dictar un comentario de revisión de un PR. En Slack, para dictar una actualización de estado. El texto pulido aparece donde esté tu cursor, en la aplicación que ya estabas usando.

Esto es especialmente valioso en sesiones largas de depuración, en las que necesitas documentar qué intentaste, qué observaste y qué concluiste. Escribir esas notas mientras razonas sobre el problema implica un costo de cambio de contexto. Dictarlas no — solo narras lo que ya estás pensando.

Otros flujos de trabajo que funcionan bien

• Comentarios en el código: documentación en línea que explica el porqué, no el qué. Suelen ser de 1 a 3 oraciones y no requieren la misma precisión que el código en sí.
• Descripciones de PR: contexto para quienes revisan — qué cambió, por qué, qué revisar. Suelen ser la parte más tediosa del proceso de un PR y son prosa por naturaleza.
• Mensajes de commit: líneas de asunto y descripciones extendidas para git commit. Dictar el mensaje suele ser más rápido que escribirlo, sobre todo con el formato de Conventional Commits.
• Documentación técnica: secciones de README, páginas de wiki, registros de decisiones de arquitectura (ADR), runbooks. Mucho volumen de prosa, requisitos de precisión moderados.
• Correos técnicos y mensajes de Slack: mensajes más largos para dar contexto a tu equipo o a otras partes interesadas, que se benefician de redactarse de viva voz.

Linux, macOS y Windows

Verity funciona en Linux, macOS y Windows — las tres plataformas como objetivos de primera clase, no como ocurrencias tardías. Esto importa más en los flujos de trabajo de desarrollo que en la mayoría de los casos de uso, porque una parte importante de los desarrolladores trabaja en Linux, ya sea como sistema operativo principal o como entorno de desarrollo.

La mayoría de las herramientas de dictado no son compatibles con Linux en absoluto. El dictado integrado de cada plataforma se limita a su propio ecosistema, y la mayoría de las alternativas son de una sola plataforma. Históricamente, Linux ha sido ignorado por completo.

La inserción de texto en todo el sistema funciona en las tres plataformas — el dictado va directo a cualquier campo de texto, sin importar qué aplicación esté activa. No necesitas una extensión de navegador, un plugin especial para tu editor ni un área de entrada dedicada.

Privacidad para código propietario

Si dictas comentarios de código o documentación técnica, probablemente estás dictando información propietaria: nombres de APIs internas, decisiones de arquitectura, detalles de la lógica de negocio. La arquitectura de cero retención importa aquí de una forma muy concreta.

El audio se procesa en la propia infraestructura de Verity — no interviene ningún proveedor de IA externo. Ningún audio de tu sesión de dictado se almacena, se registra ni se usa para entrenar modelos. Los detalles de tu código propietario no persisten en ningún sistema una vez que termina la solicitud de transcripción.

Consulta nuestro artículo sobre la arquitectura de privacidad para el desglose técnico completo, o la página de funciones de privacidad para un resumen de la lista de encargados del tratamiento y los términos del DPA. El almacenamiento de transcripciones cifrado por usuario con AES-256-GCM significa que incluso el texto de tus transcripciones es inaccesible para Verity sin tu clave.