Los agentes de programación con IA generan más código, pero la revisión puede frenar la entrega de software
Los agentes de programación con IA pueden acelerar la creación de código sin aumentar la entrega de software en la misma proporción. Un estudio citado por Ars Technica señala que, tras adoptar estas herramientas, el tiempo medio entre el envío de una propuesta de cambio y su integración en el proyecto aumentó un 49%. El dato muestra que escribir más rápido no resuelve, por sí solo, todas las etapas del desarrollo.
El principal punto de atención está en la revisión del código. Antes de incorporar un cambio al proyecto, alguien debe entender qué se ha hecho, comprobar si la solución responde a lo solicitado y evaluar sus efectos sobre el sistema. Cuando esta etapa exige más ajustes y conversaciones, parte del tiempo ganado al generar código puede perderse.
Producir más código no es lo mismo que entregar más software listo para usar. Esta diferencia ayuda a entender los resultados del estudio y pone en perspectiva las expectativas sobre la productividad con inteligencia artificial.
Qué revela el estudio sobre la programación con IA
La investigación de Chen y Stratton, mencionada por Ars Technica, identificó cambios en el flujo de trabajo tras la introducción de agentes de programación. Además del aumento en el tiempo de revisión, los autores observaron más solicitudes de corrección y más comentarios en las propuestas de cambio.
Los principales resultados fueron:
- Aumento medio del 49% en el intervalo entre el envío de una pull request y su integración en el código del proyecto.
- Proporción de pull requests con ajustes solicitados casi dos veces mayor tras la adopción de los agentes.
- Incremento del 35% en el número de comentarios por pull request.
- Aumento del 14% en la proporción de profesionales que realizaban revisiones de código.
Una pull request es una propuesta de cambio que se envía para su evaluación antes de incorporarse al proyecto. Permite que otros miembros del equipo lean el código, hagan preguntas y pidan correcciones. Por eso, su evolución ayuda a mostrar cómo pasa el trabajo de la creación a la aprobación.
Estas cifras apuntan a una mayor presión sobre la etapa de validación. Sin embargo, no significan que todos los proyectos obtuvieran el mismo resultado ni que todos los cambios producidos con IA presentaran problemas. Son resultados del conjunto analizado y deben interpretarse dentro de ese contexto.
Por qué el aumento del 49% exige una lectura cuidadosa
El tiempo medido por el estudio corresponde al intervalo entre el envío de la pull request y su integración en el proyecto. Esto es distinto de medir únicamente los minutos que una persona dedica a leer código.
Ese intervalo puede incluir la espera hasta que haya un revisor disponible, el intercambio de comentarios, la ejecución de pruebas y nuevas rondas de corrección. Por tanto, no hace falta que la lectura del código sea un 49% más lenta para que el proceso completo tarde un 49% más.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La distinción importa porque ayuda a localizar el posible cuello de botella. Un equipo puede generar cambios con mayor rapidez y, aun así, tardar más en incorporarlos. Si la capacidad de análisis no crece al mismo ritmo que el volumen de propuestas, la cola de revisión puede aumentar.
Este es un mecanismo posible para entender el problema, no una explicación única demostrada para todos los casos del estudio. El fragmento citado por Ars Technica muestra el aumento del tiempo y de las interacciones, pero no detalla cuánto contribuyó cada factor al resultado.
Más comentarios y solicitudes de ajuste amplían el trabajo de validación
El incremento del 35% en los comentarios por pull request indica más interacciones durante el análisis. A su vez, la proporción casi duplicada de propuestas con cambios solicitados muestra que una parte mayor necesitó ajustes antes de avanzar.
Sin embargo, un comentario no representa necesariamente un error. Puede pedir una explicación, sugerir un enfoque más sencillo o aclarar una regla del producto. Del mismo modo, una solicitud de cambio puede implicar desde un pequeño ajuste hasta una revisión importante de la solución.
Aun con esa diferencia, cada ronda de discusión puede añadir trabajo al proceso. El autor de la propuesta debe entender la observación, modificar el código y enviar una nueva versión. Después, el revisor debe comprobar si el punto señalado se ha resuelto.
Una solución que parece correcta también necesita contexto
En la práctica, revisar software implica más que comprobar si el código funciona en una prueba sencilla. Es necesario evaluar si respeta las reglas de negocio, mantiene el comportamiento esperado y encaja con la estructura del proyecto.
Por ejemplo, un cambio en el cálculo de un descuento puede producir el valor correcto en el caso más habitual, pero pasar por alto una regla específica de un plan determinado. Este ejemplo ilustra por qué importa el contexto; no es un caso recogido en la investigación.
Los agentes de IA pueden ayudar a crear funciones, editar archivos y sugerir pruebas. Aun así, la velocidad de estas acciones no elimina la necesidad de comprobar si el cambio resuelve el problema adecuado.
La participación humana creció en la revisión del código
Los investigadores observaron un aumento del 14% en la proporción de profesionales que participaban en revisiones tras la introducción de los agentes. El resultado sugiere que la adopción de estas herramientas estuvo acompañada de una distribución diferente de las actividades, con mayor participación en esta etapa.
Esto no debe confundirse con un crecimiento del 14% en las contrataciones. El dato se refiere a la proporción de trabajadores que realizaban revisiones, y no a una ampliación equivalente del tamaño de los equipos.
Al analizar el total de profesionales activos en los datos de Jellyfish y cruzar esa información con datos de LinkedIn de las empresas, los autores también afirmaron que no pudieron atribuir cambios significativos en el empleo a la IA.
Este resultado no demuestra que la inteligencia artificial nunca vaya a afectar al empleo en el desarrollo de software. Solo delimita lo que los investigadores pudieron identificar en el análisis presentado. En el ámbito descrito, no hubo base para atribuir a la IA un cambio significativo en este indicador.
La IA también revisa código, pero su participación sigue siendo limitada
Una posible respuesta al aumento del trabajo sería utilizar la propia inteligencia artificial para revisar los cambios. El estudio indica que esta práctica ya estaba presente en gran parte de las empresas, pero su participación en las métricas observadas seguía siendo limitada.
Hasta marzo de 2026, el 80% de las empresas analizadas utilizaba alguna forma de revisión de código con IA. Pese a esa adopción, los agentes eran responsables del 23,3% de todos los comentarios de revisión y del 10,8% de todas las pull requests, según las cifras citadas por Ars Technica.
Estos porcentajes miden aspectos diferentes y no deben sumarse. Tampoco equivalen a una medida directa de las horas ahorradas. Aun así, ayudan a mostrar por qué la presencia de la herramienta en muchas empresas no significa que ya asuma la mayor parte del trabajo.
Adoptar la revisión con IA y automatizar toda la revisión son situaciones muy diferentes. En el escenario descrito, las personas seguían siendo responsables de la mayor parte de esta actividad.
Cómo evaluar la productividad más allá del volumen de código
Los resultados refuerzan una distinción importante para los equipos de tecnología: los indicadores de producción no muestran, por sí solos, el valor entregado. Contar líneas de código o propuestas abiertas refleja actividad, pero no indica si los cambios fueron aprobados, publicados y bien recibidos por los usuarios.
Una evaluación más completa puede tener en cuenta:
Herramientas que usamos a diario
- Tiempo hasta la integración: cuánto tarda un cambio en incorporarse al proyecto.
- Rondas de corrección: cuántas veces debe volver la propuesta para recibir ajustes.
- Esfuerzo de revisión: cuánto trabajo humano exige la validación.
- Calidad tras la entrega: si aparecen fallos o la necesidad de rehacer la solución.
- Resultado para el producto: si el cambio resuelve la necesidad que motivó su creación.
Estos criterios son formas prácticas de analizar el flujo de desarrollo, no resultados adicionales atribuidos al estudio. Ayudan a evitar que una mejora puntual, como escribir código más rápido, se confunda con un avance de todo el proceso.
Qué puede facilitar el análisis de los cambios
Las propuestas centradas en un objetivo claro suelen ser más fáciles de comprender. Cuando un cambio reúne muchas tareas sin relación directa, el revisor debe seguir más decisiones al mismo tiempo. Dividir el trabajo en partes coherentes puede simplificar esa evaluación.
El contexto también marca la diferencia. Una descripción que explica el problema, resume la solución e indica las pruebas realizadas ayuda al equipo a comparar la implementación con la solicitud original. Esto se aplica tanto al código escrito por personas como a los cambios generados con ayuda de IA.
Las pruebas automáticas y las comprobaciones de estándares pueden complementar el análisis. Sin embargo, no sustituyen todas las decisiones sobre comportamiento, mantenimiento y adecuación al producto. Estas prácticas pueden reducir fricciones, pero el fragmento presentado no demuestra que eliminen el aumento de tiempo observado.
Las empresas todavía están aprendiendo a utilizar los agentes
Según Ars Technica, el 95% de las empresas del estudio ya había implementado agentes de programación en el escenario descrito. Al mismo tiempo, el artículo destaca que muchas todavía podrían estar aprendiendo cuándo y cómo utilizar mejor estas herramientas.
El texto también señala que los agentes recibieron actualizaciones después de marzo de 2026, la fecha de corte de los datos. Esto limita cualquier intento de tratar los resultados como una descripción definitiva de todas las herramientas y sus versiones futuras.
Con más experiencia, los equipos pueden encontrar tareas en las que la automatización ofrezca un mejor equilibrio entre creación y revisión. Se trata de una posibilidad, no de una mejora garantizada por las cifras presentadas.
La conclusión central se mantiene: el beneficio de la programación con IA depende de todo el recorrido entre generar un cambio y ponerlo en uso. En el estudio citado, el aumento del trabajo de revisión redujo la ventaja de crear código más rápido. El reto no consiste únicamente en producir un mayor volumen de código, sino en transformar esa producción en software fiable sin trasladar todo el esfuerzo a la siguiente etapa.
