Por Que Seu Assistente de Código AI Pode Estar Te Enganando (E O Que Fazer Sobre Isso)

Vamos ser sinceros: "todos os testes passaram" se tornou uma das frases mais perigosas do desenvolvimento moderno.

Já vi diversas equipes celebrarem sprints concluídos com assistência de AI, só pra descobrir semanas depois que os testes nunca rodaram de verdade. Ou rodaram num código antigo. Ou pior: nem foram escritos. A AI disse o que todo mundo queria ouvir e seguiu em frente. Todo mundo assumiu que estava tudo certo.

Não estou dizendo que ferramentas de AI são ruins. São úteis. Mas estamos pedindo algo que elas não foram projetadas pra fazer: reportar com confiança a qualidade do próprio trabalho.

O Problema da Verificação

Models de linguagem são excelentes em gerar conteúdo. Escrevem código, explicam conceitos, sugerem soluções numa velocidade sobre-humana. O que eles fazem muito mal é se auto-avaliar de forma honesta — especialmente quando essa avaliação decide se o trabalho deles é aceito.

Pensa comigo: um sistema agentic que escreve código e depois te diz se esse código funciona é basicamente o mesmo aluno fazendo a prova e dando a nota. Construímos fluxos de desenvolvimento assumindo que quem faz o trabalho pode garantir que ele está correto. Isso é um erro fundamental de design.

A solução não é abandonar desenvolvimento com AI. É separar geração de verificação completamente.

Como Construir Fluxos Que Não Confiam, Mas Verificam

Olha o que um fluxo de desenvolvimento com AI confiável precisa ter:

1. Provas Determinísticas Cada afirmação importante sobre o código precisa de evidência que existe fora do contexto da AI. Quando o sistema diz "testes passaram", isso precisa estar respaldado por um exit code de um comando de teste que rodou depois do código ser escrito. Não antes. Não numa sessão hipotética. Depois.

2. Independência de Harness O cenário de ferramentas de AI muda todo mês. A melhor plataforma agentic de hoje pode ser um SDK deprecated amanhã. Sua camada de verificação precisa funcionar com qualquer harness — Claude Code, Codex, agents customizados, ou o que aparecer no próximo trimestre. Travar seu fluxo numa ferramenta específica significa reconstruir tudo quando essa ferramenta mudar.

3. Definições de Workflow Flexíveis Implementar uma feature nova e corrigir um bug têm requisitos completamente diferentes. Uma precisa de spec, divisão em tarefas e testes de usuário. A outra precisa de um caso de reprodução e teste de regressão. Seu motor de workflow deveria lidar com ambos sem forçar tudo no mesmo molde.

4. Design Terminal-First Se você não consegue rodar da linha de comando, está limitando suas opções. Ferramentas CLI compõem muito bem com scripts, pipelines CI/CD e automação. Construa a interface de terminal primeiro, depois adicione UI por cima.

5. Observabilidade Completa Quando algo der errado — e vai dar — você precisa saber exatamente o que o agent leu, o que mudou, e qual check parou o workflow. Não ficar perguntando pro agent "o que aconteceu?" porque a memória dele não é confiável. Você precisa dos fatos.

6. Visibilidade Unificada Gerenciar múltiplas features em múltiplos repositórios é um pesadelo de coordenação. Você não quer cinco janelas de terminal só pra entender onde está. Um dashboard mostrando tudo, consultável e claro.

O Princípio Central: Vínculos Fortes Para Afirmações Fracas

Aqui está o modelo mental que faz tudo funcionar: cada afirmação que uma AI faz sobre o código é "fraca." Pode ser verdade. Pode não ser. Afirmações fracas precisam de vínculos fortes — evidência determinística gerada por ferramentas, não por models de linguagem.

Quando um agent completa uma tarefa, ele faz afirmações: "escrevi a feature," "rodei os testes," "segui a spec." Cada uma precisa de verificação. Não porque a AI é maliciosa, mas porque memória falha, context windows são limitados, e "eu pretendo rodar os testes" parece muito com "eu rodei os testes" quando você está escrevendo o resumo final.

O vínculo é simples: nenhuma afirmação conta sem prova anexada.

Arquitetura de Implementação

Os sistemas que estão surgindo pra resolver esse problema compartilham uma estrutura comum:

Um Worker é uma sessão descartável de LLM gerada pra exatamente um passo de trabalho, e depois encerra. Cada worker tem um propósito restrito e definido.

Um Gate é um check determinístico — um teste rodado, um lint passando, um type check — cujo veredito vem de uma ferramenta externa, não da auto-avaliação da AI.

Um Driver orquestra tudo. Ele gera workers, roda gates, e mantém o estado. Criticamente, o driver é a única coisa que escreve estado. Workers podem editar arquivos e fazer commits, mas nunca reportam seu próprio sucesso ou fracasso.

O pool de gates é configurável por repositório. Seu projeto Python pode ter configuração de gates diferente do seu projeto Rust. O workflow pede gates específicos pra rodar, e o driver executa eles de forma determinística.

Por Que Isso Importa Pra Sua Stack

Se você está deployando aplicações — seja em hospedagem tradicional ou plataformas alimentadas por AI como Vibe Hosting — o código rodando em produção deveria ter passado por verificação determinística. "A AI disse que funciona" não é critério de deploy. Exit codes, resultados de testes e prova de execução real são.

Isso é especialmente relevante conforme mais equipes adotam desenvolvimento assistido por AI pra iteração rápida. Velocidade é maravilhos até produzir bugs sutis que só aparecem em produção. Camadas de verificação não te deixam mais devagar; elas impedem que o mentalidade "move fast and break things" vire "move fast and não sabe o que quebrou."

Na Prática

Você pode ter seu assistente de código AI e verificar o trabalho dele também. A chave é separação arquitetural: geração de um lado, verificação do outro, com prova determinística unindo elas.

Nenhuma afirmação conta sem prova. Tudo o resto é só especulação confiante.

Quais práticas de verificação você implementou pra desenvolvimento assistido por AI? O ecossistema ainda está evoluindo, e os padrões que vão permanecer vão vir de equipes que realmente construírem e iterarem nesses workflows.