Harvard: la IA genera 30% más código, no más software

¿Qué encontró el estudio de Harvard sobre los agentes de IA?

El 30% más de código que generan los agentes de IA en las empresas no se traduce en más software entregado. Un estudio de Harvard sobre prácticas reales de programación en cientos de compañías encontró que la revisión humana se convirtió en el cuello de botella que absorbe esa ganancia, con "poca evidencia de que las empresas aumenten su producción de software o reduzcan su plantilla" al adoptar estas herramientas.

El hallazgo, reportado por Ars Technica, no dice que los agentes no sirvan. Dice algo más incómodo para quien firmó las licencias: la eficiencia que se gana en la fase de escritura se absorbe aguas abajo, dentro del propio proceso de producción.

Para un founder con equipo de producto, la lectura es directa. Si compraste herramientas de IA esperando duplicar entregas y el resultado no llegó, el cuello de botella probablemente no estaba donde pensabas.

Más código no es más software: los números del estudio

Los investigadores Fiona Chen y James Stratton midieron primero la parte fácil. Según el estudio, la introducción de agentes de código en una empresa produce:

• 30% más líneas de código generadas
• 20% más commits
• 23% más pull requests en promedio

Hasta ahí, la promesa se cumple. El problema aparece al medir lo que el negocio realmente quiere: la tasa de resolución de Issues y Epics —funcionalidades completas— rastreadas en herramientas como Jira no cambió de forma estadísticamente significativa tras la adopción. Los investigadores tampoco detectaron un cambio en el tamaño o la complejidad de esos tickets.

Traducido al día a día: el equipo escribe más, revisa más y entrega lo mismo.

La base del análisis es inusualmente amplia. Los investigadores usaron datos agregados de Jellyfish, una plataforma que mide el output granular de equipos de ingeniería: 300 millones de eventos de trabajo (commits y pull requests) y datos de gestión de incidencias de más de 700.000 empleados en más de 700 empresas de desarrollo de software, entre 2021 y marzo de 2026. Para saber cuándo cada compañía adoptó IA, combinaron medición directa de uso con análisis de actividad en GitHub, y aplicaron una regresión de diferencias en diferencias sobre las variables clave.

¿Por qué la revisión de código se vuelve el cuello de botella?

El estudio describe un mecanismo concreto: "el proceso de revisión de código aumenta significativamente en duración, los pull requests tienen más probabilidades de requerir revisiones y los revisores dejan más comentarios".

Ninguna de esas tres cosas es gratis. Cada una consume horas de las personas más caras de la empresa. Y el volumen crece más rápido que la capacidad de revisión, porque generar código con un agente toma minutos mientras que entenderlo, validarlo y aprobarlo sigue dependiendo de humanos.

El research del sector ya venía marcando esta tensión. DORA, el programa de investigación sobre prácticas de desarrollo de software, describió en su trabajo de 2026 sobre el ROI del desarrollo asistido por IA que el tiempo ahorrado durante la creación se reasigna con frecuencia a auditoría y verificación, lo que llama el "impuesto de verificación".

Un estudio empresarial difundido en julio y recogido por TechRepublic puso números a ese impuesto. En una empresa de tamaño medio, con 802 desarrolladores y 196.212 pull requests analizados entre enero de 2024 y abril de 2026, la proporción de pull requests con al menos una revisión humana cayó del 89% al 68%, la cobertura de revisión automatizada subió de cerca del 19% al 84% y la carga por revisor prácticamente se duplicó. Los pull requests escritos por IA tardaron alrededor de un 20% más en fusionarse después de la primera revisión humana.

El dato que contradice el optimismo: la productividad medida

No todos los estudios apuntan en la misma dirección, y ahí está la parte útil para decidir.

Un estudio de Microsoft sobre el despliegue de agentes de línea de comandos —Claude Code y GitHub Copilot CLI— a comienzos de 2026 encontró un aumento del 24% en pull requests fusionados por ingeniero por día, con un rango estimado de +14,5% a +33,7%, según reportó TechRepublic. El detalle importa: la mejora solo apareció entre quienes usaban las herramientas con regularidad. Los que las usaban cinco o más días por semana vieron saltos superiores al 50%, frente a cerca del 15% entre quienes las usaban tres días por semana. Dar acceso no bastó; el hábito sí.

Del otro lado, The Next Web recogió evidencia de que la percepción de productividad puede engañar. El laboratorio METR intentó en febrero de 2026 replicar su propio estudio de 2025 sobre tiempo de tareas con y sin IA y no pudo: los desarrolladores se negaron a participar sin acceso a las herramientas. El estudio original había mostrado lo contrario de lo que los propios desarrolladores reportaban — la IA los frenaba por el tiempo extra dedicado a corregir errores y guiar al modelo.

También hay evidencia sobre lo que se pierde en comprensión. Un estudio publicado en 2026 en IEEE Transactions on Software Engineering dio tareas de programación a 69 participantes con y sin asistencia de IA: quienes usaron IA alcanzaron más del doble de completitud mediana de la tarea, pero su capacidad de responder preguntas técnicas sobre ese código bajó un 12,5%, según recogió TechTarget.

¿Qué significa esto para tu startup?

La conclusión práctica no es "no uses agentes de IA". Es que el cuello de botella se movió y tu organización tiene que moverse con él.

Si tu equipo adoptó agentes y no ves más funcionalidades entregadas, el problema probablemente no está en la generación de código: está en que nadie rediseñó el proceso de revisión para el nuevo volumen. Comprar más licencias sin tocar el flujo de revisión solo agranda la cola.

• Mide el resultado, no la actividad. Líneas de código, commits y pull requests son métricas de esfuerzo, no de valor. Si tu tablero de IA reporta volumen de uso, estás midiendo exactamente lo que el estudio de Harvard demuestra que no se traduce en output.
• Presupuesta la revisión como parte del proyecto. Si un agente te permite generar el triple de pull requests, decide de antemano quién los revisa y con qué criterio. La revisión automatizada ayuda a filtrar, pero el estudio empresarial muestra que su cobertura crece justo cuando la revisión humana cae: eso es pérdida de control, no ganancia.
• Empieza por los repositorios nuevos. El mismo estudio empresarial encontró que las ganancias de throughput se concentraron en repositorios recientes, mientras que los codebases legacy vieron poco avance. Si tu producto vive en código viejo, ajusta la expectativa antes de prometer resultados al board.
• Protege el tiempo de los seniors. El costo oculto de generar código sin verificación es que son los ingenieros más caros quienes terminan depurando en producción lo que escribió un agente. Ese tiempo no aparece en ningún presupuesto hasta que ya se gastó.

Conclusión

El estudio de Harvard no desmiente el valor de los agentes de código: desmiente la aritmética simple de que más código equivale a más producto. La ganancia existe, pero se captura rediseñando la revisión, no comprando más asientos.

Para un founder, la pregunta correcta dejó de ser "¿cuánto código puede generar mi equipo?" y pasó a ser "¿cuánto de ese código podemos verificar sin frenar la entrega?". Las empresas que respondan esa pregunta primero son las que van a convertir la IA en ventaja real, y no en una cola de pull requests más larga.

Fuentes

• Ars Technica (fuente original)
• TechTarget
• TechRepublic
• The Next Web