Subvocal: hablarle a la computadora sin hacer ruido

¿Alguna vez intentaste dictar un commit en la oficina y te rendiste porque el compañero de al lado iba a escuchar "fix: corrige un bug tonto que yo mismo creé"? Subvocal quiere acabar con esa vergüenza. Apareció en un Show HN con una promesa simple: hablarle a la computadora sin hacer ruido.

La idea toca una frustración vieja. El dictado por voz funciona bien desde hace años, pero casi nadie lo usa en el trabajo. El motivo no es técnico. Es social.

¿Qué es Subvocal, al final?

La propuesta es controlar la máquina con el habla subvocal. Es ese habla que "casi" haces: mueves la boca, la lengua y la garganta, pero no sale sonido. Todo el mundo lo hace sin darse cuenta cuando lee con atención.

El concepto no es nuevo. El MIT mostró AlterEgo en 2018, un aparato que leía las señales eléctricas de los músculos de la cara para reconocer palabras dichas en silencio. La NASA estudió algo parecido en los años 2000. Lo que cambió desde entonces fue el resto de la pila: los modelos de reconocimiento se volvieron baratos, corren en local y entienden el contexto mucho mejor.

Un aviso honesto: no probé Subvocal en mi máquina. Lo que escribo aquí es sobre la propuesta, el tipo de pipeline que exige un proyecto así y lo que yo haría para validar la idea antes de confiar en ella. Si quieres los detalles de hardware y precisión, el hilo original es el lugar indicado.

Por qué una interfaz silenciosa le importa a un dev

Piensa en tu día. ¿Cuántas veces dejas lo que estás haciendo para:

• abrir una terminal y correr el mismo comando de siempre;
• cambiar de branch;
• pedirle algo al asistente de código;
• buscar un archivo por su nombre.

Cada una de esas acciones cuesta unos pocos segundos. El problema es el cambio de contexto. Quitar la mano del código para hacer clic en algo rompe el razonamiento.

La voz resolvería parte de esto, si no fuera por tres cosas: el ruido del ambiente, la privacidad y la incomodidad de hablar solo en el open space. El habla silenciosa ataca las tres de una vez. Sigues escribiendo y, en paralelo, "dices" un comando corto.

El cuello de botella del dictado nunca fue el modelo. Fue el compañero del escritorio de al lado.

Ahora, la parte que poca gente comenta: con los agentes de código volviéndose rutina, el volumen de texto que le mandamos a la máquina en lenguaje natural explotó. Un prompt es texto largo. Escribir prompts es aburrido. Una entrada que no exige teclado ni voz alta encaja perfecto en ese flujo.

Dónde entra Bun en esta historia

Las herramientas como esta siempre tienen la misma arquitectura por debajo. Un sensor o un modelo genera texto. Algo recibe ese texto y lo convierte en una acción en el sistema. Esa segunda parte es pegamento, y el pegamento es justo donde Bun brilla.

¿Por qué? Porque tienes servidor HTTP, WebSocket, ejecución de procesos y lectura de archivos en el runtime, sin instalar nada. Arranca en milisegundos. Para un daemon que se queda corriendo todo el día esperando comandos, eso marca la diferencia.

Un prototipo del "lado de la acción" cabe en pocas líneas:

// daemon.ts: recibe el texto reconocido y dispara acciones
const comandos: Record<string, string[]> = {
  "status": ["git", "status", "--short"],
  "tests": ["bun", "test"],
  "main": ["git", "switch", "main"],
};

Bun.serve({
  port: 4321,
  hostname: "127.0.0.1",
  fetch(req, server) {
    if (server.upgrade(req)) return;
    return new Response("aquí solo WebSocket", { status: 400 });
  },
  websocket: {
    async message(ws, msg) {
      const texto = String(msg).trim().toLowerCase();
      const cmd = comandos[texto];
      if (!cmd) return ws.send(`no entendí: ${texto}`);

      const proc = Bun.spawn(cmd, { stdout: "pipe" });
      ws.send(await new Response(proc.stdout).text());
    },
  },
});

Fíjate en dos decisiones. Primero, el servidor escucha solo en 127.0.0.1. Un daemon que ejecuta comandos en tu shell no puede quedar expuesto en la red, ni por accidente. Segundo, los comandos están en una lista cerrada. Nada de tomar el texto reconocido y tirarlo directo en un sh -c. El reconocimiento se va a equivocar, y no quieres que "correr tests" se convierta en "rm" por un músculo mal leído.

Los problemas que nadie resuelve con un post bonito

Me gusta la idea. Pero tengo suficiente experiencia con demos de Show HN para saber dónde suelen romperse.

Precisión. El reconocimiento de voz con sonido ya falla en ambientes ruidosos. Sin sonido, la señal es mucho más pobre. Una tasa de error del 5% parece buena en el papel. En la práctica, significa fallar un comando de cada veinte. Si el comando es "abrir archivo", no pasa nada. Si es "hacer push", sí.

Vocabulario. Los sistemas así suelen ir muy bien con un conjunto pequeño de palabras y empeorar rápido con texto libre. Para comandos cortos, funciona. Para dictar un prompt de tres párrafos, yo desconfiaría hasta ver números de verdad.

Calibración. Cada persona mueve la boca a su manera. Si la herramienta exige entrenamiento por usuario, la fricción de entrada sube. Vale la pena ver cuánto tarda hasta ser usable.

Privacidad. Si la señal sale de tu máquina hacia una API, estás enviando, literalmente, lo que pensaste decir. Yo solo usaría algo así con inferencia local. Punto.

La buena noticia es que buena parte de esto se mitiga con diseño, no con un modelo mejor. Un patrón que yo usaría:

// confirmación para acciones con efectos secundarios
const peligrosos = new Set(["push", "deploy", "reset"]);

function requiereConfirmacion(texto: string) {
  return [...peligrosos].some((p) => texto.includes(p));
}

Un comando seguro se ejecuta directo. Un comando peligroso pide un "sí" en el teclado. Simple, aburrido y eficaz.

Cómo evaluar Subvocal (o cualquier herramienta parecida)

Si quieres probarlo, te sugiero un plan rápido en lugar de emocionarte con el video de demostración:

1. Elige 10 comandos reales de tu día. No los de la demo, los tuyos.
2. Repite cada uno 10 veces en condiciones normales: sentado, cansado, después del almuerzo.
3. Anota aciertos y latencia. Si pasa más de medio segundo entre "hablar" y que la acción ocurra, vas a volver al teclado.
4. Prueba el falso positivo. Pasa 15 minutos leyendo documentación en silencio. ¿La herramienta disparó algo sola? Esta es la prueba que más importa, porque subvocalizamos todo el tiempo sin querer.

Este último punto es mi mayor temor con toda la categoría. Leer código es subvocalizar. Si el sistema no sabe diferenciar "estoy leyendo" de "estoy dando un comando", se va a convertir en un asistente que se mete en el momento equivocado. Una palabra de activación o un atajo de teclado para "ahora te estoy hablando a ti" lo resuelve, y yo desconfiaría de cualquier proyecto que no tenga algo así.

Qué cambia en tu flujo de trabajo

Hoy, casi nada. Siendo realistas, las interfaces silenciosas todavía están en la fase de prototipo emocionante. No van a reemplazar al teclado pronto. El teclado es rápido, preciso y no necesita calibración.

Lo que cambia es la dirección. Pasamos décadas con dos entradas: teclado y mouse. La voz se volvió la tercera, pero quedó atrapada en el auto y en la cocina. Una entrada silenciosa podría ser la primera que funcione dentro de la oficina, junto al teclado, y no en su lugar.

Y para quien escribe herramientas, la lección es otra. La parte difícil (el modelo, el sensor) va a estar cada vez más tercerizada. El valor va a estar en la capa de integración: qué comandos existen, cómo confirmar acciones peligrosas, cómo evitar falsos positivos. Eso es código de aplicación común, del que escribimos todos los días en TypeScript.

Mi opinión: la idea es buena y el momento es el correcto, pero solo la tomaré en serio cuando aparezca alguien usándola ocho horas al día sin apagarla al tercer día. Hasta entonces, voy a jugar con un daemon en Bun y una lista de cinco comandos, que es como empieza toda buena herramienta. Si te gusta este tipo de experimento, échale un vistazo a lo que estoy construyendo en mis proyectos.

El dictado por voz nunca prendió en la oficina, y el motivo no fue técnico: fue el compañero del escritorio de al lado.

Subvocal apareció en Hacker News con una propuesta atrevida: controlar la computadora moviendo la boca y la garganta, sin soltar ningún sonido.

Con los agentes de código volviéndose rutina, nunca escribimos tantos prompts. Una entrada que no exige teclado ni voz alta encaja perfecto en ese flujo.

Pero mi mayor temor es otro: leer código ya es subvocalizar. Sin una palabra de activación, la herramienta se convierte en un asistente que se mete en el momento equivocado.

Por eso yo la validaría con 10 comandos reales, inferencia local y confirmación en el teclado para cualquier cosa peligrosa, como un push o un deploy.

Escribí en el blog cómo armaría el daemon en Bun que se encarga de la acción. ¿Usarías una interfaz silenciosa en el trabajo?

#DesarrolloDeSoftware #InteligenciaArtificial #Bun #TypeScript #DevTools