La nueva deuda técnica: código que no escribiste

La deuda técnica siempre tuvo una propiedad que la hacía manejable: alguien, en algún momento, entendió el código. La persona que tomó el atajo sabía por qué lo tomaba. El código generado por IA en volumen rompe esa premisa, y eso hace que la deuda nueva sea distinta de la vieja.

El cuadrante que explica la diferencia

Martin Fowler propuso mirar la deuda técnica en dos ejes: se contrajo de forma deliberada o inadvertida, y de forma prudente o imprudente. Eso da cuatro combinaciones, y la sana es la deliberada y prudente: "sabemos que este diseño es limitado, elegimos entregar ahora y anotamos el costo".

La generación masiva por IA tiende a producir un tipo específico: inadvertida y, peor, a escala. Nadie decidió contraer la deuda, porque nadie formó el modelo mental que le habría permitido notar que la estaba contrayendo.

Deuda de comprensión

Conviene nombrarla aparte. El costo dominante no es que el código esté mal, es que nadie en el equipo sabe por qué está así.

Los síntomas típicos aparecen algunas semanas después:

• Un bug simple toma un día porque nadie entiende el camino.
• Se evita refactorizar porque el riesgo es desconocido.
• Las preguntas de review se vuelven "creo que el modelo lo hizo así porque...".

Ese costo no aparece en ninguna métrica de cobertura o complejidad. Aparece en el tiempo de resolución de defectos, meses después.

La lección que los sistemas de ML ya habían enseñado

En 2015, un trabajo influyente de Google mostró que los sistemas de aprendizaje automático cargan toda la mantención del software tradicional más un conjunto de problemas propios, entre ellos exceso de código de pegamento, selvas de pipelines, deuda de configuración y el hecho de que tocar cualquier cosa cambia todo.

La analogía con la IA generativa en desarrollo es casi directa. El código que integra el modelo, maneja prompts, parsea la salida y lidia con fallos suele crecer sin diseño, exactamente como el código de pegamento descrito allí. Y rara vez tiene dueño.

Dónde se acumula más rápido la deuda

Tres lugares concentran el problema:

1. Manejo de errores copiado. Bloques de captura genéricos y repetidos que se tragan la excepción y esconden la causa raíz.
2. Duplicación en vez de abstracción. Es más fácil volver a pedir que descubrir que ya existe una función para eso. Los análisis de repositorios vienen señalando aumento de duplicación y caída de reutilización a medida que los asistentes se popularizan.
3. Pruebas que confirman la implementación. Una prueba generada a partir del código prueba lo que el código hace, no lo que debería hacer. Pasa siempre, incluso cuando el comportamiento está mal.

Controlarla sin prohibir la herramienta

El objetivo no es usar menos IA, es mantener la deuda en el cuadrante deliberado.

Exige modelo mental en la revisión. Una pregunta estándar en la plantilla de PR resuelve buena parte: "explica en dos frases por qué esta solución funciona". Si quien abrió el PR no puede, el código todavía no está listo para entrar, sin importar quién lo escribió.

Mide mantenibilidad, no solo cobertura. La ISO/IEC 25010 descompone la calidad en características, y la mantenibilidad tiene subcaracterísticas útiles para decidir qué seguir: modularidad, reusabilidad, analizabilidad, modificabilidad y testeabilidad. Elegir dos y medirlas vale más que discutir calidad en abstracto.

Anota la deuda cuando sea deliberada. Un comentario corto diciendo qué se simplificó y por qué convierte deuda inadvertida en prudente, que es la que el equipo sí logra pagar después.

Revisa la capa de integración con más rigor. Ahí es donde se acumula el código de pegamento, y es la parte que menos suele tener pruebas.

Qué significa esto para tu equipo

Agrega la pregunta de explicación a la plantilla de pull request esta semana. Es la intervención de menor costo y mayor efecto, porque ataca la deuda de comprensión en su origen.

Elige dos subcaracterísticas de mantenibilidad y empieza a seguir una tendencia, aunque sea gruesa: duplicación y tiempo medio de resolución de defectos sirven bien. Compara el trimestre antes y después de la adopción.

Y trata la capa que integra el modelo como código de producción de verdad, con dueño, pruebas y revisión, y no como un script que alguien pegó para que la demo funcionara.