Idea principal

Verificar a posteriori el código producido por un agente frente a una ontología de negocio funciona, pero llega tarde: el agente ya ha creado clases, añadido métodos y escrito tests en torno a una mala lectura del negocio, y hay que volver sobre todo ello.

El TDD resolvió el mismo problema para el comportamiento: el test se escribe antes que el código. Trasladado al modelo del negocio, eso da al agente un orden distinto. Antes de escribir una línea, identifica los conceptos y las reglas de la ontología que toca la petición, señala las contradicciones entre la petición y el modelo, hace que se resuelvan, desarrolla y, por último, verifica que el código producido es coherente con el modelo esperado.

En un ERP donde todo pedido procede obligatoriamente de un presupuesto, la petición "permitir un pedido sin presupuesto" choca con una regla antes de que se modifique un solo archivo. La contradicción se ve en el momento en que todavía solo cuesta una decisión.

Por qué es importante

El control deja de ser una corrección para convertirse en un encuadre. El agente parte de una comprensión explícita del dominio y no de su propia interpretación, y las decisiones de negocio se toman antes de quedar codificadas.

Para ello el agente no necesita cargar toda la ontología: selecciona los conceptos, relaciones y reglas que toca la petición.

Matices y límites

La analogía con el TDD tiene un límite claro: una ontología no es una batería de tests, y un análisis hecho por un LLM no ofrece la garantía de una aserción determinista. Lo que se toma prestado es el orden de las operaciones, no la certeza del veredicto.

Una contradicción detectada de antemano no es necesariamente un error de la petición: puede anunciar una evolución buscada del negocio.

Preguntas abiertas

• ¿Cuántas de las contradicciones que el agente señala de antemano resultan, al examinarlas, falsos positivos?