O “vibe coding” prometeu que qualquer pessoa poderia construir um aplicativo web apenas com prompts em linguagem natural: você pede, e o agente de IA entrega uma interface polida em segundos. A promessa implícita é nunca mais olhar o código. Na prática, porém, a realidade é bem diferente — e o problema tem nome: falhas silenciosas.
O que são falhas silenciosas
São bugs em que a interface parece funcionar à primeira vista, mas o sistema está quebrado por baixo. Um exemplo clássico: você clica em “Adicionar ao carrinho”, vê uma mensagem de sucesso e o contador ser atualizado na tela — mas nada é gravado de fato no banco de dados ou no armazenamento. Para descobrir, é preciso interagir com a interface, ler logs e, no fim, ler o código gerado, o que anula justamente a proposta do vibe coding.
O que um estudo descobriu
Pesquisadores que desenvolveram aplicativos reais em etapas iterativas observaram que até modelos de ponta introduzem falhas silenciosas com frequência ao longo das iterações. Os erros foram agrupados em categorias como falhas no rastreamento de estado, desconexão de estado entre manipuladores e feedback de interface desconectado (a mensagem de sucesso aparece, mas o dado não foi salvo).
Um exemplo concreto: ao pedir que um agente adicione um recurso de cupom promocional a um aplicativo de compras, ele cria o campo de entrada e o botão “Aplicar”. O usuário digita um código válido e a interface exibe “Desconto aplicado!” — mas o novo total não é persistido nem exibido.
Por que a verificação tradicional falha
- LLMs como juízes: pedir ao modelo para depurar o próprio código não é confiável. Modelos como Claude Opus 4.7, DeepSeek V3 e Gemini Pro erram casos extremos, alucinam correções e não entendem fluxos de dados complexos.
- Testes unitários: exigem escrever mais código para checar o código gerado, não cobrem a integração entre interface e backend e ficam limitados aos cenários especificados — inacessíveis para quem não programa.
- Análise estática convencional: é determinística e precisa, mas a curva de aprendizado é alta demais para o usuário comum.
A solução: FlowCheck
Diante disso, a pesquisa de doutorado de Reya Vir no DAP Lab da Columbia desenvolveu o FlowCheck, uma linguagem de restrições e um pipeline de análise estática que permite especificar como o aplicativo deveria se comportar diretamente pela interface — sem precisar ler uma linha de código.
O fluxo funciona em quatro passos: o usuário expressa uma restrição no formato “Quando eu faço [ação], isto é atualizado: [componente]”, clicando nos elementos da própria interface; a restrição é traduzida para uma linguagem formal (como P(escrever | ação) = 1); o sistema a compila em consultas CodeQL que rastreiam o fluxo de dados do código; e, por fim, verifica se o comportamento bate com o esperado.
Resultados
Para avaliar o FlowCheck, foram usados quatro aplicativos modelados a partir de Amazon, Twitter, Airbnb e Slack, com 30 bugs sutis de fluxo de dados injetados. O FlowCheck sinalizou corretamente os 30 bugs, sem falsos positivos. Como linha de base, os três modelos de fronteira foram testados com três níveis de detalhe de prompt: o melhor resultado ficou com o Claude Opus 4.7, que encontrou 26 dos 30 bugs (87%).
Os modelos acertaram erros simples e localizados, mas falharam de forma consistente em fluxos entre manipuladores e ramificações condicionais — por exemplo, quando uma ação de “aplicar promoção” limpava o resumo do carrinho enquanto outro manipulador ainda tentava lê-lo. Curiosamente, adicionar mais detalhe ao prompt nem sempre ajudou: os modelos passavam a confiar mais no código e justificavam os bugs como comportamento intencional.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
