Ideia principal

Comparar o código com a ontologia de negócio permite ver uma divergência, não dizer o que ela é. Para interpretá-la, é preciso um terceiro elemento: a intenção, ou seja, o que o desenvolvedor pediu ao agente.

Num ERP cuja ontologia diz que um pedido de venda vem obrigatoriamente de um orçamento, o Claude Code introduz a possibilidade de criar um pedido diretamente. O código e a ontologia agora estão em contradição. Se o desenvolvedor tinha pedido explicitamente que o orçamento passasse a ser opcional, o código respeita a intenção: é o modelo que precisa evoluir, e é preciso procurar os outros pontos do software que ainda pressupõem o orçamento obrigatório. Se ninguém tinha pedido isso, a mesma divergência é suspeita, e é o código que precisa ser corrigido.

A divergência é idêntica nos dois casos. Só a intenção decide entre eles.

Por que isso importa

Isso evita as duas respostas erradas e simétricas: recusar qualquer mudança que contradiga o modelo, o que engessa o produto; e aceitar tudo o que o código faz, o que transforma o modelo numa descrição complacente. Uma incoerência nem sempre é um bug: ela pode sinalizar uma transformação intencional do negócio, que o sistema precisa tornar explícita e rastreável, em vez de impedir.

Nuances e limites

A intenção nem sempre é clara. Uma solicitação ambígua não decide nada, e o comportamento certo, nesse caso, é pedir uma decisão em vez de inventar uma regra.

O dispositivo também pressupõe que a intenção esteja guardada em algum lugar — a solicitação feita ao agente, as diretrizes da tarefa — e legível no momento da verificação.

Questões em aberto

• Onde guardar a intenção de uma solicitação para que ela continue legível no momento em que a divergência é descoberta, às vezes semanas depois?