Entender Software vs. Gerar Código
Bugs de estado e fluxo de uma aplicação real mostram onde fica evidente a diferença entre quem entende de programação e quem apenas gera código.
As IAs evoluíram muito.
Hoje elas escrevem boilerplate, sugerem arquiteturas, geram testes, explicam APIs e aceleram uma quantidade enorme de trabalho.
Mas existe um tipo de problema onde a diferença entre quem entende programação e quem apenas gera código fica muito evidente: bugs de estado e fluxo de uma aplicação real.
O caso real: busca por conteúdo no Flux
Nos últimos dias eu estava implementando uma nova feature no Flux, meu gerenciador de arquivos open source escrito em Rust.
A ideia era adicionar na search engine a capacidade de procurar strings dentro do conteúdo dos arquivos, e não apenas pelos nomes.
A implementação estava praticamente pronta. Só tinha um problema: depois da segunda busca, a aplicação simplesmente congelava.
Passei o projeto inteiro para as melhores IAs que encontrei: código completo, arquitetura, fluxo das mensagens, logs e contexto.
Mesmo explicando exatamente onde eu suspeitava que estava o problema, todas insistiam na mesma direção.
O diagnóstico delas dizia que o problema estava aqui:
"Talvez seja um problema de sincronização."
"Pode existir um bloqueio de execução entre tarefas."
"Talvez o loop de eventos esteja causando uma condição inesperada."
"Pode ser o gerenciamento das threads."
Tudo parecia plausível. Mas o problema não estava ali.
Eu explicava que o fluxo problemático era outro:
Ele estava entrando novamente em um caminho que causava um loop infinito. Mesmo assim, as respostas continuavam voltando para a mesma hipótese.
A investigação manual e a solução
Depois de muita insistência, precisei fechar as IAs e voltar para o código. Segui a aplicação estado por estado.
A causa era simples: quando a busca era aberta, uma atualização do filtro acontecia novamente em uma condição específica, e o fluxo não tinha uma proteção para esse caso.
A correção exigiu apenas uma validação de estado:
if query.is_empty() && self.search_just_opened {
self.search_just_opened = false;
return;
}Uma validação de estado. Só isso.
Depois apareceu outro bug: ao cancelar uma pesquisa, a rotina limpava corretamente o grid de arquivos, mas esquecia de reconstruir o estado da interface. Os dados estavam corretos, mas a tela nunca recebia a atualização.
Faltava apenas isto:
sender.input(AppMsg::Refresh);Duas correções pequenas. Dois problemas que pararam completamente o projeto.
O que isso ensina sobre "Vibe Coding"
E é exatamente aqui que entra o ponto sobre vibe coding.
Gerar código com IA é extremamente poderoso. Eu consigo desenvolver muito mais rápido usando essas ferramentas.
Mas existe uma diferença enorme entre criar código e entender software.
Cria soluções rapidamente baseadas em padrões, mas não compreende a intenção profunda nem a cadeia de eventos de uma aplicação viva.
Saber exatamente como estados, eventos, concorrência e fluxo de dados se comportam quando algo sai do caminho esperado.
Quando você não sabe como uma aplicação funciona internamente, um bug desse tipo pode simplesmente travar o projeto. A IA pode gerar uma solução, mas alguém ainda precisa entender quando aquela solução faz sentido.
Porque no final, o problema não era uma arquitetura complexa nem uma falha misteriosa. Era um estado entrando no fluxo errado e uma atualização de interface que nunca acontecia.
"IA é um multiplicador. Mas ela multiplica principalmente a capacidade de quem já sabe navegar pelo código."