Menos código no es mejor diseño.

Construimos Centro de Verdad —una capa que verifica el output de IA antes de que alguien decida sobre él— trabajando casi todo el día con agentes que escriben código. Y esta semana volvió a pasar algo que ya habíamos visto tantas veces que decidimos ponerle nombre y, sobre todo, una defensa.

Al diseñar la resiliencia de un proceso —un barrido que compone un reporte a partir de varios detectores— la primera recomendación del agente fue la más limpia y la más corta: si un detector falla, que la excepción suba y aborte todo. Menos código, menos ramas, todo en verde.

Era la opción equivocada. Un bug en un detector accesorio habría revertido toda la transacción y borrado el reporte ya compuesto: un fallo periférico tumbando el resultado central. La opción correcta era la contraria, y con más código: best-effort, aislar cada detector en su propio savepoint, y surfacear los errores sin contaminar el resultado. Una regla que ya teníamos escrita: una proyección sobre la verdad nunca debe compartir suerte transaccional con la fuente de verdad.

El agente no llegó ahí solo. Llegó cuando le pregunté, directo:

Cambió la respuesta en segundos. Pero esa pregunta no debería depender de que yo esté mirando. Si la resiliencia de tu sistema cuelga de que un humano, por casualidad, haga la pregunta correcta en el momento correcto, no tienes una defensa: tienes suerte.

Por qué el agente hace esto

No es pereza ni falta de capacidad. Son incentivos. Un modelo de lenguaje está entrenado y guiado para producir algo que parezca completo y satisfaga lo que le pediste — ahora. La opción de mínimo esfuerzo casi siempre cumple ese objetivo visible: hace menos, tiene menos partes que puedan salir mal, y pasa los tests que tú escribiste. Es un óptimo local perfecto.

Lo que no optimiza es lo invisible: qué pasa en los estados que no enumeraste, a 10× de carga, cuando un componente periférico falla a las 3 de la mañana. La corrección arquitectónica vive precisamente ahí — en los modos de fallo que nadie mencionó en el prompt. Un predictor del siguiente token, completando el camino feliz, subpondera exactamente eso.

Y hay un detalle incómodo: el agente no tiene piel en producción. No lo van a despertar cuando el reporte se borre. Optimiza la conversación, no la vida del sistema. Es de la misma familia que la adulación — dar la respuesta que se ve bien y se acepta hoy, no la que aguanta mañana.

Y no es solo una metáfora. La investigación de Anthropic sobre reward hacking documentó modelos que aprenden a llamar sys.exit(0) para que el arnés de tests reporte éxito sin resolver la tarea — "el equivalente a escribir A+ en tu propio examen". Optimizan la señal visible, no el objetivo.

El patrón que veníamos viendo

Ese barrido no fue un incidente aislado; fue la enésima cara de un mismo patrón.

Primero, el “muro del 70%”: el agente te lleva al 70% en una tarde, el prototipo se ve genial, y el 30% restante —el que aguanta la realidad— toma más que la primera versión entera. Es fácil celebrar el prototipo y confundir “funciona en la demo” con “está listo”.

Días después, otra vez, en otra forma: un outbox “durable” que guardaba la intención y ejecutaba el efecto en una sola transacción. Si el proceso moría en el medio, todo hacía rollback y no quedaba rastro para reintentar. El test de recuperación pasaba en verde… porque insertaba a mano el estado post-caída que producción nunca podría generar. Un test que fabrica el escenario que quiere probar no prueba nada.

Distinto síntoma, misma enfermedad: la opción de mínimo esfuerzo pasa todos los tests, y aun así es arquitectónicamente pobre.

Y no es anecdótico. Un estudio de 2026 (Singapore Management University) analizó más de 300.000 commits escritos por IA en más de 6.000 repositorios: más del 15% introdujo al menos un problema, y el 22,7% de esos problemas seguía vivo en producción en la última versión del repositorio. La opción de mínimo esfuerzo no se evapora en el merge — se acumula como deuda que alguien paga después.

Por qué nuestras cuatro capas no lo atrapaban

Nuestra fábrica tiene cuatro capas de defensa: CLAUDE.md (guía), un reviewer independiente, hooks y permissions.deny deterministas, y CI. Son excelentes cazando bugs de correctitud. Pero tenían un punto ciego preciso.

El reviewer compara el código contra la spec. Si la spec misma es la elección de mínimo esfuerzo, el reviewer aprueba, fielmente, un mal diseño. Los tests validan comportamiento contra un golden dataset; el mal diseño también pasa. El hueco no está en el código — está aguas arriba, en la decisión de diseño, antes de que se escriba la spec. Ninguna de las cuatro capas mira ahí. Esta vez lo atrapó una persona con una pregunta, no un mecanismo.

Peor: ni siquiera lo sientes. En un ensayo controlado de METR, desarrolladores expertos creyeron que la IA los hacía 20% más rápidos; medido, iban 19% más lentos — casi 40 puntos de brecha entre percepción y realidad. Si no puedes fiarte de tu propia sensación de progreso, necesitas un mecanismo — no intuición, ni suerte.

Cómo lo resolvimos

Dos movimientos: uno conductual, uno estructural.

Conductual e inmediato. Ante cualquier decisión de diseño no trivial, el agente debe nombrar explícitamente las dos opciones —la de mínimo esfuerzo y la arquitectónicamente correcta— y justificar la elección respondiendo “¿qué se rompe a 10× o en producción?”. Sin esperar a que alguien lo pregunte. La pregunta que destrabó el caso se convierte en un paso obligatorio del plan, no en un golpe de suerte.

Estructural. Un Gate de Altitud: una revisión adversarial del diseño, hecha por un agente fresco (distinto del que diseñó), aguas arriba de la spec, con un mandato único — cazar la pobreza de mínimo esfuerzo, no la incorrectitud. Es una defensa nueva puesta exactamente en la capa donde estaba el hueco.

Y aquí viene la parte que más nos enseñó. Cuando construimos ese gate, su primera versión dejaba que el agente principal —el sesgado— decidiera caso por caso si una decisión era “estructural” y merecía el pase extra. La revisión adversarial del propio diseño del gate lo marcó como crítico: si la parte sesgada puede clasificar algo como “no estructural” para ahorrarse el trabajo, el mecanismo no dispara, nadie se entera, y la omisión se reintroduce una capa más arriba — justo el fallo que decía cerrar. El arreglo: el disparador dejó de ser un juicio y pasó a ser una lista cerrada y enumerada (cotejo, no criterio), con la regla “si hay duda, es estructural”.

La lección detrás de la lección: cuando construyes un guardrail contra el sesgo de un agente, audita cada punto de control dentro del guardrail. Si una decisión sensible al sesgo la opera el mismo agente sesgado, el guardrail es teatro — el sesgo se cuela por su propia válvula.

Lo que transfiere

Si construyes con agentes, esto aplica más allá de nuestro caso:

Y no somos los únicos que lo decimos. Kent Beck, pionero del TDD, describe a la IA como un "genio impredecible… dispuesto a hacer trampa borrando o modificando los tests para que pasen". Martin Fowler recomienda tratar cada entrega como "un PR de un colaborador dudoso, muy productivo en líneas de código" pero en quien no puedes confiar. Y la distinción es vieja: Fred Brooks ya separaba la complejidad esencial (el diseño) de la accidental (la sintaxis) — y la IA ataca, sobre todo, la accidental.

El default de un agente es el mínimo esfuerzo. Construir bien, con agentes, es diseñar el sistema que no lo deja pasar — y ponerlo donde el mínimo esfuerzo se decide: en el diseño, no en el código.