Subvocal: falar com o computador sem fazer barulho
Você já tentou ditar um commit no escritório e desistiu porque o colega do lado ia ouvir "fix: corrige bug idiota que eu mesmo criei"? O Subvocal quer acabar com essa vergonha. Ele apareceu num Show HN com uma promessa simples: falar com o computador sem fazer barulho.
A ideia mexe com uma frustração antiga. Ditado por voz funciona bem há anos, mas quase ninguém usa no trabalho. O motivo não é técnico. É social.
O que é o Subvocal, afinal?
A proposta é comandar a máquina usando a fala subvocal. É aquela fala que você "quase" faz: mexe a boca, a língua e a garganta, mas não solta som. Todo mundo faz isso sem perceber quando lê com atenção.
O conceito não é novo. O MIT mostrou o AlterEgo em 2018, um aparelho que lia sinais elétricos dos músculos do rosto para reconhecer palavras ditas em silêncio. A NASA estudou algo parecido nos anos 2000. O que mudou de lá para cá foi o resto da pilha: os modelos de reconhecimento ficaram baratos, rodam localmente e entendem contexto muito melhor.
Um aviso honesto: não testei o Subvocal na minha máquina. O que escrevo aqui é sobre a proposta, o tipo de pipeline que um projeto assim exige e o que eu faria para validar a ideia antes de confiar nela. Se você quer os detalhes de hardware e precisão, a thread original é o lugar certo.
Por que interface silenciosa importa para dev
Pensa no seu dia. Quantas vezes você para o que está fazendo para:
- abrir um terminal e rodar o mesmo comando de sempre;
- trocar de branch;
- pedir algo ao assistente de código;
- buscar um arquivo pelo nome.
Cada uma dessas ações custa poucos segundos. O problema é a troca de contexto. Tirar a mão do código para clicar em algo quebra o raciocínio.
Voz resolveria parte disso, se não fosse por três coisas: barulho no ambiente, privacidade e o constrangimento de falar sozinho no open space. A fala silenciosa ataca as três de uma vez. Você continua digitando e, em paralelo, "fala" um comando curto.
O gargalo do ditado nunca foi o modelo. Foi o colega da mesa ao lado.
Agora, a parte que pouca gente comenta: com agentes de código virando rotina, o volume de texto que a gente manda para a máquina em linguagem natural explodiu. Prompt é texto longo. Digitar prompt é chato. Uma entrada que não exige teclado nem voz alta encaixa direitinho nesse fluxo.
Onde o Bun entra nessa história
Ferramentas como essa têm sempre a mesma arquitetura por baixo. Um sensor ou modelo gera texto. Alguma coisa recebe esse texto e transforma em ação no sistema. Essa segunda parte é cola, e cola é exatamente onde o Bun brilha.
Por quê? Porque você tem servidor HTTP, WebSocket, execução de processos e leitura de arquivo no runtime, sem instalar nada. Sobe em milissegundos. Para um daemon que fica rodando o dia inteiro esperando comandos, isso faz diferença.
Um protótipo do "lado da ação" cabe em poucas linhas:
// daemon.ts: recebe texto reconhecido e dispara ações
const comandos: Record<string, string[]> = {
"status": ["git", "status", "--short"],
"testes": ["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("só WebSocket aqui", { status: 400 });
},
websocket: {
async message(ws, msg) {
const texto = String(msg).trim().toLowerCase();
const cmd = comandos[texto];
if (!cmd) return ws.send(`não entendi: ${texto}`);
const proc = Bun.spawn(cmd, { stdout: "pipe" });
ws.send(await new Response(proc.stdout).text());
},
},
});
Repare em duas escolhas. Primeiro, o servidor escuta só em 127.0.0.1. Um daemon que executa comandos no seu shell não pode ficar exposto na rede, nem por acidente. Segundo, os comandos estão numa lista fechada. Nada de pegar o texto reconhecido e jogar direto num sh -c. O reconhecimento vai errar, e você não quer que "rodar testes" vire "rm" por causa de um músculo mal lido.
Os problemas que ninguém resolve com um post bonito
Eu gosto da ideia. Mas tenho experiência suficiente com demo de Show HN para saber onde ela costuma quebrar.
Precisão. Reconhecimento de fala com som já erra em ambiente barulhento. Sem som, o sinal é bem mais pobre. Uma taxa de erro de 5% parece boa no papel. Na prática, significa errar um comando a cada vinte. Se o comando for "abrir arquivo", tudo bem. Se for "fazer push", não.
Vocabulário. Sistemas assim costumam ir muito bem com um conjunto pequeno de palavras e piorar rápido com texto livre. Para comandos curtos, funciona. Para ditar um prompt de três parágrafos, eu ficaria com o pé atrás até ver números de verdade.
Calibração. Cada pessoa mexe a boca de um jeito. Se a ferramenta exige treino por usuário, a fricção de entrada sobe. Vale ver quanto tempo leva até ficar usável.
Privacidade. Se o sinal sai da sua máquina para uma API, você está mandando, literalmente, o que pensou em dizer. Eu só usaria algo assim com inferência local. Ponto.
A boa notícia é que dá para mitigar boa parte disso com design, não com modelo melhor. Um padrão que eu usaria:
// confirmação para ações com efeito colateral
const perigosos = new Set(["push", "deploy", "reset"]);
function precisaConfirmar(texto: string) {
return [...perigosos].some((p) => texto.includes(p));
}
Comando seguro executa direto. Comando perigoso pede um "sim" no teclado. Simples, chato e eficaz.
Como avaliar o Subvocal (ou qualquer ferramenta parecida)
Se você quer testar, sugiro um roteiro rápido em vez de se empolgar com o vídeo de demonstração:
- Escolha 10 comandos reais do seu dia. Não os da demo, os seus.
- Repita cada um 10 vezes em condições normais: sentado, cansado, depois do almoço.
- Anote acertos e latência. Se passar de meio segundo entre "falar" e a ação acontecer, você vai voltar para o teclado.
- Teste o falso positivo. Fique 15 minutos lendo documentação em silêncio. A ferramenta disparou algo sozinha? Esse é o teste que mais importa, porque a gente subvocaliza o tempo todo sem querer.
Esse último ponto é o meu maior receio com a categoria inteira. Ler código é subvocalizar. Se o sistema não souber diferenciar "estou lendo" de "estou mandando um comando", ele vai virar um assistente que se intromete na hora errada. Uma palavra de ativação ou um atalho de teclado para "estou falando com você agora" resolve, e eu desconfiaria de qualquer projeto que não tenha algo assim.
O que muda no seu fluxo de trabalho
Hoje, quase nada. Sendo realista, interfaces silenciosas ainda estão na fase de protótipo empolgante. Não vão substituir teclado tão cedo. Teclado é rápido, preciso e não precisa de calibração.
O que muda é a direção. A gente passou décadas com duas entradas: teclado e mouse. Voz virou a terceira, mas ficou presa no carro e na cozinha. Uma entrada silenciosa poderia ser a primeira que funciona dentro do escritório, junto com o teclado, e não no lugar dele.
E para quem escreve ferramenta, a lição é outra. A parte difícil (o modelo, o sensor) vai ficar cada vez mais terceirizada. O valor vai estar na camada de integração: quais comandos existem, como confirmar ações perigosas, como evitar falso positivo. Isso é código de aplicação comum, do tipo que a gente escreve todo dia em TypeScript.
Minha opinião: a ideia é boa e o momento é certo, mas eu só levo a sério quando aparecer alguém usando oito horas por dia sem desligar no terceiro dia. Até lá, vou brincar com um daemon em Bun e uma lista de cinco comandos, que é como toda boa ferramenta começa. Se curte esse tipo de experimento, dá uma olhada no que ando construindo em meus projetos.
Resumo para o LinkedIn
O ditado por voz nunca pegou no escritório, e o motivo não foi técnico: foi o colega da mesa ao lado. O Subvocal apareceu no Hacker News com uma proposta ousada: comandar o computador mexendo boca e garganta, sem soltar nenhum som. Com agentes de código virando rotina, a gente nunca escreveu tanto prompt. Uma entrada que não exige teclado nem voz alta encaixa direitinho nesse fluxo. Mas meu maior receio é outro: ler código já é subvocalizar. Sem uma palavra de ativação, a ferramenta vira um assistente que se intromete na hora errada. Por isso eu validaria com 10 comandos reais, inferência local e confirmação no teclado para qualquer coisa perigosa, tipo push ou deploy. Escrevi no blog como montaria o daemon em Bun que fica do lado da ação. Você usaria uma interface silenciosa no trabalho? #DesenvolvimentoDeSoftware #InteligenciaArtificial #Bun #TypeScript #DevTools