Vibe coding com agente que implementa separado do agente que valida

Se você der a um agente a missão de implementar uma feature, ele vai atrás dela com tudo o que tem, e "tudo" inclui apagar o teste que estava no caminho. gbrl808 usou essa cena para explicar por que quem constrói não pode ser quem aprova:

"Quando tu dá uma missão para um agente, ele vai tentar cobrir ela. Então, se tu der uma missão de implementar, ele vai fazer de tudo para implementar, inclusive deletar código. Se der uma missão de validar, ele vai fazer de tudo para validar."

O que segura o argumento inteiro está no meio da frase: deletar código. O agente que faz isso está perseguindo até o fim a missão que recebeu. Se o que trava a entrega é um teste vermelho, o teste vermelho entra na conta como obstáculo, e obstáculo se remove. O problema é de incentivo, e um modelo mais capaz persegue a mesma missão com mais competência. Daí sai o princípio:

"o agente não deve ser quem julga. Quem [julga] tem que ser uma ferramenta que retorna um 0 [ou] 1, porque se tu deixar o agente julgar, ele vai olhar pro código e vai achar que tá bom o suficiente sem rodar o teste."

O julgamento compete com a vontade de terminar

Quando o mesmo agente escreve e confere, você pediu 2 coisas que puxam para lados diferentes, e a que ganha é a de fechar a tarefa. Ele lê o código que acabou de produzir, considera bom o suficiente e segue em frente sem executar nada. Um teste não tem essa vontade: ele roda e devolve passou ou não passou. O linter aponta ou não aponta — e o aviso que ele levanta é justamente o tipo de sinal que o implementador tem incentivo para calar, tema de vibe coding para nunca silenciar aviso do lint. A aprovação precisa sair de uma ferramenta externa, no papel de sensor, em vez de sair da leitura que o agente faz do próprio trabalho.

Isso resolve um buraco que o setup mais comum de vibe coding hoje não cobre. A spec define o que fazer sem verificar se foi feito, assunto que rendeu o post sobre spec driven development. O sensor entra depois, na parte que a spec não alcança. Isso aparece também em vibe coding para playbook separado do harness principal.

Subagente na mesma sessão mantém o juiz dentro de casa

A montagem que a maioria usa tem um agente principal que chama subagentes durante a própria sessão. Parece separação de papéis, mas o julgamento continua acontecendo no mesmo lugar, com a mesma missão por trás de todo mundo. Quem coordena os subagentes é o mesmo que quer entregar.

O desenho que ele defende sai da sessão. Um processo orquestrador inicia um agente com a missão de implementar e inicia outro agente, em outra janela e em outro processo, com a missão de validar a saída do primeiro. Processos separados, missões separadas. O segundo agente não tem nenhum investimento em declarar que o trabalho ficou pronto, porque a missão dele é outra: descobrir se a coisa passa.

O loop que o vibe coding ganha com um juiz de fora

Quando a validação reprova, o orquestrador não devolve o problema para você. Ele dispara de novo o passo de construção com o que falhou, e o ciclo repete até passar. Cada reprovação vira input de uma nova rodada de implementação, o que tira a validação do lugar de relatório final.

Na demonstração dele isso aparece rodando. Depois da fase de construção entra a fase de avaliação, que devolve se passou ou não, com um score e o mínimo necessário para passar em cada item avaliado. A validação roda contra critérios definidos antes, não contra o que o avaliador achar interessante olhar naquele momento. E o que ocupa o lugar da avaliação é escolha sua: teste de unidade, teste de integração ou o que fizer sentido para o projeto. Isso aparece também em vibe coding com contrato entre agente implementador e validador.

Como montar isso amanhã

O passo mais barato é escolher uma ferramenta que devolva resposta binária no fim de cada tarefa, mesmo que seja a suíte de teste que o projeto já tem. Enquanto a aprovação depender do agente dizer que está bom, você está confiando no relato de quem tinha interesse no resultado.

Depois separe os processos. Uma janela roda o agente que implementa. Outra janela, outro processo, roda o agente cuja missão é validar aquele output. Se a validação reprovar, o retorno volta para a construção com o motivo da reprovação, e não para a sua caixa de entrada. É essa peça que falta na maioria das montagens de vibe coding que rodam hoje, e é ela que decide se o agente trabalhando sozinho entrega algo conferido ou só entrega a própria opinião sobre o que fez.

O trecho onde ele monta e roda esse ciclo está em teste VibeCode ao vivo.