O que mudou na entrega: engenharia com agentes de IA

Meus 21 anos de carreira — 15 em governança financeira corporativa e 6 em engenharia de software — me deram um critério único para julgar qualquer mudança: o que ela altera no balanço. A entrada dos agentes de IA na entrega de software passa por esse critério sem dificuldade, e é por isso que acho a discussão improdutiva quando ela sai da pergunta útil. Ninguém precisa acreditar que agentes escrevem código. A pergunta é o que acontece com a atividade de revisão quando a quantidade de código plausível deixa de ser o recurso escasso.

Quando comecei, a entrega era limitada por três coisas ao mesmo tempo: digitar, revisar e ter contexto de domínio. A digitação deixou de ser o gargalo, e o contexto de domínio nunca esteve escrito em lugar nenhum — sempre morou em quem revisava. O que continua escasso é atenção de revisão, e esse recurso não aparece em nenhum dashboard. É por isso que a entrega mudou de forma: não porque escrever ficou mais rápido, mas porque revisar ficou mais caro.

A unidade de trabalho deixou de ser o diff

Um diff grande não é uma entrega grande, é um custo de leitura grande. Com agentes, a tentação natural é delegar a implementação e revisar no fim. Funciona até a primeira vez em que a revisão deixa de ser leitura e vira auditoria, porque ninguém no processo tem contexto sobre por que cada decisão foi tomada. O que posso delegar com segurança é a implementação; o critério de aceitação nunca é delegável.

Verificação substituiu autoria

Durante décadas, autoria era o sinal de qualidade: quem escreveu, entendeu. Com agentes, o sinal mais forte passa a ser o teste que prova o comportamento. A assimetria é favorável à engenharia: escrever 300 linhas de teste é muito mais barato que escrever 3.000 de implementação, e é exatamente o inverso do que a pressa promote. O ofício não encolheu; deslocou-se para o artefato que o código não pode substituir.

1. Escreva a asserção antes de delegar. Sem critério de aceitação executável, um agente otimiza para parecer correto — e parecer correto é o modo de falha mais difícil de detectar em code review.
2. Trate a suíte de testes como especificação executável. É o único artefato que sobrevive à regeneração do código, e o único que um auditor aceita sem refazer o trabalho.
3. Automatize o que você não quer revisar. Uma verificação barata e automática vale mais que um bloco de código revisado com atenção parcial.

O custo por tentativa é uma linha do demonstrativo

Um agente que chama uma API de terceiros, executa inferência paga ou toca um sistema de produção cobra por tentativa. E retry, nesse contexto, não é recuperação: é despesa. Na contabilidade isso se chama custo por tentativa, e é exatamente o número que desaparece quando a entrega parece gratuita.

O antídoto não é disciplinear o time, é tornar a tentativa visível: orçamento por operação, idempotência onde existe efeito colateral e custo registrado no mesmo caminho da métrica de latência. Onde o time não consegue enxergar o custo, ele não consegue reduzi-lo.

Contexto é o novo gargalo de design

Antes, o design vivia no código e na cabeça de quem desenhou. Agora ele precisa viver no enunciado — o que é uma melhora, porque enunciado escrito e revisado é melhor que design implícito. Também é mais trabalho, e trabalho que não pode ser pulado. Um agente entrega exatamente o escopo que foi descrito, nem mais nem menos. A qualidade do escopo passa a ser a qualidade da entrega.

tarefa:
  contexto: "<o domínio em três linhas>"
  invariantes:
    - "<o que não pode quebrar>"
  interface: "<assinatura pública, sem detalhe interno>"
  exemplos:
    - "<entrada> -> <saída esperada>"
  nao_fazer:
    - "<o que está fora do escopo>"
  aceitacao: "<o comando que prova que terminou>"

O item que a maioria dos prompts esquece é o nao_fazer. Sem ele, o agente otimiza por parecer completo e entrega refatoração, cobertura extra e abstração que ninguém pediu. Escopo declarado é o equivalente, na engenharia, de uma reconciliação: sem ela, qualquer número parece bonito e não significa nada.

O que não mudou

A responsabilidade pelo resultado continua sendo de uma pessoa, e a diferença é que essa pessoa agora precisa entender o suficiente para discordar. Quem não consegue avaliar o que foi gerado não deveria estar aprovando o que foi gerado. Isso valia há cinco anos; agora vale ainda mais, porque a quantidade aprovada é muito maior.

• O dono do resultado. Assinar o merge é assumir o comportamento em produção, inclusive o que o agente sugeriu.
• A contabilidade da decisão. Toda mudança é um passivo com juros. Agente não altera essa equação; só aumenta a velocidade com que se contrai o passivo.
• O ofício de revisar. Julgar código com rigor leva anos e não terceiriza para uma máquina que gera código plausível mais rápido do que se lê.

A soma é simples: 15 anos me ensinaram a ler demonstrativo, 6 anos a ler código. A combinação me faz desconfiar de qualquer promessa de que a atividade técnica deixou de exigir julgamento. Ela passou a exigir mais julgamento por unidade de código, e é por isso que a próxima década vai pertencer a quem sabe escolher o que revisar.