- Agentes de IA para escrever código geram código e aplicam mudanças no branch enquanto o desenvolvedor dorme, mas é difícil validar a exatidão e a confiabilidade do resultado
- Se a mesma IA que escreveu o código também o testa, ela vira uma máquina de autocelebração e não consegue capturar mal-entendidos que desviam da intenção original
- Tomando emprestado o princípio central do TDD, escreve-se primeiro os critérios de aceitação antes do código, e o agente implementa com base neles enquanto uma verificação separada é executada depois
- Foi construído um pipeline de 4 etapas combinando o modo headless do Claude Code (claude -p) com o Playwright MCP como ferramenta de verificação, sem necessidade de backend separado
- Para confiar no que um agente produz, é preciso definir claramente o que significa “pronto” antes de iniciar o trabalho — isso é mais difícil do que escrever prompts, mas é um processo indispensável
O problema da validação de código em agentes autônomos
- Com ferramentas de IA como o Gastown, agentes passam horas escrevendo código e aplicando mudanças no branch, mas não existe um método confiável de validação para saber se o resultado está realmente correto
- Após conduzir workshops do Claude Code com mais de 100 engenheiros nos últimos 6 meses, o mesmo problema foi observado em todas as equipes
- Equipes que usam o Claude em PRs do dia a dia viram o volume de PRs mesclados aumentar de 10 por semana para 40–50, passando muito mais tempo em revisão de código
- Quanto mais autônomo o sistema se torna, mais grave o problema fica — chega um ponto em que, em vez de revisar o diff, você apenas observa o deploy e torce para que nada dê errado, descobrindo os erros só depois da implantação
Limites das soluções existentes
- A solução de contratar mais revisores não acompanha a velocidade, e é ineficiente fazer engenheiros seniores passarem o dia inteiro lendo código gerado por IA
- Quando o Claude escreve testes para o código que ele mesmo criou, a estrutura passa a verificar não o que o usuário realmente queria, mas o que o Claude julgou que queria
- Dá para capturar bugs de regressão, mas não o mal-entendido (misunderstanding) original
- Se a mesma IA faz tanto a implementação quanto a validação, ela vira uma “máquina de autocelebração (self-congratulation machine)”
- O objetivo original do code review é ter um segundo olhar, e a revisão cruzada entre IAs vem da mesma origem, então deixa passar as mesmas coisas
O ponto essencial que o TDD acertou
- Princípio do TDD: escrever os testes primeiro, escrever o código e parar quando os testes passam (sem implementar mais do que isso)
- A razão de a maioria das equipes não praticar TDD é que pensar antecipadamente no que o código deve fazer toma tempo
- Como a IA resolve o problema de velocidade, essa desculpa desaparece — agora a parte lenta é julgar se o código está correto
- Em vez de testes unitários, é mais fácil descrever em linguagem natural o que a funcionalidade deve fazer
- Exemplo: "O usuário se autentica com e-mail e senha. Se as credenciais estiverem incorretas, mostrar 'Invalid email or password'. Em caso de sucesso, ir para /dashboard. O token de sessão expira após 24 horas"
- Esses critérios podem ser escritos antes mesmo de abrir o editor, e então o agente implementa enquanto outra coisa valida
Caso de uso real
-
Mudanças de frontend
- Com base em um arquivo de especificação, são gerados os critérios de aceitação (Acceptance Criteria)
- AC-1: ao acessar /login com credenciais válidas, redirecionar para /dashboard e definir o cookie de sessão
- AC-2: ao informar senha incorreta, exibir exatamente "Invalid email or password" e permanecer na página /login
- AC-3: se os campos estiverem vazios, o botão de envio fica desabilitado ou um erro inline é mostrado
- AC-4: após 5 falhas, bloquear o login por 60 segundos e mostrar uma mensagem com o tempo de espera
- Cada critério pode ser claramente classificado como aprovado ou reprovado
- Depois que o agente constrói a funcionalidade, um agente de navegador com Playwright executa a verificação para cada AC, tira screenshots e gera um relatório de resultado por critério
- Em caso de falha, é possível ver exatamente qual critério falhou e o que apareceu no navegador
-
Mudanças de backend
- O mesmo padrão é aplicado sem navegador
- Especifica-se o comportamento observável da API (status code, headers de resposta, mensagens de erro) e a validação é feita com comandos curl
-
Limitações
- Não consegue capturar mal-entendidos na própria especificação — se a spec já estiver errada desde o começo, a verificação pode passar e a funcionalidade continuar incorreta
- O que o Playwright consegue capturar: falhas de integração, bugs de renderização e comportamentos quebrados em navegador real
- É uma afirmação mais restrita do que “exatidão verificada”, mas ainda captura mais coisas do que o code review costumava detectar de forma confiável
-
Resumo do fluxo de trabalho
- Escrever os critérios de aceitação antes do prompt → o agente implementa com base neles → executar a validação → revisar apenas o que falhou (revisão de falhas, não de diff)
Como foi construído: pipeline em 4 etapas
- Implementado como Claude Skill (github.com/opslane/verify), usando claude -p (modo headless do Claude Code) e Playwright MCP
- Não requer backend customizado separado nem chaves de API adicionais, usando apenas o token OAuth existente do Claude
-
Etapa 1: Pre-flight
- Bash puro, sem chamadas a LLM
- Verifica se o servidor de desenvolvimento está em execução, se a sessão de autenticação é válida e se o arquivo de especificação existe
- Falha rapidamente antes de consumir tokens
-
Etapa 2: Planner
- Uma chamada ao Opus
- Lê a spec e os arquivos alterados, e decide o que é necessário e como executar cada verificação
- Como lê o código para encontrar os seletores corretos, não precisa adivinhar nomes de classe
-
Etapa 3: Browser Agents
- Uma chamada ao Sonnet por AC, todas executadas em paralelo
- Se houver 5 ACs, 5 agentes navegam de forma independente e tiram screenshots
- O Sonnet é 3 a 4 vezes mais barato que o Opus e tem desempenho equivalente em tarefas baseadas em clique
-
Etapa 4: Judge
- Uma chamada final ao Opus lê todas as evidências e retorna um veredito por critério: pass, fail ou needs-human-review
-
Como instalar
- Pode ser instalado como plugin do Claude Code:
/plugin marketplace add opslane/verify
- Ou você pode clonar o repositório e customizar — cada etapa tem uma única chamada claude -p, com entrada clara e saída estruturada
- É possível trocar modelos, adicionar etapas e integrar com CI usando a opção --dangerously-skip-permissions
Lição principal
- O ponto central é que “se a definição de pronto não for explicitada antes, você não pode confiar no resultado”
- Escrever critérios de aceitação é mais difícil do que escrever prompts, mas obriga a considerar casos de borda antecipadamente, elevando a qualidade
- Do mesmo modo que equipes resistiam ao TDD, aqui também há resistência porque no começo parece mais lento
- Sem critérios de aceitação, só resta ler o resultado e torcer para que esteja certo
- Este é um procedimento indispensável para garantir confiabilidade em um ambiente de desenvolvimento orientado por IA
2 comentários
Por mais que você faça TDD, no nível atual em que o LLM manipula os testes para fazê-los passar, revisão humana é absolutamente necessária..
Opiniões no Hacker News
Tenho a sensação de que os frameworks de LLM que estão surgindo ultimamente acabam tornando o desenvolvimento mais difícil e mais caro
Só com a configuração padrão já dá para ir bem longe, e, com os modelos mudando o tempo todo, criar inúmeros wrappers e harnesses me parece ineficiente
Esse jeito de deixar rodando a noite toda e queimando dinheiro vai acabar virando piada no futuro, como o meme do PHP
Segundo o artigo, “nos últimos 6 meses, foram realizados workshops de Claude Code para mais de 100 engenheiros”
Quando ficarem rodando dia e noite, a empresa de IA acabar quebrando e só sobrarem 80% de código espaguete escrito por IA, vamos ver quem vai rir no fim
Tenho a sensação de que o PHP de 15 anos atrás era melhor do que o ambiente full-stack JS/TS de hoje
O PHP continua vivo e evoluindo. As ferramentas de LLM também vão acabar virando ferramentas básicas desse tipo
As fronteiras entre BA, PO, QA e SWE estão ficando borradas. Agora estão surgindo papéis híbridos entre negócios e desenvolvimento
Parece que hoje em dia as pessoas querem usar agentes só por usar
Eu rodo só dois, um para escrita e outro para revisão, e mesmo assim já consigo 5 a 7 vezes mais produtividade
Gasto mais tempo revisando a especificação, e o agente termina a codificação em 10 a 30 minutos, então não há pressa
Amanhã ainda vai haver trabalho, então não há motivo para deixar isso rodando a madrugada inteira
Do ponto de vista do cliente, não faz muita diferença se o bug veio da Índia, de San Francisco ou da IA
É uma forma muito mais controlada do que essa moda de “orquestra de agentes”
Por isso eu mesmo criei a skill verify para checar se o Claude segue bem a especificação
Fazer o Claude usar o padrão red-green-refactor realmente melhora a qualidade dos testes
Indo além, criar subagentes de red/green/refactor para validarem uns aos outros funciona muito bem
O essencial é não misturar contextos
Reward hacking existe de fato e é difícil de evitar
Mesmo consultando este guia, o problema dos testes ruins continua grande
O resultado foi bom, então publiquei os princípios e exemplos e um starter repo
É importante separar autor e verificador, e mesmo com o mesmo modelo a qualidade sobe quando o contexto é separado
Com os limites atuais de contexto dos LLMs, agentes de verdade ainda são impossíveis
Em códigos com mais de 500 linhas, os erros aumentam drasticamente, e algo em torno de 200 linhas já é o limite
No fim, LLM é apenas uma ferramenta para ser usada repetidamente como uma calculadora
Eu chamo esse fenômeno de “Test Theatre”
Escrevi sobre isso aqui. Deve ser evitado ativamente
Bons testes devem validar padrões de design e dependências, além de ajudar no debugging
Por exemplo, com Schemathesis dá para validar automaticamente permissões de usuário ou a ocorrência de respostas 5xx
Coloquei um POC relacionado aqui
Recentemente estou experimentando orquestração de agentes
A chave é reduzir chamadas ao LLM e conectar tudo por um pipeline de scripts determinístico
Os detalhes estão organizados neste texto
Como neste registro de experimento, o essencial são os scripts, não o LLM
Eu opero 6 agentes para operações de negócios
Eles cuidam de várias funções, como pesquisa de mercado, produção de conteúdo e roteiros de vídeo
“Deixar rodando a noite toda” é um conceito exagerado; na prática, o que funciona é ter objetivos claros e escopo estreito
O verdadeiro gargalo não é a execução, e sim o gerenciamento de contexto
Não faço ideia do que essa pessoa realmente está construindo
No LinkedIn só vejo posts sobre Claude
Para um negócio sério, isso é algo inimaginável
No fim, o código fica parado enquanto tentam descobrir como vender o produto
É o mesmo problema de contratar alguém que só escreve testes
No fim, você só confirma que “o código funciona do jeito que o próprio código diz que funciona”
Definir uma especificação clara é muito mais importante
É surpreendente que outras áreas da engenharia não repitam esse erro, mas software em particular faça isso o tempo todo
Mesmo que a primeira versão esteja errada, eles garantem que o comportamento não mude depois
Muitas consultorias trabalham com validação baseada em acceptance criteria
A IA atual já chegou a um ponto em que não apenas ajuda no desenvolvimento, mas substitui o desenvolvedor
O fato de não conseguirmos mais controlar nem validar o código é um problema sério
Isso não parece um novo jeito de desenvolver, e sim uma mudança quase religiosa, baseada em confiança em vez de compreensão
Mesmo com menos autonomia, só faço merge de código que consigo validar