Ideia principal

Quando um agente como o Claude Code implementa uma funcionalidade, ele explora o código existente, altera várias classes, adiciona funções, escreve testes e entrega um trabalho que compila e cujos testes passam. Esses dois sinais dizem que a implementação está tecnicamente correta. Não dizem nada sobre a fidelidade dela ao negócio.

Três tipos de deriva passam por baixo dessas duas verificações. O agente pode usar um segundo nome para um conceito que já tinha um — "ordem de venda" ao lado de "pedido de venda" num ERP. Ele pode trazer de volta uma noção que a equipe tinha abandonado. Ele pode criar uma regra que contradiz outra, em outro ponto do código: uma fatura validada que volta a ser editável por um caminho novo.

Nenhuma dessas derivas quebra um teste, porque os testes tratam do comportamento que o agente acabou de escrever, não do modelo de domínio que ele deveria ter respeitado.

Por que isso importa

O risco muda de escala à medida que os agentes assumem uma parte cada vez maior das alterações: cada tarefa é uma oportunidade para o agente reconstruir a sua própria interpretação do negócio, e as divergências vão se somando sem que nenhuma verificação existente as enxergue. Falta um referencial comum do negócio, externo ao código que o agente altera, com o qual confrontar o trabalho dele.

Nuances e limites

O fenômeno não é exclusivo dos agentes: um desenvolvedor humano introduz as mesmas derivas. O que muda é o volume e a velocidade, e o fato de que um agente não tem nenhuma memória das discussões que fixaram o vocabulário e as regras.

Questões em aberto

• Que proporção das derivas de negócio introduzidas por um agente um revisor humano realmente percebe no code review?