Idea principal

Mantener al día una ontología de negocio frente al código exige dos operaciones de naturaleza distinta, que hay que separar.

La primera es mecánica: determinar con precisión qué ha cambiado. Un script lee el historial de Git y enumera las funciones, clases, interfaces, módulos, firmas de API y contratos expuestos mediante MCP que se han añadido, modificado o eliminado. Una herramienta como Tree-sitter permite analizar la estructura sintáctica para identificar los elementos afectados.

La segunda es semántica: entender si esos cambios introducen, modifican o contradicen un concepto de negocio. Una clase no es necesariamente un concepto; un paquete nuevo puede no ser más que una reorganización; una función puede implementar una regla sin constituir un concepto. Ahí interviene un LLM, que contrasta el inventario con la ontología y con la petición que puso en marcha el desarrollo, y clasifica cada cambio: concepto nuevo, concepto que cambia de sentido, conceptos que han dejado de ser coherentes, vocabulario que diverge o cambio puramente técnico.

Por qué es importante

La separación hace sostenible el control. No se pide a un LLM que relea toda la aplicación en cada modificación: se concentra su análisis en lo que el script ha señalado. Y la parte que puede ser exacta lo es, en lugar de confiarse a un modelo que podría aproximarla.

Protege también la ontología de la arquitectura: el script describe la estructura técnica, el LLM decide qué pertenece al dominio, y ni una arquitectura hexagonal ni un código desordenado imponen su división al modelo del negocio.

Matices y límites

Un cambio de negocio real puede no dejar ninguna huella en los nombres: una condición modificada dentro de una función que no cambia escapa a un inventario basado en los símbolos. Y el juicio semántico produce falsos positivos cuyo volumen todavía se desconoce.

Preguntas abiertas

• ¿Cómo detectar una modificación de negocio que no cambia ningún nombre de clase, de función ni de firma?