Ideia principal

Verificar depois, contra uma ontologia de negócio, o código produzido por um agente funciona, mas tarde demais: o agente já criou classes, adicionou métodos e escreveu testes em cima de uma leitura errada do negócio, e é preciso voltar em tudo isso.

O TDD resolveu o mesmo problema para o comportamento: você escreve o teste antes do código. Transposto para o modelo de domínio, isso dá ao agente uma ordem diferente. Antes de escrever uma linha, ele identifica os conceitos e as regras da ontologia que a solicitação afeta, aponta as contradições entre a solicitação e o modelo, faz com que sejam resolvidas, depois desenvolve e, por fim, verifica se o código produzido se sustenta diante do modelo esperado.

Num ERP em que todo pedido de venda precisa obrigatoriamente vir de um orçamento, a solicitação "permitir um pedido sem orçamento" esbarra numa regra antes que qualquer arquivo seja alterado. A contradição fica visível no momento em que ainda custa só uma decisão.

Por que isso importa

A verificação deixa de ser uma correção e passa a ser um enquadramento. O agente parte de um entendimento explícito do domínio, e não da sua própria interpretação, e as decisões de negócio são tomadas antes de serem codificadas.

Para isso, o agente não precisa carregar a ontologia inteira: ele seleciona os conceitos, as relações e as regras que a solicitação afeta.

Nuances e limites

A analogia com o TDD tem um limite claro: uma ontologia não é uma suíte de testes, e uma análise feita por um LLM não oferece a garantia de uma asserção determinística. O que a gente aproveita é a ordem das operações, não a certeza do veredito.

Uma contradição apontada antes do código não é necessariamente um erro da solicitação: ela pode anunciar uma evolução intencional do negócio.

Questões em aberto

• Quantas das contradições apontadas de antemão pelo agente acabam se revelando, depois de examinadas, falsos positivos?