Hace seis meses, un equipo fintech con el que trabajo envió un servicio de autenticación en tres días. Claude generó la mayor parte, el ingeniero senior que lo propuso lo revisó y aprobó, y el servicio superó todas las pruebas. Funcionó.

El mes pasado, otro miembro del equipo tuvo que modificar la lógica de refresco del token. Pasó cuatro días leyendo código que tardó tres días en construir. No porque el código fuera malo. El formato era limpio, la denominación era consistente, las pruebas eran exhaustivas. No podía modificarla porque no podía explicar por qué estaba estructurada de esa manera. Las decisiones eran invisibles, la arquitectura implícita, y el ingeniero que impulsó la generación original se había trasladado a otro equipo sin documentar el razonamiento.

El servicio funciona, nadie lo entiende y la base de código tiene seis meses.

La deuda que no tiene nombre

La deuda técnica tradicional es un código que entiendes pero eliges construir mal. Tomaste el atajo deliberadamente, sabes dónde está y sabes lo que cuesta arreglarlo. La deuda de comprensión es diferente. No se acumula en el código, sino en la organización: en el hueco entre lo que hace una base de código y lo que cualquier miembro vivo del equipo puede explicar sobre por qué lo hace así.

Cuando la IA genera código, la salida suele verse excelente a nivel de función. Formato limpio, nombres consistentes, buena estructura. Un revisor que echara un vistazo a un método individual concluiría que es un trabajo sólido. Pero el revisor no puede ver qué consideró y rechazó el agente de IA, no puede ver las alternativas arquitectónicas que fueron implícitamente eliminadas, no puede rastrear la cadena de razonamiento que produjo esta estructura específica sobre otra igualmente válida.

Nada del código cambió entre el día que se envió y el día que alguien tuvo que modificarlo. Lo que cambió fue la relación del equipo con él: el ingeniero que tenía el modelo mental se fue, el contexto que existía en la cabeza de alguien desapareció y ningún artefacto lo preservó. La deuda reside en el conocimiento organizacional compartido, no en la base de código en sí, y eso la hace fundamentalmente diferente de la deuda técnica.

La encuesta de desarrolladores de Stack Overflow de 2026 encontró que el 76 % de los desarrolladores que usan herramientas de programación con IA declararon generar código que no entendían completamente al menos en parte del tiempo. No principiantes. Desarrolladores experimentados. La propia investigación de Anthropic (febrero de 2026) mostró que los ingenieros asistidos por IA obtuvieron un 17 % menos en los cuestionarios de comprensión post-tarea, con la mayor brecha en habilidades de depuración.

La velocidad de generación crea un problema de acumulación. Cada sprint que lanza código generado por IA sin puntos de control explícitos de comprensión añade a una base de código donde la proporción de «código que existe» y «código que alguien puede explicar» se dispersa cada vez más. Los datos de GitClear muestran que la rotación de código se duplicó y la clonación de código se cuadruplicó desde que las herramientas de programación con IA se generalizaron. Carnegie Mellon encontró que la complejidad aumentó un 25 por ciento en los repos que adoptaron Cursor, a pesar de las ganancias de velocidad. La velocidad es real. La brecha de comprensión también es real, y se agrava.

El Modelo de Triple Deuda

Para mayo, el patrón ya se había manifestado en tres enfrentamientos distintos, y necesitaba un nombre para él. Empecé a llamarlo deuda de comprensión: código que funciona pero existe fuera del modelo mental de cualquiera. Poco después, Margaret-Anne Storey y colaboradores de la Universidad de Victoria publicaron un marco en ACM Queue que daba estructura académica a lo que los profesionales habían estado descubriendo empíricamente.

Su Modelo de Triple Deuda sostiene que la deuda técnica por sí sola es insuficiente para razonar sobre la salud del software en la era de la IA. El marco que yo construía a partir de la observación, ella lo hacía a partir de la investigación.

Ambos describen problemas estrechamente relacionados en diferentes niveles: la deuda cognitiva es el fenómeno organizativo; La deuda de comprensión es cómo los profesionales la experimentan en la entrega diaria de software.

Tres deudas interactúan:

La deuda técnica reside en el código. Atajos de arquitectura, compromisos de calidad de código, mantenimiento diferido. Esta es la deuda que conocemos. Disponemos de herramientas para medirlo, procesos para abordarlo y un vocabulario compartido para discutirlo.

La deuda cognitiva vive en las personas. Es la erosión de la comprensión compartida en un equipo, donde nadie puede explicar con confianza cómo funciona un sistema ni predecir el impacto de un cambio. Antes de la IA, la deuda cognitiva se acumulaba lentamente, normalmente cuando los ingenieros clave se marchaban o la documentación se podría. La IA lo aceleró drásticamente porque ahora el código entra en la base de código sin que nadie construya el modelo mental que habría creado escribirlo desde cero.

La deuda de intención reside en artefactos externalizados: las especificaciones ausentes, registros de decisiones, restricciones y justificaciones que explican para qué sirve el sistema y guían cómo debería evolucionar. Cuando un desarrollador escribe código manualmente, la intención está parcialmente incrustada en el historial de confirmación, las discusiones de PR y los documentos de diseño. Cuando la IA genera código a partir de un prompt, el prompt en sí es el único registro de la intención, y los prompts suelen ser efímeros.

La tesis central de Story es que la IA acelera la acumulación de los tres, y que cada deuda amplifica a las demás. La deuda técnica empeora la deuda cognitiva porque el código mal estructurado es más difícil de entender. La deuda cognitiva empeora la deuda de intención porque los equipos que no entienden un sistema no pueden articular qué debería hacer a continuación. La deuda por intención empeora la deuda técnica porque, sin especificaciones claras, la IA genera código que es localmente correcto pero globalmente incoherente.

La lista de colaboradores parece un quién es quién del pensamiento de ingeniería de software: Kent Beck, Martin Fowler, Adam Tornhill, Russell Miles, Marian Petre, Mary Shaw, Dave Thomas. La convergencia de esas voces en un único modelo sugiere que la industria reconoce el problema aunque aún no tenga la solución.

A qué se corresponde esto en la práctica

Las prácticas existentes ya abordan partes del problema. El Modelo de Triple Deuda se corresponde perfectamente con lo que los equipos ya están haciendo y dónde permanece la brecha:

La deuda por intención tiene soluciones emergentes. La ingeniería de intención primero, donde haces que la intención sea un entregable antes de que la IA genere código, convierte la especificación en la entrada, no en la ocurrencia posterior. La elaboración de grupos (una práctica estructurada para esto) es una versión. Los Registros de Decisiones de Arquitectura conservan el razonamiento. Las especificaciones de protección empresarial incorporan restricciones en el contexto de generación. No son teóricas: los equipos que articulan la intención primero generan código que otros humanos pueden modificar después, porque el «por qué» es explícito.

La deuda técnica ha establecido herramientas. Las prefases brownfield que reestructuran las bases de código para la legibilidad de la IA (la elevación de código es un enfoque) abordan específicamente sistemas donde la IA no puede operar eficazmente porque la estructura existente es demasiado ambigua. El trabajo de Tornhill sobre la salud del código y la literatura más amplia sobre refactorización abarca este tema.

La deuda cognitiva no tiene un ritual equivalente. Y ese es el problema sin resolver.

Ayuda con revisiones de arquitectura, ayuda con ADRs, ayuda con documentación estructurada. Pero ninguno de estos es un ritual de deuda cognitiva como la Elaboración de Mob es un ritual de deuda de intención. No tenemos una práctica repetible a nivel de equipo que reconstruya la comprensión después de que la IA genera código a gran escala. Storey propone «Tours y Puntos de Paso Cognitivos» como dirección, pero es aguas arriba y sin probar.

El problema de la asimetría de velocidad

Un equipo que lanza código generado por IA durante seis meses sin una práctica de comprensión acumula una deuda cognitiva que habría tardado tres años en acumularse bajo el desarrollo manual. Doscientos economistas, dieciséis laureados con el Nobel e investigadores de todos los principales laboratorios de IA firmaron la semana pasada una declaración argumentando que la IA comprime décadas de adaptación institucional en años. Hablaban de economías, pero la misma compresión se aplica a nivel de código. La deuda es del mismo tipo, nadie entiende cómo funciona el sistema, pero la línea temporal se vino abajo. El coste del rescate no se redujo con ella.

El equipo fintech con el que empecé ahora está pasando cuatro meses de ingeniería en lo que llaman un «sprint de comprensión»: leer su propio código de seis meses, escribir la documentación que debería haber existido, registrar las decisiones arquitectónicas que nunca se tomaron explícitamente. Cuatro meses de remediación para seis meses de generación. Y su base de código es pequeña.

Lo que aún no sabemos

Ese coste de remediación es la cantidad conocida. Lo que aún se desconoce es si la deuda puede evitarse a gran escala o solo gestionarse después.

No tengo un marco ordenado para rescatar una base de código donde la deuda cognitiva ya se haya acumulado a velocidad de IA. La respuesta honesta es que nadie lo hace. El Modelo de Triple Deuda nombra el problema con precisión, pero no lo resuelve.

Lo que sabemos funciona para la prevención: articular la intención antes de la generación, limitar el alcance con decisiones explícitas de arquitectura y exigir que la persona que solicitó el código pueda explicarlo a alguien que no lo hizo. Estas son decisiones metodológicas, no de herramientas, y funcionan porque crean comprensión como subproducto del proceso estructurado.

Lo que no sabemos es cómo adaptar la comprensión a una base de código que se construyó sin ella. La elevación de código aborda la deuda técnica en sistemas brownfield, pero la remediación de deuda cognitiva es un problema completamente diferente porque ese conocimiento no existe en ningún sitio. No puedes extraer comprensión del código que se generó sin él.

Pasamos décadas aprendiendo a gestionar la deuda técnica. La IA puede obligarnos a aprender a gestionar la deuda de comprensión en una fracción de ese tiempo. Ese ritual de la deuda cognitiva, la práctica repetible que reconstruye el entendimiento compartido después de que la IA genere código a gran escala, es hacia lo que estoy trabajando. Todavía no lo tengo. Pero nombrar el problema con precisión es el primer paso para resolverlo.

Ricardo