Idea principal

Comparar el código con la ontología de negocio permite ver una desviación, no decir qué es. Para calificarla hace falta un tercer término: la intención, es decir, lo que el desarrollador pidió al agente.

En un ERP cuya ontología dice que un pedido procede obligatoriamente de un presupuesto, Claude Code introduce la posibilidad de crear un pedido directamente. El código y la ontología quedan en contradicción. Si el desarrollador había pedido explícitamente que el presupuesto fuera opcional, el código respeta la intención: es el modelo el que debe evolucionar, y hay que buscar los demás puntos del software que todavía suponen que el presupuesto es obligatorio. Si nadie lo había pedido, la misma desviación es sospechosa, y lo que hay que corregir es el código.

La desviación es idéntica en ambos casos. Solo la intención permite decidir entre ellos.

Por qué es importante

Evita las dos malas respuestas simétricas: rechazar todo cambio que contradiga el modelo, lo que congela el producto, y aceptar todo lo que hace el código, lo que convierte el modelo en una descripción complaciente. Una incoherencia no siempre es un bug: puede señalar una transformación deliberada del negocio, que el sistema debe hacer explícita y trazable en lugar de impedirla.

Matices y límites

La intención no siempre está clara. Una petición ambigua no permite decidir nada, y lo correcto entonces es pedir una decisión en lugar de inventarse una regla.

El dispositivo supone además que la intención se conserve en algún sitio —la petición hecha al agente, las directrices de la tarea— y sea legible en el momento de la verificación.

Preguntas abiertas

• ¿Dónde conservar la intención de una petición para que siga siendo legible cuando se descubre la desviación, a veces semanas después?