GitClear: la AI acelera los releases de código, pero aumenta la 'deuda de comprensión' y los riesgos ocultos

Los asistentes de IA aceleran el desarrollo, pero cada vez dejan atrás código que funciona formalmente, pero esencialmente nadie entiende. Esto lo indican tanto los datos de GitClear como la experiencia de equipos que han descubierto un nuevo riesgo oculto: "deuda de comprensión".

Qué Encontró GitClear

En el estudio de GitClear de 2025, analizaron 211 millones de líneas de código modificadas durante 2020–2024. La señal principal: code churn, es decir, líneas reescritas dentro de dos semanas después de un commit, comparado con la línea de base anterior a la IA de 2021, prácticamente se ha duplicado. Al mismo tiempo, la proporción de refactorización y reutilización de código disminuyó, y la duplicación se volvió más frecuente que antes. En términos simples, los equipos producen más código, pero una parte significativa de ese volumen rápidamente vuelve para rehacerse. Esto es importante no solo como métrica de calidad, sino como problema de gestión.

En marzo de 2026, el ingeniero de Google Addy Osmani describió esto como deuda de comprensión — la brecha entre el volumen de código en un sistema y el volumen de código que el equipo realmente comprende. En la superficie, todo se ve bien: CI está verde, la cobertura no cae, los PRs se fusionan más rápido. Pero en el primer incidente inusual, resulta que nadie puede explicar rápidamente por qué la lógica está organizada de esa manera.

"La IA genera código más rápido de lo que las personas pueden evaluarlo."

Por Qué las Pruebas Fallan

La trampa principal es que la IA a menudo escribe no solo la función en sí, sino también las pruebas para ella. Como resultado, el equipo verifica que la implementación coincida con la implementación, no cómo debería funcionar la lógica de negocio. Con un ejemplo simple de webhook, esto parece inofensivo: la prueba confirma que un pedido cambia el estado a paid.

Pero puede no verificar la ausencia de order_id, reentrega de eventos, nuevo estado en la API de pago, o una situación donde el sistema devuelve 200 aunque el pedido no se encuentre en absoluto. Tales pruebas crean una falsa sensación de confiabilidad. Aumentan la cobertura, se ven bien en los informes y permiten cerrar tareas más rápido, pero no reemplazan el entendimiento de restricciones de dominio y casos extremos.

Esto es especialmente notorio en nuevas tecnologías. En enero de 2026, Anthropic publicó un experimento con 52 desarrolladores Python que estudiaban la biblioteca Trio: el grupo con asistencia de IA mostró un resultado 17% peor en la prueba de comprensión que el grupo sin IA. Mientras tanto, los que mejor se desempeñaron no fueron quienes delegaron el código completamente, sino quienes usaron el modelo para preguntas de "por qué" y "qué pasaría si".

Cómo Reducir el Riesgo

La práctica muestra que la IA por sí sola no garantiza ni fracaso ni éxito. El proceso que la rodea se vuelve decisivo. Si un equipo acepta PRs enormes, no requiere explicaciones y considera que las pruebas verdes son fundamento suficiente para fusionar, casi inevitablemente acumulará código difícil de mantener. Si los estándares de revisión permanecen estrictos, la IA comienza a traer beneficios sin un crecimiento brusco del caos.

• Dividir los cambios grandes en PRs pequeños que realmente puedan ser leídos y discutidos
• Requerir que el autor explique las soluciones y documente explícitamente las suposiciones sobre lógica de negocio
• Escribir pruebas antes de la implementación o al menos separar la verificación de intención de la verificación del happy path generado
• Agregar reglas modulares, verificaciones automáticas y documentación actualizada para que la IA funcione dentro del contexto del proyecto

La paradoja es que la IA puede ser no solo una fuente de problemas, sino también una herramienta para resolverlos. Estos mismos modelos explican bien el código legacy antiguo, ayudan a encontrar condiciones olvidadas e iluminan puntos débiles en la arquitectura. Es decir, el "código sin autor" existía antes, es solo que la IA aumentó drásticamente el volumen de cambios e hizo que esta deuda sea notoria no años después, sino casi inmediatamente después de la fusión.

Qué Significa Esto

Para los equipos, el objetivo no cambia, pero el criterio de calidad sí. Ganan no quienes producen líneas más rápido, sino quienes mantienen la comprensión del sistema mientras aumentan la velocidad. Si la IA ya está escribiendo una parte significativa del código, la habilidad principal se convierte no en generación, sino en verificación, explicación y la capacidad de arreglarlo a la medianoche bajo presión de incidente. Esto es exactamente lo que separa acelerar el desarrollo de acelerar problemas futuros.