Un asistente de voz local para trabajar con Codex

Este es uno de los proyectos que estan sobre la mesa en Dani En Remoto: un asistente de voz local que permite hablarle de forma natural a un agente de codigo mientras trabaja dentro de una carpeta real.

La idea no es venderlo como producto ni prometer una plataforma nueva. La idea es mostrar una prueba concreta: que pasa cuando una instruccion dictada se convierte en trabajo real dentro del proyecto, con archivos, verificaciones y un resumen que se puede escuchar sin perder el hilo.

Tambien esta cerca del puente hacia AUTOMATED & CO, porque toca las mismas preguntas: sistemas mas claros, automatizacion practica y flujos que ayudan a mover trabajo real. Pero el experimento vive aqui, como parte del diario publico de Dani En Remoto.

Que hace hoy

La version actual ya sostiene un ciclo simple:

• la persona dicta una instruccion,
• el wrapper local captura la voz y la convierte en texto,
• el agente trabaja dentro de la carpeta activa del proyecto,
• puede revisar archivos, cambiar codigo y correr verificaciones,
• y al final devuelve una respuesta corta para escuchar.

Ese ultimo punto parece pequeno, pero cambia mucho la experiencia. Cuando el sistema habla, no conviene que lea una ruta completa de Windows, un bloque largo de terminal o una lista interminable de detalles internos. Para eso agregamos una capa que limpia la respuesta hablada.

El flujo del modelo

El modelo principal recibe la instruccion dictada, entiende el objetivo y decide que trabajo hace falta dentro del proyecto. Puede leer contexto, razonar sobre los archivos, aplicar cambios y resumir el resultado.

Alrededor de ese modelo hay capas locales que hacen mas comoda la interaccion:

• captura de voz para la entrada,
• ejecucion atada a la carpeta del proyecto,
• sanitizacion de respuesta para la salida hablada,
• y un registro escrito donde los detalles completos siguen disponibles.

Esa separacion importa. El modelo se concentra en hacer el trabajo. El wrapper se encarga de que hablar con el sistema no sea incomodo.

Por que importa el sanitizador

Una respuesta escrita puede permitirse mas ruido tecnico. Una respuesta hablada no.

Si el agente cambia un archivo con una ruta profunda, la version completa puede quedar en el transcript. Pero la voz puede decir solamente el nombre del archivo y el resultado importante. Asi el resumen se mantiene humano: que cambio, que se verifico y que queda pendiente.

Es una decision pequena de producto, pero es justo el tipo de detalle que decide si una herramienta se siente util en la practica o si solo funciona en una demo.

Lo que estamos aprendiendo

El valor no esta solo en hablar en vez de escribir. El valor esta en cerrar mejor el ciclo:

1. pensar en voz alta,
2. convertir eso en una instruccion util,
3. dejar que el agente haga trabajo concreto,
4. verificar lo que cambio,
5. y escuchar un estado corto para seguir avanzando.

Para trabajo remoto y proyectos propios, ese ritmo puede ser muy potente. Permite mantener la energia de una conversacion sin soltar la precision de un proyecto editable.

Lo que sigue

Por ahora la prioridad es seguir probandolo en tareas reales de Dani En Remoto: publicaciones, pequenas mejoras de sitio, flujos internos y revisiones de proceso.

Las siguientes mejoras deberian concentrarse en cosas practicas:

• resumenes hablados mas consistentes despues de tareas largas,
• mejor manejo de interrupciones,
• instrucciones mas claras cuando el usuario dicta de forma incompleta,
• y una ruta mas ordenada para pasar de una nota de proyecto a contenido publico, social y CRM.

Esta publicacion es parte de esa correccion de proceso: primero la historia entra al sitio de Dani En Remoto, despues se convierte en campana o contenido derivado.