El hallazgo más sorprendente de la investigación reciente sobre productividad con IA no es que los asistentes de codificación puedan hacer más lentos a los desarrolladores. Es que los desarrolladores no lo notan.
El ensayo controlado aleatorizado de METR midió una desaceleración del 19 por ciento entre 16 desarrolladores experimentados de código abierto que trabajaban en 246 tareas reales en sus propios repositorios. Este es un resultado preliminar parcial de una serie de investigación en curso, con un tamaño de muestra pequeño y un contexto de tareas específico (bases de código familiares). Los participantes habían predicho una aceleración del 24 por ciento de antemano y aún creían que habían sido un 20 por ciento más rápidos después. La brecha entre percepción y medición: 39 a 44 puntos porcentuales.
Esto no es una coincidencia. Tiene una estructura. La brecha entre la autoevaluación y la medición no es un fenómeno aislado, sino sistemáticamente reproducible, enraizada en factores cognitivos y metodológicos bien conocidos.
La brecha estructural de percepción
El diseño del estudio merece un análisis más detallado. Un verdadero ECA, asignación aleatoria, grabación de pantalla, tareas reales en bases de código familiares, sin benchmarks sintéticos. Y aun así los desarrolladores no actualizaron sus creencias, incluso después de completar tareas mediblemente más lentas. La experiencia subjetiva de productividad se había desacoplado completamente del rendimiento objetivo. Los autores de METR señalan que parte de la desaceleración puede atribuirse a que los desarrolladores pasan tiempo formulando prompts, evaluando sugerencias y depurando código generado. Esa sobrecarga permanece invisible en la percepción subjetiva porque se siente como trabajo activo, no como tiempo muerto.
Este no es un hallazgo aislado. Según una encuesta de Panto, un proveedor comercial de herramientas de IA cuyos datos provienen de su propia base de usuarios, el 74 por ciento de los desarrolladores reporta sentirse más productivo con herramientas de IA. Sin embargo, las mediciones controladas regularmente no confirman ganancias equivalentes, especialmente no para desarrolladores experimentados que trabajan en bases de código complejas. La brecha entre percepción y medición no es un artefacto metodológico. Es una propiedad estructural de cómo los humanos evalúan el trabajo asistido por IA.
El sesgo de automatización amplifica el problema. Un metaanálisis de la California Management Review a través de 74 estudios encontró que los sistemas automatizados con alta pero imperfecta precisión generan sistemáticamente sobredependencia. Según este análisis, los errores de comisión aumentan un 12 por ciento y la detección de anomalías se ralentiza. Aplicado a las herramientas de codificación con IA: los desarrolladores probablemente pasan por alto más errores en la salida generada precisamente porque la tasa de precisión es lo suficientemente alta como para erosionar la vigilancia.
¿Por qué la autoevaluación falla de manera tan consistente? Las herramientas de IA reducen el esfuerzo cognitivo percibido a través de la generación de código repetitivo y el autocompletado. Esto crea una experiencia subjetiva de flujo que los desarrolladores interpretan como velocidad. El estudio de Anthropic sobre formación de habilidades, cuyos hallazgos detallados se discuten más extensamente en la sección "La deuda invisible", revela el mecanismo: los desarrolladores que delegaron mucho en la IA obtuvieron menos del 40 por ciento en pruebas de comprensión. El mismo mecanismo que se siente productivo, la reducción del compromiso cognitivo, degrada la capacidad de evaluar la propia producción. Para cualquier organización, esto significa: una evaluación de productividad con IA basada en autoinformes sobreestima sistemáticamente los beneficios.
Ganancias individuales, estancamiento sistémico
Si las autoevaluaciones de desarrolladores individuales ya no son fiables, ¿qué sucede a nivel de equipo? Los datos de telemetría de más de 10,000 flujos de trabajo de desarrolladores proporcionan una respuesta aleccionadora.
El estudio de productividad de Faros AI presenta una imagen paradójica: los desarrolladores individuales con soporte de IA fusionan un 98 por ciento más de pull requests y cierran un 21 por ciento más de tareas. Sin embargo, las métricas DORA (Deployment Frequency, Lead Time for Changes, Change Failure Rate y Time to Restore Service), los cuatro indicadores centrales del rendimiento de entrega de software, se mantienen planas a nivel organizacional. Métricas DORA planas en medio de un creciente rendimiento individual son la señal de un cuello de botella sistémico, no de una ganancia de productividad. Más producción individual no se traduce en mayor rendimiento organizacional.
La explicación reside en un desplazamiento del cuello de botella. La IA acelera la generación de código pero crea una carga abrumadora de revisión aguas abajo. El tiempo de revisión de PR aumenta un 91 por ciento en equipos con alta adopción de IA según Faros AI, impulsado por un aumento del 154 por ciento en el tamaño promedio de los PR. Los PR más grandes aumentan desproporcionadamente la carga cognitiva para los revisores. Cada unidad de producción generada por IA demanda más tiempo de evaluación humana del que ahorra.
La analogía con la manufactura es adecuada: un paso de producción más rápido antes de un paso manual de inspección de calidad no aumenta el rendimiento general. Crea un backlog de productos semiterminados. Según Faros AI, la frecuencia de despliegue permanece sin cambios incluso con un 98 por ciento más de merges.
Un factor agravante: el análisis longitudinal de GitClear registra una disminución de casi el 30 por ciento en la participación en peer review junto con una creciente adopción de IA, a pesar de que el volumen de commits aumentó un 55 por ciento. Más producción con menos revisión genera erosión de calidad descontrolada. El ROI individual de 4:1 (según Index.dev: $150 en tiempo de desarrollador ahorrado versus $37.50 por PR adicional) colapsa cuando se tiene en cuenta la sobrecarga de revisión, una tasa de error 1.7 veces mayor según Sonar y el doble de churn de código.
Deuda técnica a un ritmo sin precedentes
El problema de las métricas sistémicas planas se profundiza por la calidad del código generado en sí. Más código también significa: más deuda técnica, a un ritmo nunca antes visto.
La Encuesta de Desarrolladores 2026 de Sonar con más de 1,100 desarrolladores encontró: el código generado por IA contiene 1.7 veces más problemas totales que el código escrito por humanos. Los errores de lógica son 1.75 veces mayores, los problemas de mantenibilidad 1.64 veces, las vulnerabilidades de seguridad 1.57 veces. Un estudio presentado en IEEE ISSRE 2025 con 500,000 muestras de código y el análisis de Ox Security de 300 proyectos de código abierto son referenciados conjuntamente por InfoQ: el código de IA y el humano tienen perfiles de defectos fundamentalmente diferentes. Fallan de maneras categóricamente distintas.
El análisis de Ox Security identificó 10 antipatrones recurrentes que aparecen en el 80 al 100 por ciento del código generado por IA:
- Comentarios excesivos (90-100 por ciento)
- Patrones de libro de texto sin adaptación contextual (80-90 por ciento)
- Resistencia al refactoring (80-90 por ciento)
- Sobreespecificación para casos extremos improbables (80-90 por ciento)
- Bugs duplicados entre sesiones de generación (80-90 por ciento)
El título de su informe, "Army of Juniors", da en el clavo: la IA produce código funcionalmente competente al que le falta la sabiduría arquitectónica de ingenieros experimentados. Esto es particularmente evidente en la incapacidad de tomar decisiones técnicas en el contexto del sistema general. El código generado por IA resuelve el problema inmediato pero ignora los efectos secundarios en sistemas vecinos, abstracciones existentes y costos de mantenimiento a largo plazo.
El análisis de cinco años de GitClear de 211 millones de líneas muestra la consecuencia estructural: los repositorios intensivos en IA exhiben un déficit de refactoring acumulado un 34 por ciento mayor. "Moved Code", un proxy para un refactoring saludable, ha caído a casi cero. El código de copiar y pegar superó al código refactorizado por primera vez en 2024, un punto de inflexión en el comportamiento de evolución del código. Las bases de código crecen por acumulación en lugar de por consolidación; cada nueva funcionalidad añade capas en lugar de mejorar las estructuras existentes. Según Addy Osmani, para 2026, el 75 por ciento de los tomadores de decisiones tecnológicas ya enfrentan consecuencias moderadas a severas de esta deuda acumulada.
La deuda invisible: habilidades y criterio
Más allá de la deuda técnica, se acumula otra deuda menos visible entre los propios desarrolladores. Sus habilidades y criterio cambian en paralelo con el uso de herramientas.
La evidencia directa más fuerte proviene del ECA de 52 personas de Anthropic, documentado como fuente secundaria en InfoQ: los desarrolladores junior con soporte de IA obtuvieron un 17 por ciento peor en pruebas de comprensión (50 vs. 67 por ciento). No todo uso de IA fue igualmente dañino: quienes delegaron mucho cayeron por debajo del 40 por ciento. Quienes usaron la IA estratégicamente para preguntas conceptuales obtuvieron más del 65 por ciento. Cómo se usa la IA determina el resultado mucho más que si se usa.
El estudio identificó un bucle de retroalimentación peligroso: más delegación degrada la capacidad de monitoreo, lo que a su vez aumenta la dependencia de la IA para tareas que el desarrollador ya no puede manejar de forma independiente. El ahorro de tiempo fue insignificante, aproximadamente dos minutos por tarea. Un mal intercambio por una pérdida sostenida de competencia.
El paralelo con la complacencia de automatización en la aviación no es una metáfora: los pilotos que dependen del piloto automático durante años pierden demostrablemente sus habilidades de vuelo manual. El desarrollo de software sigue la misma dinámica, solo que sin las contramedidas regulatorias que la aviación implementó hace mucho tiempo.
Los desarrolladores junior cargan con el mayor riesgo porque son simultáneamente los usuarios más intensivos de IA y los más vulnerables a la descarga cognitiva durante las fases formativas de aprendizaje. Según Addy Osmani, los juniors logran ganancias de productividad del 35 al 39 por ciento versus el 8 al 16 por ciento para los seniors. Estas ganancias de velocidad pueden ir directamente a costa del criterio arquitectónico y la intuición de depuración que definen la ingeniería senior. Las organizaciones que optimizan para la velocidad de los juniors pueden estar debilitando su pipeline de ingeniería a largo plazo, y no notarán el daño hasta que la generación actual crezca hacia roles que demandan más de lo que aportan.
Qué funciona realmente
Ninguno de estos hallazgos significa que las herramientas de IA sean inútiles. Significan que las promesas generales de productividad no resisten la realidad y que el contexto es lo que importa.
Línea de senioridad e idoneidad de tareas
Los efectos de productividad divergen marcadamente a lo largo de la línea de senioridad. Los estudios controlados muestran ganancias del 35 al 39 por ciento para juniors según Addy Osmani, pero solo del 8 al 16 por ciento para desarrolladores experimentados. En el extremo: el ECA de METR encontró una desaceleración del 19 por ciento para expertos trabajando en sus propios repositorios, un resultado de una muestra de 16 desarrolladores en un contexto específico que no debería generalizarse fácilmente. Los seniors ya poseen el reconocimiento de patrones y el conocimiento contextual que la IA proporciona. Para los juniors, la IA llena verdaderas lagunas de conocimiento. Para los expertos, la sobrecarga de evaluación supera la ventaja de generación.
La investigación muestra límites claros de idoneidad. Según la propia encuesta de Panto entre su base de usuarios, los desarrolladores trabajan un 51 por ciento más rápido en tareas rutinarias, con hasta un 81 por ciento de ahorro de tiempo reportado para operaciones CRUD e integración de API. La IA alcanza sus límites con el desarrollo de algoritmos novedosos, la lógica de negocio compleja, las decisiones arquitectónicas y las implementaciones críticas de seguridad. El límite no está entre IA y no-IA, sino entre tareas donde los costos de error son bajos y aquellas donde pueden ser catastróficos.
Medir, no estimar
La brecha de 39-44 puntos porcentuales entre percepción y realidad descalifica la autoevaluación como base para la toma de decisiones. Quien realmente quiera saber si las herramientas de IA marcan una diferencia debe rastrear métricas DORA, tiempos de revisión y tasas de defectos, no el sentimiento de los desarrolladores. El siguiente código calcula el PR Cycle Time promedio (tiempo desde la creación del PR hasta el merge) y el tamaño del PR, ambos proxies útiles para cuellos de botella de revisión, pero a distinguir del DORA Lead Time, que comienza a contar desde el commit inicial:
# Calculate PR Cycle Time and PR size from GitHub data
# Prerequisites: GitHub CLI (gh) and jq installed
gh pr list \
--state merged \
--limit 100 \
--json number,createdAt,mergedAt,additions,deletions \
| jq '[.[] | {
pr: .number,
cycle_time_h: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
pr_size: (.additions + .deletions)
}] | {
avg_cycle_time_h: (map(.cycle_time_h) | add / length),
avg_pr_size: (map(.pr_size) | add / length)
}'
El resultado muestra cuánto tiempo permanecen abiertos los PR en promedio y cuán grandes son típicamente. Quien detecte una tendencia - tamaños de PR crecientes con frecuencia de merge estable o decreciente - está enfrentando el patrón de cuello de botella de revisión que Faros AI documentó a través de más de 10,000 flujos de trabajo de desarrolladores.
Gobernanza como requisito previo
Según DevOps.com, las empresas con inversiones en gobernanza logran resultados de IA significativamente mejores que los equipos sin marcos estructurados. Gobernanza aquí significa: escalar proactivamente la capacidad de revisión, introducir métricas de calidad específicas para IA y crear deliberadamente espacios de aprendizaje para desarrolladores junior sin delegación de IA. Los equipos que usan la IA como compañero de pair programming, con revisión activa de código y compromiso consciente con la salida generada, reportan consistentemente mejores resultados que aquellos que aceptan la salida de IA directamente y sin revisión. El modo de interacción determina el resultado: IA como compañero de pensamiento en lugar de escritor fantasma. Los workflows de desarrollo basados en agentes con pipelines Multi-Agent y Quality Gates son un enfoque concreto para implementar este tipo de gobernanza a escala.
Conclusión para los tomadores de decisiones
Las herramientas de codificación con IA no son inútiles ni el milagro de productividad generalizado que se comercializa. Su valor depende de quién las usa, para qué propósito y con qué infraestructura organizacional. Quienes ignoren esto acumulan deudas técnicas y humanas que ya se manifiestan hoy en costos de mantenimiento crecientes, backlogs de revisión en aumento y competencias de ingeniería en erosión. La pregunta crítica no es si estas consecuencias ocurrirán, sino si su organización las reconoce lo suficientemente temprano como para corregir el rumbo antes de que la escala del problema haga cualquier corrección significativa prohibitivamente costosa.