El 41% del código que se produjo en 2025 fue generado o asistido por IA. Eso ya no es una proyección — es el punto de partida. Y ese código trae 1.7x más defectos por PR que el código escrito por humanos, según el análisis de CodeRabbit sobre 470 pull requests. Errores de lógica suben 75%. Vulnerabilidades de seguridad, entre 1.5x y 2x. Problemas de rendimiento, casi 8x.

Hay un dato adicional que desafía la narrativa de productividad: el estudio controlado de METR encontró que desarrolladores experimentados de open-source fueron 19% más lentos usando herramientas de IA — mientras creían que eran 20% más rápidos. Rechazaron más del 56% de las sugerencias.

Como señaló Aakash Gupta en un análisis reciente, respondiendo a la observación de Arvid Kahl de que los desarrolladores siempre han escrito código malo: sí, siempre hubo código malo. Pero la infraestructura de calidad — code review, CI/CD, blame chains, ownership — se diseñó para un mundo donde el autor entendía su propio código. Ese mundo ya terminó.

El problema no es que la IA genere mal código. Es que todo el sistema de revisión y gobernanza asume algo que ya no es cierto: que quien envía el código puede explicarlo.

El sistema que dejó de funcionar

La infraestructura de calidad del software se construyó sobre tres pilares. Los tres dependen de la misma suposición, y los tres están fallando.

El code review asume que el autor puede explicar su código

Un code review efectivo es una conversación. El revisor pregunta “¿por qué usaste este patrón aquí?” y el autor explica su razonamiento. Si hay un error, el autor sabe dónde buscar porque tomó las decisiones que llevaron a ese punto.

Con código generado por IA, esa conversación no existe. El que envía el PR pegó la salida de Copilot, Cursor o Claude. El revisor ve código que nadie en el equipo escribió. No hay razonamiento que explicar porque no hubo razonamiento humano — hubo una predicción estadística de tokens.

Esto conecta directamente con los riesgos del vibe coding a nivel organizacional que hemos documentado antes: cuando un individuo acepta código sin entenderlo es un riesgo personal. Cuando un equipo entero acepta código que nadie entiende a través de un proceso formal de revisión, es un riesgo sistémico.

CI/CD testea regresiones, no corrección

Tu pipeline de CI/CD fue diseñado para responder una pregunta: “¿este cambio rompe algo que ya funcionaba?” Los tests verifican regresiones contra comportamiento conocido. El linting verifica estilo. SAST busca patrones de vulnerabilidad conocidos.

Ninguno verifica si el código nuevo es correcto. Ninguno pregunta: “¿esta lógica hace lo que debería hacer en casos que el autor no consideró?” Con código humano, esa brecha era manejable porque el autor cubría los casos borde que conocía. Con código generado por IA, los casos borde que no se cubrieron son los que la herramienta no predijo — y nadie más los conoce tampoco.

“Tests pass” siempre significó “no rompimos lo que había.” Nunca significó “el código nuevo es correcto.” La diferencia es que ahora esa brecha es mucho más ancha.

La cadena de trazabilidad tiene un eslabón roto

git blame muestra quién hizo el commit. En el modelo tradicional, eso equivalía a quién escribió y entendió el código. Esa equivalencia se terminó.

Cuando un auditor pregunta “¿quién revisó este cambio y por qué se aprobó?”, la respuesta honesta muchas veces es: “alguien aceptó la sugerencia de la IA y otro alguien aprobó el PR sin entender completamente el código.” Eso no es una falla individual — es un proceso que ya no produce el resultado que se supone que debe producir.

La accountability, la respuesta a incidentes, las auditorías de cumplimiento — todo depende de una cadena de trazabilidad que ahora tiene un vacío. No sabes quién entendió el código, solo quién lo aceptó.

Lo que vemos en empresas que ya tienen este problema

En nuestra experiencia en IQ Source trabajando con equipos de desarrollo, estos patrones aparecen consistentemente:

PRs que se aprueban porque nadie quiere admitir que no entiende el código. El revisor ve código que parece razonable, los tests pasan, y aprobarlo es más fácil que preguntar “¿puedes explicarme esta lógica?” cuando ambos saben que la generó Copilot. El incentivo social empuja hacia la aprobación, no hacia la comprensión.

Cobertura de tests que se ve saludable pero testea las cosas equivocadas. La IA genera código y también genera tests. Esos tests validan lo que la IA predijo que el código haría — no lo que el sistema necesita que haga. Cobertura del 85% que no cubre los escenarios de negocio que importan.

Tiempos de respuesta a incidentes que aumentan porque el on-call no escribió el código y el “autor” no puede explicarlo. Esto conecta con lo que hemos analizado sobre la brecha de fluidez en equipos que usan IA: la diferencia entre quienes integran herramientas de IA con criterio y quienes las usan como sustituto de entendimiento se amplifica bajo presión.

Deuda técnica invisible. El código generado por IA tiende a resolver el problema inmediato de maneras que se ven correctas pero que introducen dependencias innecesarias, abstracciones que no alinean con la arquitectura existente, o patrones duplicados porque la herramienta no tenía contexto del resto del codebase. Esa deuda no aparece en ningún linter.

Qué necesita cambiar

Revisión de código adaptada a la generación por IA

El code review necesita pasar de “¿este código se ve correcto?” a “¿el autor puede demostrar que entiende este código?”

Tres cambios concretos:

• Anotaciones de “por qué”: Cada PR debe incluir no solo qué hace el código, sino por qué se eligió ese enfoque sobre alternativas. Si la respuesta es “porque eso sugirió la IA”, eso es información valiosa que el revisor necesita saber.
• Revisión secundaria para PRs con alta generación por IA: Cuando un PR tiene un porcentaje alto de código generado, debe pasar por un segundo revisor que se enfoque específicamente en comprensión, no solo en funcionalidad.
• Preguntas de comprensión obligatorias: El revisor debe hacer al menos una pregunta sobre manejo de casos borde. No como formalidad — como filtro real. Si el autor no puede responder sin consultar la herramienta, eso indica un gap de entendimiento que debe resolverse antes del merge.

Quality gates para código generado por IA

Los gates tradicionales siguen siendo necesarios, pero ya no son suficientes. El escaneo de seguridad es necesario pero no es suficiente — necesitas gates que validen lo que los tests convencionales no cubren.

Gate tradicional	Gate adaptado para código IA
Unit tests (¿pasa las pruebas?)	Testing conductual (¿funciona en escenarios reales del negocio?)
Cobertura de código (¿cuánto se testeó?)	Mutation testing (¿los tests detectan errores reales?)
Linting (¿sigue el estilo?)	Consistencia arquitectónica (¿encaja con el diseño del sistema?)
SAST (¿tiene vulnerabilidades conocidas?)	Análisis de dependencias (¿introduce patrones o abstracciones innecesarias?)

El mutation testing en particular: si alteras una línea del código y todos los tests siguen pasando, esos tests no están validando nada. Con código generado por IA, donde los tests y el código vienen de la misma fuente, esta validación es crítica.

Modelo de ownership explícito por módulo

Cada módulo, servicio o componente necesita un owner humano que pueda responder tres preguntas:

1. ¿Qué hace este código y por qué lo hace así?
2. ¿Qué pasa si falla?
3. ¿Cómo lo cambiarías si los requerimientos cambian?

Si el owner no puede responder sin consultar la herramienta de IA, no es realmente el owner — es un intermediario. Y los intermediarios no pueden hacer debugging a las 3 AM cuando el servicio se cae.

Esto no significa que no se pueda usar IA para generar código. Significa que alguien tiene que pasar de “acepté la sugerencia” a “entiendo este código lo suficiente como para mantenerlo, corregirlo y evolucionarlo.”

El costo de no adaptar el proceso

El dato clásico del IBM Systems Sciences Institute sigue aplicando: corregir un defecto en producción cuesta ~30x más que corregirlo en desarrollo. Cuando tu código generado por IA trae 1.7x más defectos y tu proceso de revisión no está calibrado para detectarlos, estás multiplicando riesgo por costo.

Pero el costo más grande no es el técnico. Es el operacional:

• Respuesta a incidentes degradada: Cuando el on-call tiene que entender código que nadie del equipo realmente escribió, el MTTR sube. Minutos de más en producción significan impacto en clientes, SLAs y revenue.
• Riesgo de cumplimiento: Cuando un auditor de SOC 2 o ISO 27001 pregunta “¿quién revisó este código y cómo se validó su seguridad?”, y tu respuesta depende de un proceso de review que no fue diseñado para verificar comprensión, tienes un gap de compliance.
• Attrition silenciosa: Los mejores desarrolladores saben cuándo un proceso de calidad dejó de funcionar. Si tu equipo senior empieza a frustrarse con PRs que se aprueban sin entendimiento real, los pierdes.

Cómo saber si tu organización ya tiene esta brecha

Si más del 30% de tu código nuevo viene de herramientas de IA y tu proceso de revisión no ha cambiado en los últimos dos años, tienes un gap de gobernanza. No es hipotético — es aritmético.

Las señales: PRs que se aprueban en menos de 15 minutos para cambios de más de 200 líneas. Cobertura de tests que sube pero bugs en producción que no bajan. Tiempos de resolución de incidentes que aumentan trimestre a trimestre. Ownership difuso donde nadie puede explicar módulos enteros sin recurrir a la IA.

En IQ Source auditamos procesos de desarrollo — no solo el código, sino cómo se revisa, se testea y se despliega. Si tu equipo está generando código con IA pero evaluándolo con procesos de 2020, la conversación que necesitas tener no es sobre qué modelo de IA usar. Es sobre si tu infraestructura de calidad todavía funciona.

Hablemos sobre tu proceso de desarrollo →