Ângulo

Um modelo de domínio escrito só protege o código produzido por agentes se mantiver a sua posição entre duas derivas: congelado, ele bloqueia qualquer evolução do produto; alinhado ao código, ele chancela cada erro. O que permite que ele se sustente é um terceiro elemento, a intenção da solicitação, que separa a evolução intencional da deriva, e um ciclo que funciona nos dois sentidos: o código faz o modelo evoluir quando a intenção justifica, e o modelo enquadra o código antes que ele seja escrito.

Síntese

Os testes e a compilação verificam o comportamento que o agente acabou de escrever, não o modelo que ele deveria ter respeitado. O modelo de domínio preenche essa lacuna, mas só é útil se atuar em vários momentos: antes do código, como no TDD, para enquadrar a solicitação; durante e depois, para interpretar as mudanças do repositório; antes da integração, para gerar um relatório de coerência.

O ciclo só se sustenta com uma divisão rigorosa. O que pode ser exato — o inventário das mudanças, os invariantes transformados em testes — fica com scripts e asserções. O que exige julgamento — uma mudança de classe é uma mudança de conceito? uma divergência é intencional? — fica com o LLM, com a intenção como juiz e a prova como exigência. E cada evolução do modelo é tratada de forma explícita, versionada e ligada à sua decisão, para que o modelo continue sendo uma referência e não um espelho.

O resultado cabe numa divisão de papéis: o código faz fé sobre o comportamento implementado, a ontologia sobre o sentido de negócio, a intenção sobre o motivo pelo qual esse sentido pode mudar.

Tensões / contradições

Com a tese de que o código é a fonte da verdade: aqui, o código não deve ter razão automaticamente. A tensão se resolve por uma divisão — o código faz fé sobre o comportamento, não sobre o sentido —, mas continua real quando a intenção se perde.

Nada foi medido ainda. O volume de falsos positivos do julgamento semântico, o custo de execução e o custo de atenção humana da validação das evoluções ainda precisam ser postos à prova em evoluções reais de software.

Questões

• O ganho de coerência justifica o custo de execução e de manutenção do ciclo, e em que tipos de software?
• Como evitar que a ontologia se encha de detalhes técnicos à medida que o ciclo a alimenta a partir do código?