El muro del 10%: por qué la productividad con IA se estanca

DX encuestó a 121.000 desarrolladores en 450 empresas. El 92,6% usa asistentes de programación con IA al menos una vez al mes. El código generado por IA representa ahora el 26,9% de las fusiones en producción. Los desarrolladores reportan un ahorro de aproximadamente cuatro horas por semana.¹ La productividad no ha superado el 10%.

Esa cifra se ha mantenido estable durante tres trimestres consecutivos.^{1 2} La adopción creció. El volumen de código creció. Las herramientas mejoraron. Las ganancias no. Laura Tacho, CTO de DX, lo planteó directamente: “Esto es realmente un problema de gestión. El entusiasmo hizo que pareciera que simplemente probar IA daría resultados automáticamente.”³

El informe DORA 2025 encontró la divergencia. Las organizaciones con prácticas de ingeniería sólidas vieron cómo la IA amplificaba sus fortalezas existentes. Las organizaciones con prácticas débiles vieron cómo la IA amplificaba sus disfunciones existentes. Las mismas herramientas. Resultados opuestos. El informe concluyó: “El rol principal de la IA en el desarrollo de software es el de un amplificador. Magnifica las fortalezas de las organizaciones de alto rendimiento y las disfunciones de las que tienen dificultades.”⁴

El muro no es un problema de modelos. Es un problema de infraestructura. Mejores modelos no atravesarán un muro construido con verificación ausente, contexto ausente y gobernanza ausente. Los artículos complementarios a este describen la arquitectura: Anatomy of a Claw explica la capa de orquestación, The Fabrication Firewall explica la puerta de salida, y Context Is Architecture explica el sistema de inyección de contexto. El artículo a continuación explica por qué existen esos sistemas.

Resumen

121.000 desarrolladores encuestados, 92,6% de adopción, productividad estancada en 10%. Tres causas raíz explican el techo: inanición de contexto (la IA adivina sin conocimiento del proyecto), vacío de verificación (el código se entrega más rápido de lo que la revisión se adapta) y brecha de gobernanza (la IA elude los estándares que los humanos aplican). DORA encontró que la IA amplifica tanto las fortalezas como las disfunciones dependiendo de la infraestructura que la rodea.⁴ Superar el muro requiere infraestructura alrededor de la IA, no mejor IA. Este artículo documenta un intento N=1 de construir esa infraestructura, con cifras específicas de un sistema que ejecuta 84 hooks, 43 skills y 19 agentes.

Lo que dice la encuesta

El conjunto de datos de DX abarca 4,2 millones de desarrolladores observados entre noviembre de 2025 y febrero de 2026, con un panel detallado de 121.000 desarrolladores en 450 empresas.¹ Los números cuentan dos historias.

La historia de adopción es inequívoca. Los asistentes de programación con IA alcanzaron una penetración casi universal. DX midió un 92,6% de adopción mensual y aproximadamente un 75% de uso semanal.¹ La encuesta de Stack Overflow de 2025 encontró que el 84% de los desarrolladores usan o planean usar herramientas de IA.⁶ JetBrains midió un 85% de uso regular entre 24.534 desarrolladores en 194 países.⁷ El techo de adopción está cerca.

La historia de productividad se ha estancado. DX midió un promedio de cuatro horas ahorradas por semana, sin cambios respecto a las 3,6 horas del trimestre anterior.^{1 2} El código generado por IA pasó del 22% al 26,9% del código fusionado, pero el volumen adicional no se tradujo en producción adicional.^{1 2} Laura Tacho identificó la matemática: los desarrolladores dedican aproximadamente el 20% de su tiempo a escribir código. Una mejora del 10% sobre el 20% de la jornada laboral es una mejora del 2% en total. “La velocidad de escritura nunca ha sido el cuello de botella.”⁸

La fila crítica es la última. El informe DORA de 2024 encuestó a 39.000 profesionales y encontró que por cada 25% de aumento en la adopción de IA, el rendimiento de entregas disminuyó un estimado de 1,5% y la estabilidad de entregas disminuyó un 7,2%.⁵ El informe DORA de 2025 encontró que la relación IA-rendimiento pasó de la correlación negativa observada en 2024 a una positiva, pero la estabilidad de entregas siguió asociada negativamente con la adopción de IA.⁴ La adopción de IA continuó correlacionándose con mayor inestabilidad incluso cuando el rendimiento mejoró.

La divergencia importa más que los promedios. METR estudió a 16 desarrolladores experimentados de código abierto trabajando en 246 issues reales de repositorios y encontró que tardaron un 19% más con herramientas de IA que sin ellas.⁹ El ensayo controlado aleatorizado de Google con 96 ingenieros encontró una mejora de velocidad del 21%, pero el resultado no fue estadísticamente significativo (IC del 95% cruzó el cero).¹⁰

McKinsey encontró ganancias del 35-50% en tareas simples pero menos del 10% en tareas de alta complejidad, y los desarrolladores junior que usaban IA fueron un 7-10% más lentos en un estudio con 40 de sus propios desarrolladores.¹¹ El patrón: la IA acelera las partes del desarrollo que nunca fueron el cuello de botella.

Las empresas que superaron el muro no usaron mejores modelos. Construyeron infraestructura que capturaba lo que los modelos pasaban por alto.

Por qué existe el muro

Tres causas raíz explican el estancamiento. Cada una opera de forma independiente. Juntas forman un techo que mejores modelos no pueden penetrar.

Inanición de contexto

Los asistentes de programación con IA operan sobre el código visible en el archivo actual y el contexto que cabe en la ventana de prompt. No conocen las decisiones de arquitectura, los contratos de API, las restricciones de despliegue ni las convenciones de nombres del equipo a menos que alguien inyecte esa información.

Sin contexto específico del proyecto, el modelo adivina. Inventa rutas de archivos que siguen convenciones plausibles pero no existen. Genera llamadas a API hacia endpoints que coinciden con patrones comunes pero no con los suyos. Sugiere importaciones de paquetes que el proyecto no utiliza.¹²

Faros AI analizó telemetría de 10.000 desarrolladores en 1.255 equipos y encontró que los pull requests asistidos por IA son un 154% más grandes que los no asistidos.¹² Los PRs más grandes tienen más superficie para errores dependientes del contexto. La IA genera código con confianza. El código compila. El código no tiene en cuenta la restricción documentada en una página de Confluence que la IA nunca vio.

El comportamiento no es un problema de alucinación en el sentido de seguridad de modelos. El modelo está funcionando exactamente como fue diseñado: prediciendo código probable dado el contexto disponible. El problema es que el contexto disponible excluye la mayor parte de lo que importa para la corrección en un código base específico.

Vacío de verificación

La IA genera código más rápido de lo que los procesos de revisión existentes pueden absorber. Faros encontró que los PRs asistidos por IA tardan un 91% más en revisarse.¹² Los desarrolladores completan un 21% más de tareas y fusionan un 98% más de pull requests, pero el pipeline de revisión maneja producción a velocidad humana.¹²

El estudio de código inseguro de Stanford cuantificó la dimensión de seguridad. Los investigadores asignaron a 47 desarrolladores tareas de programación con y sin asistencia de IA. El grupo asistido por IA escribió soluciones inseguras con más frecuencia en cuatro de cinco tareas. En la tarea de inyección SQL, el 36% del grupo con IA escribió código vulnerable frente al 7% del grupo de control. Los participantes con asistencia de IA tenían más probabilidad de creer que habían escrito código seguro incluso cuando no era así.¹³ La combinación de producción más rápida y mayor falsa confianza crea una brecha de verificación que la revisión manual no puede cerrar a escala.

GitClear analizó 153 millones de líneas de código modificadas y encontró que el code churn (código reescrito dentro de las dos semanas posteriores a su escritura) se proyectaba a duplicarse en 2024 respecto a las líneas base pre-IA.¹⁴ El aumento de volumen por las herramientas de IA crea retrabajo que compensa parcialmente las ganancias de productividad. La encuesta de Stack Overflow de 2025 confirma la fricción: el 66% de los desarrolladores reporta dedicar más tiempo a corregir código generado por IA que está “casi correcto”.⁶

Brecha de gobernanza

El código generado por IA elude los mecanismos de gobernanza que los desarrolladores humanos internalizan. Un desarrollador senior sabe que debe revisar la guía de estilo, ejecutar el linter, actualizar el changelog y notificar al líder del equipo sobre cambios de arquitectura. Un asistente de IA genera una solución que satisface el prompt. La brecha entre “compila y pasa las pruebas” y “cumple los estándares organizacionales” es gobernanza.

Los investigadores de McKinsey atribuyeron la desaceleración de los desarrolladores junior a la brecha entre el código generado y el contexto organizacional. Los desarrolladores junior carecen del criterio para evaluar si la producción de la IA cumple estándares que aún no han internalizado. Sin infraestructura de gobernanza que codifique esos estándares como verificaciones automatizadas, la producción de IA fluye sin control hacia abajo.

La brecha de gobernanza se acumula entre equipos. La utilidad generada por IA de un desarrollador duplica el módulo existente de otro desarrollador. Dos endpoints generados por IA usan formatos de error diferentes para la misma API. Las migraciones generadas por IA siguen una convención de nombres diferente al estándar del equipo. Cada violación es pequeña. El efecto acumulativo es un código base que se desvía de sus propias convenciones más rápido de lo que la revisión puede corregir.

Cómo se ve el otro lado

El hallazgo de DORA describe dos poblaciones usando herramientas idénticas. Las organizaciones con prácticas sólidas vieron cómo la IA amplificaba sus fortalezas. Las organizaciones con prácticas débiles vieron cómo la IA amplificaba sus disfunciones.⁴ La variable entre ellas no es qué IA usan. Es la infraestructura alrededor de la IA.

Cada causa raíz se mapea a una solución de infraestructura. La tabla a continuación mapea la cadena desde el problema hasta la solución, con una implementación concreta de un sistema que construí y documenté en los artículos complementarios. El ejemplo es un intento con cifras específicas, no una prescripción universal.

La inyección de contexto aborda la inanición al asegurar que el modelo reciba información específica del proyecto en cada prompt. Un hook dispatcher ejecuta nueve manejadores secuenciales que inyectan la fecha actual, la rama de Git, el directorio de trabajo, las convenciones del proyecto, el contexto de la tarea activa y las restricciones arquitectónicas. El modelo recibe entre 200 y 400 tokens de contexto de anclaje antes de procesar la solicitud del usuario. Latencia medida: 200ms en total para los nueve hooks. El modelo deja de inventar rutas de archivos porque se le han proporcionado las rutas reales.¹⁵

La verificación independiente aborda el vacío al eliminar a los humanos del cuello de botella de verificación en comprobaciones rutinarias. El bucle de desarrollo autónomo (documentado en Anatomy of a Claw) genera código, ejecuta la suite completa de pruebas y envía los resultados a tres agentes de revisión que operan de forma independiente. El agente de implementación nunca revisa su propia producción. La separación refleja el hallazgo de que el grupo asistido por IA en el estudio de Stanford tenía más confianza en código inseguro: la autoverificación no es confiable sin importar si el autor es humano o artificial.¹³

La gobernanza automatizada aborda la brecha al codificar los estándares del equipo como verificaciones ejecutables. El Fabrication Firewall clasifica cada acción saliente como local, compartida o externa, delegando la publicación externa a la revisión humana. Las puertas de calidad bloquean los informes de finalización que usan lenguaje evasivo (“debería funcionar”, “parece correcto”) en lugar de citar resultados de pruebas y rutas de archivos. El sistema aplica estándares que los desarrolladores humanos aplicarían si tuvieran tiempo de revisar cada línea. A la velocidad de generación de la IA, no lo tienen.

El sistema combinado produce resultados medibles en su propio código base: 4.518 fragmentos de código indexados para búsqueda semántica, 49.746 fragmentos de bóveda en 15.800 archivos para memoria persistente, y una suite de pruebas que se ejecuta automáticamente antes de que cualquier cambio reporte su finalización.¹⁵ Estos números describen la infraestructura de un solo desarrollador. No pueden demostrar que el enfoque sea generalizable. Pueden demostrar que el muro es permeable con las herramientas adecuadas del otro lado.

La proporción de gobernanza

El sistema de hooks descrito en Anatomy of a Claw contiene 84 hooks. Un conteo verificado los separa por función: 35 hooks de juicio que deciden si algo debe ocurrir, 44 hooks de automatización que ejecutan acciones predeterminadas, y 5 hooks de utilidad (dispatchers, gestión de estado). La proporción de gobernanza es 4:5. Comenzó en 1:6.¹⁵

La proporción inicial refleja lo que la mayoría de los equipos construyen primero: automatización. Inyectar contexto. Registrar métricas. Formatear salida. Registrar uso. Estos hooks capturan el 10% que todos obtienen. Automatizan las partes mecánicas del desarrollo que ya estaban parcialmente automatizadas antes de la IA. Los datos de DX confirman esto: las cuatro horas ahorradas por semana provienen de la generación de código y la reducción de código repetitivo, tareas que ya eran la parte más rápida del ciclo de desarrollo.¹

El giro hacia hooks de juicio refleja de dónde provienen las ganancias adicionales.

La encuesta de McKinsey de 2025 a casi 300 empresas que cotizan en bolsa encontró que las de mayor rendimiento vieron mejoras de productividad del 16-30% y mejoras de calidad del 31-45%.¹⁶ Estas organizaciones tenían una adopción del 80-100% de desarrolladores combinada con integración organizacional. El factor diferenciador no fue la tasa de adopción (que se correlaciona con ganancias del 10% en todos los casos) sino la infraestructura y los procesos construidos alrededor de esa adopción.

El planteamiento de Laura Tacho aplica aquí: “Soy escéptica respecto a la promesa de cualquier tecnología de mejorar el rendimiento sin abordar esas restricciones subyacentes.”³ Las restricciones subyacentes son restricciones de juicio. ¿Este código cumple nuestros estándares? ¿Este cambio rompe algo más adelante? ¿Esta producción contiene una fabricación? Los hooks de automatización no pueden responder estas preguntas. Los hooks de juicio sí pueden, de forma imperfecta, al codificar los criterios que los desarrolladores experimentados aplican mentalmente.

La proporción aún no ha alcanzado la paridad. El sistema todavía automatiza más de lo que gobierna. El desequilibrio es en sí un diagnóstico: cualquier capa de orquestación donde los hooks de automatización superan en número a los hooks de juicio tiene margen de mejora.

Lo que realmente necesita construir

El sistema descrito en los artículos complementarios tiene 84 hooks, 43 skills, 19 agentes y 15.000 líneas de infraestructura.¹⁵ No necesita 15.000 líneas. Necesita tres cosas.

Un hook de inyección de contexto. Cinco líneas de bash que inyectan la fecha actual, la rama y el directorio de trabajo en cada prompt de IA. La inyección elimina toda una categoría de alucinación: el modelo deja de inventar rutas de archivos y nombres de ramas porque tiene los reales.

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

Una puerta de calidad. Quince líneas que buscan lenguaje evasivo en los informes de finalización. Si el agente dice “debería funcionar” en lugar de citar resultados de pruebas, la puerta bloquea. La puerta aborda el vacío de verificación en el punto de entrada más económico posible.¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

Un ejecutor de pruebas independiente. Un hook que ejecuta la suite de pruebas del proyecto después de cada cambio de código y falla de forma visible si las pruebas se rompen. La implementación varía según el proyecto. El principio no: el agente que escribe código no debe ser el único juez de ese código.

Comience con lo que más se rompe en su flujo de trabajo. Si su IA inventa rutas de archivos, construya primero el hook de contexto. Si su IA entrega código sin probar, construya primero el ejecutor de pruebas. Si su IA escribe “listo” sin evidencia, construya primero la puerta de calidad.

Karpathy describió la evolución del vibe coding a la ingeniería agéntica: “orquestar agentes que hacen [el trabajo] y actuar como supervisión.”¹⁷ Los tres hooks anteriores son la supervisión mínima viable. No producirán ganancias del 30%. Le moverán del 10% hacia el 15%, y cada uno que agregue revelará la siguiente restricción que vale la pena abordar.

El muro es real. También es específico. Inanición de contexto, vacío de verificación y brecha de gobernanza son problemas de ingeniería con soluciones de ingeniería. Los modelos seguirán mejorando. El muro se mantendrá en el 10% para cada equipo que trate la IA como un generador de código en lugar de un sistema que requiere infraestructura para gobernar su producción.

Conclusiones clave

Para desarrolladores individuales. Comience con un hook de inyección de contexto. Cinco líneas de bash que inyectan fecha, rama y directorio de trabajo eliminan toda una categoría de alucinación de la IA. El muro empieza a ceder cuando el modelo conoce las rutas reales de sus archivos en lugar de adivinarlas.

Para líderes de equipo. Mida su proporción de gobernanza: cuántos de sus hooks de IA verifican la producción frente a cuántos automatizan tareas. Si los hooks de automatización superan en número a los de juicio, su equipo solo captura el primer 10%. Los datos de DX confirman que las cuatro horas ahorradas por semana provienen de la generación de código, tareas que ya eran la parte más rápida del ciclo de desarrollo.¹

Para ingenieros de plataforma. Construya la capa de verificación antes de escalar la adopción de IA. DORA encontró que las organizaciones que desplegaron IA sin infraestructura de ingeniería vieron aumentar la inestabilidad con la adopción.^{4 5} Las tres causas raíz se mapean a tres soluciones de infraestructura. Comience con la que cause más fricción en su pipeline.

Fuentes