Tu equipo está entregando código más rápido que nunca. Las gráficas de velocidad del sprint apuntan hacia arriba y a la derecha. Los pull requests — paquetes de cambios de código propuestos para revisión — pasan la aprobación como mantequilla por sartén caliente. El PM le da el crédito a las herramientas de IA para programar. Todos asienten. La vida es bella.

Excepto que los tickets de bugs van en aumento. Los reverts — cuando deshaces un cambio porque rompió algo — ocurren cada vez más seguido. El backlog crece. Nadie conecta los puntos porque el dashboard dice que la están rompiendo.

El 30 de marzo de 2026, un equipo de investigadores de la Singapore Management University publicó el estudio empírico más grande jamás realizado sobre la calidad del código generado por IA. Analizaron 304,362 commits verificados como escritos por IA (cambios de código confirmados como provenientes de herramientas de IA) en 6,275 repositorios de GitHub, cubriendo cinco herramientas principales: GitHub Copilot, Claude, Cursor, Gemini y Devin. El período: enero de 2024 a octubre de 2025.

Lo que encontraron debería bajarle el volumen a tu celebración de velocidad.

En esos repositorios, los investigadores identificaron 484,606 problemas distintos. De esos, el 89% eran code smells — patrones que funcionan hoy pero pudren el código mañana. Casi el 6% eran bugs en tiempo de ejecución. Y el 5.1% eran vulnerabilidades de seguridad. Entre el 15% y el 29% de los commits de IA introdujeron al menos un problema, dependiendo de la herramienta. Gemini se llevó la corona con 28.7%. Copilot marcó 17.3% — mejor, pero sigue siendo uno de cada seis commits llegando con equipaje.

Y aquí viene lo bueno: el 24.2% de esos problemas introducidos por IA seguían vivos en la última versión del código. Las vulnerabilidades de seguridad tenían una tasa de supervivencia del 41.1% — la más alta de cualquier categoría. Para febrero de 2026, el estudio rastreó más de 110,000 problemas sobrevivientes que la IA puso ahí y que los humanos nunca limpiaron. Los investigadores lo dijeron sin anestesia: los asistentes de IA corrigen aproximadamente la misma cantidad de code smells que crean, pero "crean más bugs y problemas de seguridad de los que resuelven".

Un día antes, el 29 de marzo, Exceeds AI publicó datos de benchmark que encuadran por qué esto importa a nivel organizacional. Su análisis sitúa el ratio seguro de código IA en 25–40% del output total — el rango donde los equipos ven ganancias genuinas de productividad del 10–15% sin ahogarse en retrabajo. ¿El promedio global actual? 41–42%. Ya pasaron la línea. Los equipos con más del 40% de código IA muestran tasas de retrabajo 20–25% más altas. Y aquí está la paradoja de productividad que debería quitarle el sueño a todo engineering manager: los desarrolladores sienten que son 20% más rápidos pero en realidad miden 19% más lentos cuando cuentas la sobrecarga de revisión, debugging y correcciones.

La velocidad percibida sube. El throughput real baja. El dashboard miente.

El 6 de abril, la investigadora Margaret-Anne Storey de la University of Victoria le puso nombre a este problema en un nuevo paper. Lo llama "Deuda Cognitiva" — la erosión del entendimiento compartido dentro de un equipo. Cuando la IA genera código más rápido de lo que los desarrolladores pueden comprender, el equipo pierde la capacidad de modificar su propio sistema de forma segura. No es solo deuda técnica (código desordenado que arreglarás después). Es deuda de conocimiento — nadie entiende completamente qué hace el codebase.

Nada de esto significa que debas dejar de usar herramientas de IA para programar. Las ganancias de productividad son reales, y el genio no va a volver a la lámpara. Pero la pregunta que tu equipo debería estar haciéndose no es "¿cuánto código puede escribir la IA por nosotros?" sino "¿cuánto código generado por IA puede realmente sostener nuestro proceso de revisión y cobertura de tests sin que todo se vaya al carajo?"

La velocidad siempre fue una métrica de vanidad — un número que se ve impresionante pero no te dice si estás construyendo algo sólido. Ahora, sin un denominador de calidad, es una métrica peligrosa. Tu gráfica del sprint va hacia arriba y a la derecha. Tu conteo de bugs también. Misma gráfica. Historia completamente distinta.