Vibe coding é caça-níquel. Engenharia com agentes é disciplina.

Aprovei um diff de agente porque a suíte ficou verde. Três dias depois, um caso que nenhum teste cobria derrubou um fluxo de estorno em produção. O código estava certo pela única medida que eu tinha olhado, e errado pela única que importava.

A ficha caiu ali: o que eu chamava de trabalho não era engenharia, era caça-níquel. Eu puxava a alavanca do prompt, torcia pra sair verde e tratava o verde como prova. Funciona até o dia em que não funciona, e aí a conta chega com juros.

A diferença não está na ferramenta

Vibe coding e engenharia com agentes usam o mesmo modelo, o mesmo editor, muitas vezes o mesmo prompt inicial. Quem olha de fora não distingue. A separação é invisível porque ela é de método, não de stack.

Vibe coding é prompt-and-pray: você descreve, o agente gera, você lê por cima, roda, e se passou, mergeia. É ótimo pra protótipo, pra explorar, pra descartar. O problema começa quando esse mesmo gesto atravessa a fronteira da produção sem trocar de roupa.

Engenharia com agentes é o gesto oposto. O agente é rápido e confiante, e confiança sem verificação é exatamente o perfil de quem você não deixa mergear sozinho. Então você monta a verificação em volta dele.

Spec antes, não depois

O primeiro corte é escrever a spec antes do prompt. Não um parágrafo vago, mas o contrato: o que a função aceita, o que ela recusa, o que nunca pode acontecer. Estorno não excede o valor pago. Idempotência na retry. Erro de rede degrada, não corrompe.

Sem isso, o agente inventa o contrato pra você, e ele inventa o mais fácil de satisfazer, não o mais certo. Um diff verde contra um contrato que o próprio agente escolheu é um espelho, não um teste.

O loop que passei a exigir

Depois do estorno, parei de aprovar diff no olho. Montei três travas, e nenhuma delas é ferramenta nova:

• Dataset de eval, não suíte de teste. Teste prova um caso conhecido. Eval roda o comportamento contra dezenas de casos, inclusive os adversariais que eu de propósito escrevi pra quebrar, e me dá uma taxa de acerto, não um verde binário.
• Revisão de diff obrigatória, linha a linha, com a pergunta certa. Não “compila?”, e sim “o que este diff faz quando a entrada é hostil?”.
• Fronteira explícita em volta da saída do agente, do mesmo jeito que eu trato qualquer integração instável.

Uma linha de eval vale mais que a intenção:

// eval: um contrato que o agente não pode quebrar, nem nos casos que escrevi pra derrubar
test('estorno nunca excede o valor pago', () =>
  expect(refund(order).amount).toBeLessThanOrEqual(order.paid));

A pergunta deixa de ser “passou no teste?” e vira “com que frequência acerta, e o que acontece nas vezes em que erra?”.

Isso não desacelera o agente. Desacelera a minha vontade de acreditar nele.

O que a disciplina compra

O verde de uma suíte responde uma pergunta pequena: este caso específico, que alguém lembrou de escrever, ainda passa. Ele não diz nada sobre os casos que ninguém escreveu, e é sempre um desses que chega em produção.

Vibe coding aposta que os casos que faltam não vão aparecer. Engenharia com agentes assume que vão, e transforma essa suspeita em dataset, em revisão, em fronteira. A ferramenta é a mesma. O que muda é se você está operando uma máquina ou puxando uma alavanca.

Caça-níquel paga às vezes. É esse “às vezes” que engana.