Vibe coding com contrato entre agente implementador e validador antes do código
Separar quem implementa de quem valida cria um crítico sem limite. O contrato é a lista combinada antes do código que define o que o validador pode cobrar.
Separar o agente que implementa do agente que valida resolve um problema conhecido, o do agente que se dá nota e passa. Em troca abre outro, e esse só aparece com a obra andando: um validador sem limite começa a cobrar coisa que ninguém pediu, e quem implementa sai atrás de cada cobrança nova.
Na live de gbrl808 esse freio aparece com nome, contrato. É uma lista que os 2 agentes combinam antes de existir uma linha de código, e ela define o que o validador vai poder cobrar quando chegar a hora de julgar. Sem essa delimitação, quem julga tem alçada infinita.
Quem vai fazer escreve a lista, quem vai julgar confere contra a spec
O contrato nasce no planejamento do sprint, e a ordem em que ele nasce é a parte que faz diferença:
"no momento de planejamento, quando um sprint vai começar, o agente que vai desenvolver cria uma lista de coisas que ele vai fazer. O agente que vai avaliar, ele olha para essa lista e diz: 'Essa lista tá batendo com a spec'."
Quem vai fazer o trabalho escreve o que vai fazer. Quem vai julgar não escreve a lista, confere ela contra a spec e concorda ou não concorda. O validador entra como revisor do plano do outro, com poder de veto no momento em que vetar sai barato, antes de o primeiro arquivo mudar. E o critério dessa conferência é único: a lista tem que bater com a spec.
Fechado o acordo, a construção começa. Depois, na validação, o validador pega o mesmo documento e percorre item por item.
A lista fechada é o roteiro da checagem
O primeiro motivo é cobertura. Com a lista na mão, "o agente que testa, ele vai bater uma a uma e não deixar escapar nada". Um validador sem roteiro confere aquilo que chamou atenção dele naquela passada, e o que não chamou fica sem conferência. Com o contrato, a checagem tem começo e fim, e quem escreveu esse começo e esse fim foi o outro agente, no planejamento.
O loop que não converge
O segundo motivo é o que dá a medida do risco:
"se o agente que testa ele não tivesse uma lista concordada com o agente que vai implementar, ele ia começar a sugerir outras coisas não relacionadas e o agente ia entrar num loop infinito de fazer coisas"
O implementador obedece, e a obediência dele vira problema no instante em que a fila de pedidos deixa de ter fim. Se o validador tem licença para sugerir qualquer coisa, ele sugere, e a construção não fecha porque as exigências não acabam. "Essa concordância é muito importante", ele resume.
São 2 loops diferentes, e eles se parecem o bastante para confundir. O loop saudável já está contado no post sobre o agente que implementa separado do agente que valida: a validação reprova, a construção roda outra vez com o que falhou, e isso repete até passar. Aquele termina porque a lista de itens é fechada. O loop desta live não termina, porque a lista fica aberta e cada passada do validador acrescenta item que não estava combinado.
O contrato é estado visível de quem faz vibe coding com 2 agentes
Na demonstração dá para pedir o estado do que está rodando e ler ali que os agentes concordaram num contrato e que a construção está em andamento naquele momento. O acordo não fica implícito na cabeça de nenhum dos dois, ele é uma coisa que se consulta no meio da execução. Isso muda o que você faz quando desconfia de uma cobrança: em vez de argumentar com o validador sobre o que ele deveria estar exigindo, você abre o contrato e procura o item ali dentro. Se ele está lá, a cobrança vale; se não está, é escopo novo chegando fora de hora.
Nada disso depende de o validador ficar mais esperto. Ele continua sendo outro agente, em outra missão, o que já é necessário por si só. O contrato acrescenta a fronteira do que esse outro agente tem direito de dizer.
O que fazer no seu próximo sprint
Se você já roda vibe coding com 2 agentes, o ajuste cabe no próximo planejamento. Peça ao agente que vai implementar a lista do que ele vai entregar naquele sprint, antes de liberar qualquer construção. Passe a lista ao agente que vai validar com uma pergunta só, se ela bate com a spec. E na hora de julgar, deixe claro que o validador julga a lista e nada além dela: item de fora vira assunto do próximo planejamento, não exigência no meio da obra.
É essa combinação feita antes do código que separa o vibe coding com 2 papéis de uma negociação sem fim entre eles. O mecanismo inteiro, do planejamento ao contrato fechado, dá para ver ao assistir à live.