Salve, pessoal.

Eu passei muito tempo numa bolha onde ler docs em inglês me davam a falsa sensação de fluência. Mas quem já fez entrevista pra vaga na gringa sabe a realidade: a gente sabe responder as perguntas, mas na hora de responder em inglês dá uma travada, eu lembro da minha primeira reunião que eu fiz há um bom tempo, tinham me perguntado alguma coisa sobre o Vue.js, na época o Next e Nuxt nem eram tão famosos, eu sabia responder em português e no inglês só travei, aí eu comecei a misturar um inglês com espanhol bizarro

Então, recentemente, eu tentei resolver isso do jeito óbvio: abrindo o ChatGPT e pedindo pra ele simular uma entrevista técnica comigo. E é aqui que tá um grande problema.

O ChatGPT puro, na verdade, sabota o seu cérebro. E o buraco é tanto cognitivo quanto técnico.

O problema cognitivo: A ilusão do texto assíncrono

Quando você treina digitando, você tem tempo de pensar. Você apaga. Você pesquisa a palavra que esqueceu. E pior: por padrão, as LLMs são treinadas com RLHF (Reinforcement Learning from Human Feedback) para serem "assistentes prestativos". Elas concordam com você. Elas não te cortam, não questionam suas escolhas de arquitetura de forma agressiva e, geralmente, te dão a resposta mastigada.

Numa entrevista de System Design real, se você propõe usar um banco relacional, o Tech Lead te interrompe e pergunta: "Why not NoSQL here? What about the read-heavy nature of this service?".

A tentativa de solução: Voz em tempo real

Pra consertar isso, resolvi montar uma PoC (Proof of Concept) local conectando a API do Claude com o navegador, só pra eu tentar fazer mock de entrevista falada usando uns prompts mais pesados.

Parecia simples. Até eu descobrir o inferno que é lidar com estado de áudio no browser.

O pesadelo do VAD (Voice Activity Detection)

Se você usa o microfone do navegador gravando um áudio contínuo e mandando pro backend, a latência fica bizarra. E pior: como a IA sabe que você terminou de falar e não está apenas fazendo uma pausa dramática pra pensar?

O modo de voz padrão do app da OpenAI sofre com isso: você respira, ele acha que você acabou, te interrompe e quebra sua linha de raciocínio lógico.

Para o negócio ficar imersivo, eu tive que descer o nível da abstração. Abandonei APIs prontas e fui implementar o Silero VAD, rodando client-side direto no browser via WebAssembly (WASM).

Para quem não conhece, o VAD analisa os frames de áudio na máquina do usuário, em tempo real, verificando probabilidades probabilísticas de ser voz humana ou ruído. Ele processa pedaços de 30ms. Se a probabilidade cai abaixo de um threshold (digamos, 0.5) por mais de X milissegundos, o front-end corta o áudio, empacota o blob em base64 e dispara pra onde você quiser (um endpoint).

O resultado? Latência mínima e a IA não te interrompe enquanto você diz "Uhhhhh... let me think about that".

O pedágio dos navegadores

Lidar com isso me fez perder alguns anos de vida por causa do Safari (como sempre). A política de Autoplay do iOS bloqueia qualquer áudio gerado pelo ElevenLabs no retorno da requisição se o contexto de áudio (AudioContext) não tiver sido iniciado por um gesto explícito e contínuo do usuário. Acabei tendo que criar toda uma máquina de estados no React só pra manter os buffers de áudio em fila sem o Safari matar o processo de fundo.

No fim, o aprendizado real foi que interfaces de voz assíncronas são o próximo pesadelo do front-end. O DOM e o React não foram feitos pra lidar com streams de áudio não-determinísticos com a graciosidade que lidam com JSON.

Alguém aqui já teve que lidar com áudio client-side profundo ou processamento via WebAssembly? Como vocês lidam com as limitações bizarras de segurança dos browsers mobile para áudio?

E pra galera que trampa fora: como vocês destravam esse delay na hora do inglês sem recorrer ao texto?