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

DX encuestó a 121.000 desarrolladores en 450 empresas. El 92,6% utiliza asistentes de codificació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 expresó directamente: “Esto es realmente un problema de gestión. El entusiasmo hizo parecer que simplemente probar la IA produciría beneficios 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 papel 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. Este artículo explica por qué existen esos sistemas.

Resumen

121.000 desarrolladores encuestados. 92,6% de adopción. Productividad estancada en 10%. El muro existe porque la IA genera código más rápido de lo que las organizaciones pueden verificar, contextualizar o gobernar. Tres causas raíz: inanición de contexto (la IA alucina sin conocimiento específico del proyecto), vacío de verificación (el código se despliega más rápido de lo que los procesos de revisión se adaptan) y brecha de gobernanza (la IA elude los estándares de calidad que los humanos aplican). Superar el muro requiere infraestructura alrededor de la IA, no mejor IA. La evidencia: las organizaciones que construyeron infraestructura de verificación y gobernanza redujeron los incidentes a la mitad; las organizaciones que adoptaron IA sin infraestructura los duplicaron.^{4 5} Este es un intento N=1 de construir esa infraestructura, documentado con números específicos. No puede demostrar generalización. Puede demostrar cómo se ve el otro lado del muro.

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 la adopción es inequívoca. Los asistentes de codificació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 la productividad se ha estancado. DX midió un promedio de cuatro horas ahorradas por semana, sin cambio 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 aritmé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 2024 encuestó a 39.000 profesionales y encontró que por cada 25% de aumento en la adopción de IA, el rendimiento de entrega disminuyó un estimado de 1,5% y la estabilidad de entrega disminuyó un 7,2%.⁵ El informe DORA 2025 encontró que el rendimiento se recuperó (la relación pasó de negativa a positiva) pero la estabilidad siguió siendo negativa.⁴ 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 incidencias 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.¹¹ 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 capturó lo que los modelos pasaban por alto.

Por qué existe el muro

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

Inanición de contexto

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

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

Faros AI analizó la 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 PR 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 contempla la restricción documentada en una página de Confluence que la IA nunca vio.

Esto no es un problema de alucinación en el sentido de seguridad del modelo. El modelo funciona 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 una base de código específica.

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 PR asistidos por IA tardan un 91% más en ser revisados.¹² Los desarrolladores completan un 21% más de tareas y fusionan un 98% más de pull requests, pero el flujo de revisión está diseñado para una velocidad humana de producción.¹²

El estudio de Stanford sobre código inseguro cuantificó la dimensión de seguridad. Los investigadores asignaron tareas de codificación a 47 desarrolladores 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 probabilidades de creer que habían escrito código seguro incluso cuando no era así.¹³ La combinación de una producción más rápida y una falsa confianza más alta 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 churn de código (código reescrito dentro de las dos semanas posteriores a ser escrito) se proyectaba para duplicarse en 2024 en relación con las líneas base previas a la IA.¹⁴ El aumento de volumen producido 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 bien”.⁶

Brecha de gobernanza

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

El estudio de McKinsey de 2023 encontró que los desarrolladores junior que usaban IA eran un 7-10% más lentos, no más rápidos.¹¹ Los investigadores atribuyeron esto a la brecha entre el código generado y el contexto organizacional. Los desarrolladores junior carecen del criterio para evaluar si la salida 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 salida de la IA fluye sin control hacia las etapas posteriores.

La brecha de gobernanza se multiplica 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 nomenclatura diferente al estándar del equipo. Cada violación es pequeña. El efecto acumulativo es una base de código 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. Una redujo los incidentes a la mitad. La otra los duplicó.⁴ La variable entre ellas no es qué IA utilizan. Es la infraestructura alrededor de la IA.

Cada causa raíz se mapea a una solución de infraestructura. La tabla siguiente 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. Este es un intento con números específicos, no una prescripción universal.

La inyección de contexto aborda la inanición al garantizar que el modelo reciba información específica del proyecto en cada prompt. Un hook despachador activa 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 adivinar 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 controles rutinarios. El bucle de desarrollo autónomo (documentado en Anatomy of a Claw) genera código, ejecuta la suite de pruebas completa 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 salida. Esto 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 la salida de las pruebas y las rutas de archivos. El sistema aplica los estándares que los desarrolladores humanos aplicarían si tuvieran tiempo para revisar cada línea. A la velocidad de generación de la IA, no lo tienen.

El sistema combinado produce resultados medibles en su propia base de código: 4.518 fragmentos de código indexados para búsqueda semántica, 49.746 fragmentos en el almacén a lo largo de 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 criterio que deciden si algo debe ocurrir, y 44 hooks de automatización que ejecutan acciones predeterminadas. La proporción es 4:5. Comenzó en 1:6.¹⁵

La proporción inicial refleja lo que la mayoría de los equipos construye 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 cambio hacia hooks de criterio refleja de dónde provienen las ganancias adicionales.

La encuesta de McKinsey de 2025 con cerca de 300 empresas encontró que los 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% entre desarrolladores combinada con integración organizacional. El factor diferenciador no fue la tasa de adopción (que se correlaciona con ganancias del 10% en general) sino la infraestructura y los procesos construidos alrededor de esa adopción.

El planteamiento de Laura Tacho aplica aquí: “Soy escéptica de la promesa de cualquier tecnología de mejorar el rendimiento sin abordar esas restricciones subyacentes.”³ Las restricciones subyacentes son restricciones de criterio. ¿Este código cumple nuestros estándares? ¿Este cambio rompe algo aguas abajo? ¿Esta salida contiene una fabricación? Los hooks de automatización no pueden responder estas preguntas. Los hooks de criterio 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. Esto es en sí mismo un diagnóstico: cualquier capa de orquestación donde los hooks de automatización superan en número a los hooks de criterio 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. Esto 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 la salida de las pruebas, la puerta bloquea. Esto 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 ruidosa 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 falla en su flujo de trabajo. Si su IA alucina rutas de archivos, construya primero el hook de contexto. Si su IA despliega 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 añada 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 a la IA como un generador de código en lugar de un sistema que requiere infraestructura para gobernar su producción.

Fuentes