Idea principal

Cuando un agente como Claude Code implementa una funcionalidad, explora el código existente, modifica varias clases, añade funciones, escribe tests y entrega un trabajo que compila y cuyos tests pasan. Esas dos señales dicen que la implementación es técnicamente correcta. No dicen nada de su fidelidad al negocio.

Tres derivas pasan por debajo de esos dos controles. El agente puede usar un segundo nombre para un concepto que ya tenía uno: "orden de compra" junto a "pedido" en un ERP. Puede recuperar una noción que el equipo había abandonado. Puede crear una regla que contradice otra en otro punto del código: una factura validada que vuelve a ser modificable por un camino nuevo.

Ninguna de esas derivas rompe un test, porque los tests versan sobre el comportamiento que el agente acaba de escribir, no sobre el modelo del negocio que debería haber respetado.

Por qué es importante

El riesgo cambia de escala a medida que los agentes asumen una parte creciente de las modificaciones: cada tarea es una ocasión para que el agente reconstruya su propia interpretación del negocio, y las desviaciones se suman sin que ningún control existente las vea. Falta un marco de referencia común del negocio, externo al código que el agente modifica, con el que contrastar su trabajo.

Matices y límites

El fenómeno no es exclusivo de los agentes: un desarrollador humano introduce las mismas derivas. Lo que cambia es el volumen y la velocidad, y el hecho de que un agente no tiene memoria alguna de las discusiones que fijaron el vocabulario y las reglas.

Preguntas abiertas

• ¿Qué proporción de las derivas de negocio introducidas por un agente detecta realmente un revisor humano en la revisión de código?