Product manager sem desenvolvedor lança extensão feita por agentes de IA e a protege com 89 testes-guarda

O agente escreve: “Pronto, todos os testes passam”. Quando o projeto não tem desenvolvedor e você mesmo não lê o código, restam duas opções: acreditar na palavra do agente ou criar um método de verificação. O product manager que desde janeiro constrói uma extensão para Chrome com dois agentes de IA, Claude Code e Codex, escolheu a segunda.

Em 28 de outubro, o projeto tinha 593 commits, 78 478 linhas de código, 177 511 linhas de testes e a versão 1.0.1 na Chrome Web Store.

Mas os testes foram escritos pelo mesmo agente que escreveu o código, então a quantidade, por si só, não prova nada. Por exemplo, o produto promete reler o arquivo de configurações pelo menos uma vez por hora. O agente muda o intervalo para um dia; o teste pega o novo número do próprio código, compara-o consigo mesmo e continua verde.

Enquanto isso, o usuário espera um dia inteiro. Para se proteger disso, o autor criou os “guardas” (em inglês, guard): testes que protegem uma promessa específica do produto e falham quando ela é violada. Hoje são 89.

Se você entrega ao agente uma tarefa de várias horas, pode adotar essa abordagem.

Que produto é esse e em que base isso foi testado

A extensão se chama Chat with Multiple AI e envia uma única pergunta, de uma vez, a 15 chats de IA, entre eles ChatGPT, Claude e Gemini. São sites de terceiros, que mudam sem aviso. Por isso, a descrição de como trabalhar com cada chat fica em um arquivo de configurações separado. Quando um chat muda, o autor corrige o arquivo, e a correção chega aos usuários sem uma nova versão na loja. Isso aconteceu duas vezes: em 19 de outubro e em 1º de novembro. Antes da versão 1.0.1, o próprio agente percorreu 70 cenários de aceitação no navegador.

A verificação do autor é dividida em etapas. O build, os testes e os guardas garantem que as regras no código e nos documentos não divirjam. O agente no navegador mostra o que o produto realmente faz. Um revisor independente analisa as mudanças que não foram escritas por ele. O próprio product manager aprova o comportamento visível com base em uma lista do relatório: o que acontece após o clique, se o resultado apareceu, o que ocorre em caso de falha.

O guarda: a promessa do produto registrada em um teste

O guarda do exemplo verifica duas condições: o intervalo de releitura é maior que zero e não passa de uma hora. Se o agente definir um dia, a segunda condição não será satisfeita, e o teste falhará. O nome do arquivo do guarda é a própria promessa, em linguagem comum, por exemplo “a correção publicada chega ao usuário em até uma hora” ou “o lembrete não é enviado enquanto não estiver registrado que ele vai ser enviado”. Sem esse registro, depois de uma reinicialização o produto não saberia que já enviou o lembrete e o enviaria uma segunda vez. A lista de arquivos se lê como uma lista de promessas do produto.

Os guardas foram adicionados de forma irregular: 2 em maio, 9 em julho, 33 em agosto, 40 em setembro e 5 em outubro. O modelo prático de pedido ao agente é este: descreva a promessa com as palavras do usuário, peça que ele encontre o que no código a sustenta, escreva um guarda com um nome claro e mostre que ele falha quando a promessa é violada.

Build verde e duas cópias das regras

Um build verde pode não verificar nada. Em 27 de julho, o contador de erros de tipos (quando o código confunde tipos de dados, por exemplo ao tratar texto como número) chegou a zero. Há duas maneiras de chegar a zero: corrigir os erros ou deixar de procurá-los, por exemplo desligando o modo estrito ou excluindo uma pasta da verificação.

Contra isso, o autor usa dois recursos. O primeiro é um limite mínimo: a verificação conta os arquivos lidos e falha se forem poucos demais. O segundo é a quebra intencional: em uma cópia do projeto, uma regra é violada de propósito, e o guarda tem de falhar.

No desenvolvimento, isso se chama teste de mutação. O template quebra uma cópia do projeto de 42 formas e mostra qual verificação pegou cada falha; no computador do autor, a demonstração leva menos de um minuto.

Outro problema é a duplicação das regras. Claude Code e Codex liam as regras de arquivos diferentes, CLAUDE.md e AGENTS.md, que deveriam ser idênticos. As divergências foram se acumulando: 9 linhas em março, 12 em junho e 21 em agosto, quando os arquivos tinham 102 e 85 linhas. O arquivo de regras cresceu de 61 linhas em fevereiro para 179 em outubro. Desde 25 de setembro, resta apenas um AGENTS.md, e o guarda falha se aparecer outro arquivo de regras ao lado. As skills (instruções para ações repetíveis, como fazer um commit) ficam nas pastas de cada agente, por isso o guarda confere cada par.

O autor faz uma ressalva honesta: ele não mediu quanto da melhoria veio da estrutura de verificação e quanto veio de modelos mais inteligentes. Ele publicou essa estrutura como um template aberto no GitHub (yesgenius/agent-harness).