Deuda técnica por código de IA: lo que muestran los datos

La deuda técnica es el trabajo extra que una solución rápida impone a los cambios posteriores. En el desarrollo asistido por IA crece de forma medible más rápido: según el análisis de GitClear, la proporción de bloques de código duplicados pasó de un valor de índice de 40,3 en 2023 a 73,0 en 2026, mientras que la proporción de código desplazado, la mejor aproximación disponible a una limpieza real, bajó del 21 % (2022) al 3,8 % (2026).

¿Qué es la deuda técnica?

El concepto procede de Ward Cunningham y describe una ponderación deliberada: se entrega más rápido eligiendo una solución poco limpia y se pagan intereses en forma de trabajo adicional en cada cambio futuro. Lo decisivo de la imagen original es la palabra deliberada: una deuda que se contrae es una deuda que se conoce.

Eso es justo lo que ha cambiado. Cuando surge código que nadie ha leído, la deuda no se contrae, se pasa por alto. Solo aparece cuando alguien quiere cambiar algo.

¿Con qué rapidez crece la deuda técnica por código de IA?

Más rápido que antes, y las pruebas son ya sólidas. Para el informe «The Maintainability Gap», GitClear analiza cientos de millones de cambios de código. Tres indicadores son relevantes para esta cuestión.

Ambos movimientos van juntos. Para un modelo de lenguaje, duplicar es el camino más natural: ve el fragmento que debe modificar, no los otros tres lugares donde el mismo patrón ya existe. Y la refactorización exige comprender el conjunto, justo lo que falta cuando nadie ha leído lo existente.

¿Por qué es caro el código duplicado?

Porque cada copia es un lugar donde se puede olvidar una corrección. No es una cuestión de estilo, sino de aritmética.

Si una comprobación existe cuatro veces en lugar de una, un error debe corregirse cuatro veces. Si se pasa por alto un lugar, se produce un comportamiento correcto en tres sitios e incorrecto en uno: el tipo de error más caro, porque solo aparece bajo ciertas condiciones y no se puede reproducir en las pruebas.

A ello se suma el esfuerzo de búsqueda: quien deba cambiar una regla tiene que averiguar primero cuántas veces aparece en lo existente. Con una tasa de duplicados creciente, este esfuerzo aumenta con cada cambio.

¿Cómo noto que mi proyecto ha acumulado deuda técnica?

Por cinco observaciones cotidianas que no requieren medición: son señales previas, no pruebas, pero rara vez aparecen sin motivo.

• Las estimaciones dejan de ser fiables. Si un «cambio pequeño» tarda con regularidad tres días, no se debe a la estimación, sino a que nadie sabe de antemano qué depende todavía de él.
• Las correcciones generan nuevos errores. La señal clásica de los duplicados: se corrigió un lugar, tres no.
• Se evitan ciertos archivos. Si en el equipo se sabe qué archivo «nadie toca», es una factura impagada con nombre propio.
• Las nuevas incorporaciones tardan un tiempo inusual. El tiempo de incorporación es una buena aproximación de la comprensibilidad.
• Se omiten pruebas porque «de todos modos a veces están en rojo». Una prueba poco fiable es peor que ninguna: consume una confianza que luego falta.

Estos cinco puntos sirven mejor que cualquier indicador para abrir la conversación con la dirección, porque todo el mundo los ha vivido ya.

¿Cómo mido la deuda técnica en mi proyecto?

Con cuatro indicadores que se obtienen del repositorio y de las herramientas existentes, sin un producto nuevo.

• Proporción de duplicados. Cualquier análisis estático habitual la ofrece. Lo interesante no es el valor absoluto, sino la tendencia a lo largo de los meses.
• Frecuencia de cambio frente a complejidad. Los archivos que se tocan a menudo y son complejos son sus puntos más caros. Ambas cosas juntas dan una lista de prioridades sin discusión.
• Proporción de líneas modificadas sin pruebas. No la cobertura total, sino la cobertura de lo nuevo. Detalles en el artículo sobre la cobertura de pruebas.
• Antigüedad y número de dependencias. Si la lista crece más rápido que el equipo, ya nadie la tiene a la vista.

Qué otras métricas sirven y cuáles solo tranquilizan se trata en el artículo Medir la calidad del código.

¿Qué ayuda contra la deuda técnica del código de IA?

Tres medidas, en este orden; la tercera es la única que detiene la entrada.

• Hacerla visible. Proporción de duplicados y cobertura de pruebas de lo nuevo en el pipeline, con histórico. Lo que no se mide, se discute.
• Reducirla de forma selectiva. No limpiar en todas partes, sino donde coinciden la frecuencia de cambio y la complejidad. El procedimiento está en el artículo Refactorización de código generado por IA.
• Limitar la entrada. Un umbral en el pipeline que rechace nuevos duplicados y código nuevo sin pruebas. Sin este paso, usted achica agua con el grifo abierto. Véase Quality Gates en el pipeline.

Preguntas frecuentes sobre la deuda técnica

¿Es siempre mala la deuda técnica?

No. Una deuda contraída deliberadamente puede ser correcta, por ejemplo cuando una fecha de mercado importa más que la solución limpia. El problema son las deudas que nadie ha contraído y que, por ello, no aparecen en ninguna planificación.

¿No es la caída de la refactorización simplemente un artefacto de medición?

GitClear mide el código desplazado como valor aproximado, no la refactorización directamente: es una limitación real. Pero la magnitud de la caída, del 21 al 3,8 % en cuatro años, no se explica solo con eso, y el aumento simultáneo de duplicados apunta en la misma dirección.

¿Puede la IA ayudar a reducir la deuda técnica?

Sí, y es uno de sus usos más sólidos: encontrar duplicados, aplicar cambios de nombre de forma coherente, completar pruebas que faltan. El requisito es una cobertura de pruebas que detecte un error; de lo contrario, sustituye deudas visibles por errores invisibles.

¿Cómo convenzo a la dirección de que reserve tiempo para ello?

Con la frecuencia de cambio en lugar de con la proporción de duplicados. «Estos cinco archivos se modificaron 200 veces en el último trimestre y son los más complejos» es un argumento de costes. «La proporción de duplicados ha aumentado» es una discusión técnica.

Reducir deuda sirve de poco mientras la entrada siga abierta. Por eso Code Guardian revisa cada cambio inmediatamente después de generarlo en busca de redundancia y duplicados, antes de que pase a formar parte de lo existente.

Fuentes

• GitClear, The Maintainability Gap: 2026 AI Code Quality Research: fuente de todos los indicadores de la tabla anterior.
• Ward Cunningham, formulación original de la metáfora de la deuda (OOPSLA 1992).

Fecha: 27 de julio de 2026. Valoración técnica general, no una evaluación de un proyecto concreto.