Ángulo

Un modelo del negocio escrito solo protege el código producido por agentes si mantiene su posición entre dos derivas: congelado, bloquea toda evolución del producto; alineado con el código, da por buenos todos los errores. Lo que le permite sostenerse es un tercer término, la intención de la petición, que distingue la evolución buscada de la deriva, y un bucle que funciona en ambos sentidos: el código hace evolucionar el modelo cuando la intención lo justifica, y el modelo encuadra el código antes de que se escriba.

Síntesis

Los tests y la compilación controlan el comportamiento que el agente acaba de escribir, no el modelo que debería haber respetado. El modelo del negocio cubre esa carencia, pero solo es útil si interviene en varios momentos: antes del código, como el TDD, para encuadrar la petición; durante y después, para calificar los cambios del repositorio; antes de la integración, para producir un informe de coherencia.

El bucle solo se sostiene con un reparto estricto. Lo que puede ser exacto —el inventario de cambios, los invariantes convertidos en tests— se confía a scripts y a aserciones. Lo que exige juicio —¿un cambio de clase es un cambio de concepto?, ¿una desviación es buscada?— se confía al LLM, con la intención como árbitro y la prueba como exigencia. Y cada evolución del modelo se trata de forma explícita, versionada y vinculada a su decisión, para que el modelo siga siendo una referencia y no un espejo.

El resultado se resume en un reparto de papeles: el código da fe del comportamiento implementado, la ontología del sentido de negocio, y la intención de la razón por la que ese sentido puede cambiar.

Tensiones / contradicciones

Con la tesis según la cual el código es la fuente de verdad: aquí, el código no debe tener razón automáticamente. La tensión se resuelve con un reparto —el código da fe del comportamiento, no del sentido—, pero sigue siendo real cuando la intención se ha perdido.

Todavía no hay nada medido. El volumen de falsos positivos del juicio semántico, el coste de ejecución y el coste de atención humana que exige validar las evoluciones siguen pendientes de ponerse a prueba con evoluciones de software reales.

Preguntas

• ¿Justifica la ganancia en coherencia el coste de ejecución y de mantenimiento del bucle, y en qué tipos de software?
• ¿Cómo evitar que la ontología se cargue de detalles técnicos a medida que el bucle la alimenta desde el código?