La deuda técnica invisible: el iceberg que la IA está metiendo a tu repo mientras no volteas

La deuda técnica invisible: el iceberg que la IA está metiendo a tu repo mientras no volteas

No toda la deuda técnica es consciente. La IA genera código tan rápido que nadie lo lee — y eso es una clase nueva de deuda: invisible, no decidida, no trackeada.

Hay dos tipos de deuda técnica.

La primera es la que decides. “Este módulo lo refactorizamos el próximo sprint.” La documentas, la metes al backlog, la justificas en la retro. Es deuda con nombre y apellido. Incómoda, pero honesta.

La segunda es la que nadie decide. Sucede mientras estás por café.

Tu AI generó 400 líneas. Ningún humano las revisó de verdad. El build pasó verde. El PR se aprobó. Y ahora ese bloque vive en producción — lógica que nadie en el equipo entiende del todo, sin tests suficientes, con patrones que contradicen los seis meses de arquitectura que construiste antes.

Eso no es deuda técnica visible. Eso es deuda técnica invisible.

Y ya nos mordió la mano.


Por qué es peligrosa de una forma diferente

Decidí nombrarla así porque no tenía nombre. La industria lleva décadas con infraestructura para manejar la deuda consciente — Ward Cunningham la formuló en 1992, Martin Fowler la catalogó, SonarQube la cuantifica. Hay herramientas, métricas, ceremonias enteras diseñadas para el código que sabes que está mal.

No hay nada para el código que nadie sabe que está mal porque nadie lo escribió conscientemente.

La deuda técnica invisible tiene tres características que la hacen especialmente peligrosa:

No fue decidida. La deuda visible es el resultado de una elección deliberada. La invisible no pasó por ninguna mente humana. Fue generada, aceptada por el CI, y desplegada. La decisión nunca existió.

No está trackeada. No hay ticket en Jira. No hay comentario // TODO. No hay nada que señale que ese bloque es un riesgo. Está ahí, mezclado con el código bueno, invisible exactamente por su nombre.

Escala más rápido que la deuda visible. Un desarrollador que toma atajos conscientes tiene un límite cognitivo — hay un número de malas decisiones que puede tomar por día. Un AI que genera código no tiene ese límite. Puede producir kilobytes de deuda invisible por minuto.


Cómo reconocer que ya la tienes

Tres señales que ya he visto en cientos de equipos:

1. Nadie puede explicar por qué se implementó así. Preguntas en code review y la respuesta es: “el AI lo generó así y el test pasó.” No hay razonamiento detrás de la decisión — porque nunca hubo decisión.

2. El refactor tarda el triple de lo esperado. Cuando vas a tocar ese código, descubres que tiene dependencias implícitas que nadie documentó. El AI conectó puntos que parecían razonables localmente pero que forman una red frágil a nivel sistema.

3. Los bugs aparecen en lugares “imposibles”. El módulo nuevo, el que el AI escribió en 20 minutos, rompe un comportamiento en un módulo viejo que aparentemente no tiene relación. La deuda invisible es el puente oculto entre ambos.


No es un problema de velocidad. Es un problema de elevar el nivel.

Tengo 30 años en esto. He trabajado con cientos de equipos, desde startups de 3 personas hasta empresas que mueven millones de transacciones por día. Y nunca, en ningún proyecto, vi documentación completa. Pero sí vi algo peor: equipos convencidos de que estaban siendo productivos mientras acumulaban complejidad que nadie entendía.

Con IA, ese patrón se acelera exponencialmente.

La promesa que nos vendieron fue: el AI escribe código, tú lo revisas. Hermosa en teoría. En la práctica: el AI escribe código, tú lo lees por encima porque el build pasó, el linter no se quejó, y tienes otras doce pull requests esperando.

Ahí nace la deuda invisible.

No es que el AI programe mal. Es que programa rápido, y la velocidad sin governance es un caballo desbocado. Poderoso. Útil. Pero sin arnés, simplemente destruye.

La solución no es volver a programar lento. Es elevar qué hace el humano.

Llevamos décadas diciéndoles a los desarrolladores que su trabajo es escribir código. No lo es. Su trabajo es tomar decisiones de arquitectura — el código es solo la expresión de esas decisiones. El AI puede generar el código. Pero la decisión de qué construir, por qué así, y qué compromisos implica esa implementación — eso no es delegable. Eso es lo que separa a un arquitecto de un albañil.

Y aquí está el problema: cuando el AI genera código sin governance, convierte a los arquitectos en albañiles de revisión. En lugar de diseñar, validan línea por línea. O peor: confían en que el CI haga la validación por ellos.


Cómo gobernamos esto en RaiSE

En RaiSE, atacamos la deuda invisible desde el proceso, no desde el código.

Cada historia tiene un scope commit antes de empezar. Cada tarea tiene un plan antes de ejecutar. Cada sesión cierra con una retrospectiva que captura lo que aprendimos — y lo que detectamos que podría volverse un problema más adelante.

El mínimo contexto viable no es un prompt largo — es una ontología. Una estructura que le dice al AI qué patrones aplicar, qué decisiones ya fueron tomadas, qué no reinventar. Sin esa ontología, el AI improvisa. Y la improvisación a escala es deuda invisible en formación.

Los arneses determinísticos sobre capacidades probabilísticas son exactamente eso: las reglas que el AI no puede violar, el perímetro dentro del cual puede ser creativo. Un AI que no puede tomar ciertas decisiones por sí solo no es un AI limitado — es un colaborador confiable.

Llevamos 360+ sesiones aplicando esto. No solo para clientes: usamos RaiSE para construir RaiSE. Cada historia nueva pasa por el mismo proceso que le recomendamos a los equipos. Cuando detectamos que estamos generando código que nadie va a entender en seis meses, paramos. Lo nombramos. Lo trackeamos.

El resultado no es velocidad aparente. Es velocidad real: una historia de usuario en 20 minutos, con plan, con tests, con scope claro, con un registro de las decisiones tomadas y por qué.


La deuda invisible ya está en tu repo

No va a desaparecer. Es una consecuencia directa de la velocidad que la IA da, y esa velocidad no va a ralentizarse.

Lo que sí puede cambiar es cómo la gobiernan.

Si tu equipo usa AI para generar código y no tiene un proceso claro de scope, de decisiones de arquitectura explícitas, de retrospectivas que capturen lo que aprendieron — está acumulando deuda invisible ahora mismo. Mientras lees esto.

No es un problema de AI.

Es un problema de governance.

Y ese problema sí tiene solución.