El código que genera la IA acumula más deuda técnica que el que escribe una persona: qué exigir antes de contratar desarrollo con estas herramientas

Un pull request escrito con ayuda de IA trae, en promedio, 1.7 veces más issues que uno escrito por una persona: 10.83 contra 6.45, según el informe de CodeRabbit publicado en diciembre de 2025, que analizó 470 pull requests reales en GitHub. Si tu empresa está por contratar desarrollo (propio o con un proveedor) donde el equipo usa agentes de IA para programar, ese medio punto de diferencia no es una curiosidad académica: es el tamaño del trabajo extra que alguien tiene que revisar antes de que ese código llegue a producción.

La adopción ya no es marginal. Según la encuesta 2025 de Stack Overflow, 84% de los desarrolladores usa o planea usar herramientas de IA para programar, frente a 76% en 2024. El problema no es que la IA escriba código: es que la velocidad con la que lo escribe superó a la velocidad con la que los equipos lo revisan.

Los números detrás de la alarma

El informe de CodeRabbit no es el único que documenta la brecha. Tres estudios distintos, con metodologías distintas, llegan a la misma dirección:

• CodeRabbit (diciembre de 2025). Sobre 470 pull requests (320 con coautoría de IA, 150 escritos solo por personas), el código con IA tuvo hasta 2.74 veces más issues de seguridad y 75% más errores de lógica y corrección.
• Cortex, "Engineering in the Age of AI" (2026). El benchmark de Cortex encontró que los pull requests por desarrollador subieron 20% con asistencia de IA, pero los incidentes por pull request subieron 23.5% y la tasa de fallos por cambio subió cerca de 30% en el mismo periodo.
• Universidad Carnegie Mellon, "Speed at the Cost of Quality" (MSR 2026). El estudio siguió 806 repositorios de GitHub que adoptaron Cursor entre enero de 2024 y marzo de 2025, comparados contra 1,380 repositorios de control, con un diseño de diferencias en diferencias. Los avisos de análisis estático subieron 30.26% y la complejidad del código subió 41.64%. La ganancia de velocidad, en cambio, fue pasajera: llegó a su pico en el primer mes y se disolvió en dos meses, mientras la deuda técnica se quedó.

A esto se suma un cambio de comportamiento medible en el propio código. GitClear analizó 623 millones de cambios de código entre 2023 y 2026 y encontró que el porcentaje de código refactorizado cayó de 21% en 2022 a 3.8% en lo que va de 2026, mientras el código copiado y pegado subió de 9.4% a 15.7% y los bloques de código duplicado crecieron 81% en tres años. Traducido: cada vez es más barato pedirle a un agente que genere código nuevo y más caro conseguir que alguien lo reorganice para que el siguiente cambio no sea más difícil que el anterior.

El resultado ya aparece en las decisiones de presupuesto. Según el reporte "The tech debt reckoning" del IBM Institute for Business Value, 81% de los ejecutivos consultados dice que la deuda técnica ya frena los resultados de sus proyectos de IA, y 69% cree que puede volver financieramente inviables algunas iniciativas, al sumar entre 15% y 22% al tiempo de entrega.

Por qué el código con IA acumula deuda más rápido

No es que el modelo escriba peor sintaxis. Los tres estudios apuntan a un mismo mecanismo: un agente de IA no tiene memoria del resto del sistema ni incentivo para simplificar. Genera la función que resuelve el caso que le pediste, con el patrón más común en sus datos de entrenamiento, sin preguntarse si ya existe una función parecida tres archivos más abajo. Una persona que conoce el proyecto sí se hace esa pregunta, aunque sea por costumbre.

Por eso el estudio de Carnegie Mellon encuentra que la velocidad inicial es real (hasta 281% más líneas añadidas en el primer mes) pero se revierte: la complejidad acumulada termina frenando la velocidad futura entre 50% y 64%, según los propios autores. El ahorro de tiempo al escribir se convierte en tiempo perdido al mantener.

Esto no vuelve inútil a la IA como herramienta de programación. Vuelve inútil la idea de que basta con activarla y esperar que el equipo entregue más rápido sin cambiar nada del proceso de revisión.

Qué debe exigir quien contrata desarrollo con IA de por medio

Si vas a contratar desarrollo, propio o con proveedor, y sabes que el equipo usa agentes de IA para programar (la mayoría hoy lo hace, lo digan o no en la propuesta), esto es lo que conviene pedir como condición, no como buena intención:

1. Revisión humana obligatoria antes de cada merge, sin excepción por "es un cambio menor". El propio informe de CodeRabbit muestra que los errores de lógica en código con IA no son más visibles a simple vista: aparecen 75% más seguido y a veces pasan la primera lectura.
2. Métricas de calidad por sprint, no solo de avance. Pide ver issues por pull request, no solo pull requests cerrados. Un proveedor que solo reporta velocidad está reportando la mitad del dato.
3. Un dueño humano identificado por módulo del sistema, alguien que responda si algo se rompe, aunque el código lo haya generado un agente.
4. Pruebas automatizadas como puerta de entrada, no como documentación posterior. Si el pull request no pasa pruebas, no se revisa, y mucho menos se aprueba.
5. Cláusula de soporte y evolución posterior a la entrega, con responsabilidad explícita sobre la deuda que el propio desarrollo generó. Aquí es donde una operación de soporte, evolución y hosting bien planteada evita que la factura de mantenimiento llegue sin nadie que la explique.

Nada de esto es exclusivo de proyectos con IA. Es lo que cualquier práctica de ingeniería seria pedía antes. La diferencia es que ahora, con la velocidad de generación que da un agente, saltarse estos pasos cuesta más rápido de lo que costaba hace tres años.

Dónde esta alarma no aplica

No todo código necesita el mismo nivel de escrutinio, y tratar un prototipo interno con las mismas exigencias que un sistema de nómina es un desperdicio de tiempo. Un script de un solo uso, un prototipo para validar una idea con un cliente, o una prueba de concepto que se va a desechar en semanas no necesitan la misma revisión que un sistema que va a vivir cinco años en producción. Exigir el mismo proceso de gobernanza en ambos casos frena lo que debería ser rápido sin proteger nada que valga la pena proteger.

Tampoco es una razón para prohibir el uso de IA en desarrollo, ni para exigirle a un proveedor que jure no usarla. Los mismos estudios que documentan el problema muestran que el código con IA, bien revisado, no es peor: el estudio de Carnegie Mellon encontró que los repositorios que mantuvieron disciplina de revisión no mostraron la misma acumulación de complejidad que los que no la tuvieron. El punto no es rechazar la herramienta. Es no asumir que "usamos IA" ya es sinónimo de "vamos más rápido y no pasa nada".

Y si tu decisión no es sobre un proyecto nuevo sino sobre construir equipo propio frente a apoyarte en un proveedor externo, vale la pena leer la nota sobre cuándo construir equipo propio y cuándo apoyarte en una plataforma ya construida: la respuesta cambia según qué tanto control de calidad puedas ejercer tú mismo sobre el código que entra a tu sistema.

Si estás evaluando un contrato de desarrollo y quieres que la revisión de código y el control de calidad queden por escrito desde la propuesta, construimos esas condiciones dentro del proceso de desarrollo, no como un paso opcional al final.

Fuentes

• CodeRabbit, "State of AI vs Human Code Generation Report" (diciembre de 2025)
• Cortex, "Engineering in the Age of AI: 2026 Benchmark Report"
• He et al., "Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects", MSR 2026, arXiv
• IBM Institute for Business Value, "The tech debt reckoning"
• GitClear, "The AI Code Quality Maintainability Gap" (2026)
• Stack Overflow, "2025 Developer Survey", sección de IA