Octoverse 2026: cuando el coste del código se desplaza a la revisión
Escribir código resulta cada vez más barato. Comprender por qué existe un cambio y decidir si debe integrarse no se vuelve automáticamente más barato.
El informe Octoverse 2026 de GitHub ofrece una instantánea útil de esa tensión. Según GitHub, en septiembre los desarrolladores iniciaron más del 40 % de las pull requests con un agente, frente al 17 % en marzo. La plataforma también comunica que los commits mensuales de septiembre de 2026 multiplicaron por seis los de septiembre de 2025.
Son cifras de actividad de una plataforma, no un experimento controlado sobre calidad del software. No demuestran qué parte del aumento causaron los agentes, cuánto tiempo ahorraron los equipos ni si mejoró un proyecto concreto. Aun así, me llevan a una pregunta práctica: ¿qué ocurre con la revisión cuando producir un cambio aparentemente razonable se vuelve más rápido?
Una pull request cambia la responsabilidad
Un agente puede preparar una implementación, ejecutar comandos y resumir un diff. Quien revisa sigue teniendo que decidir si se entendió el problema, si las hipótesis corresponden al sistema y si el resultado es adecuado para sus usuarios.
Eso es diferente de comprobar que un parche parezca coherente. Una explicación fluida puede presentar una hipótesis errónea como si estuviera resuelta. Un test satisfactorio puede demostrar el comportamiento de los casos que cubre y dejar sin probar el límite operativo importante. Ninguno de estos problemas es exclusivo de los agentes, pero la producción más rápida puede hacerlos aparecer con más frecuencia.
Yo empezaría cada revisión con tres preguntas:
- ¿Qué decisión toma este cambio? Identificar el requisito, los usuarios afectados y el comportamiento modificado.
- ¿Qué evidencia demostraría que es incorrecto? Buscar fallos, límites de permisos y supuestos que un test de caso favorable no cubre.
- ¿Puede revisarse por partes? Separar comportamientos sin relación y mantener cada cambio lo bastante pequeño para ver sus consecuencias.
No se trata de aplicar la misma ceremonia a una errata y a un cambio en la autorización de pagos. La evidencia necesaria debe corresponderse con las consecuencias de una decisión equivocada.
Actividad no equivale a productividad
GitHub también informa de que los repositorios creados recientemente con un archivo de configuración de agente promediaron ocho veces más commits que los nuevos repositorios sin ese archivo. Es una correlación entre los grupos medidos por GitHub. Los repositorios con propósitos, automatizaciones y patrones de contribución diferentes pueden comportarse de manera distinta. Un archivo de configuración no demuestra por sí solo que un agente haya multiplicado por ocho la productividad.
La distinción útil está entre volumen de trabajo y resultados. Commits, pushes y pull requests muestran lo que procesó un sistema. Por sí solos no muestran el valor para el cliente, la fiabilidad ni el coste de mantenimiento.
Para evaluar el uso de agentes, combinaría esos datos con medidas más cercanas al trabajo: cuánto esperan los cambios para ser revisados, con qué frecuencia necesitan modificaciones importantes, si cubren los fallos relevantes y qué ocurre después del despliegue. Ninguna debería convertirse en una puntuación única. Un equipo puede mejorar una medida empeorando otra.
Que la evidencia acompañe al cambio
El resultado más útil de un agente de programación puede ser el contexto que acompaña al diff: comportamiento solicitado, hipótesis adoptadas, comandos ejecutados y resultados. La persona que revisa puede reproducir las comprobaciones relevantes, examinar lo que no se probó y comparar la implementación con la petición original.
Cuando un cambio tiene impacto significativo sobre seguridad o datos, también querría ver sus límites de confianza: qué identidades pueden activar el comportamiento, qué sistemas reciben datos y qué ocurre ante un fallo. El resumen del agente es un punto de partida para la inspección, no una prueba de que esos límites funcionen.
En mi artículo sobre DeepSeek Superagent, examiné qué convierte un mensaje en trabajo autorizado. Octoverse señala el otro extremo del proceso: cuando llega un cambio, alguien sigue teniendo que decidir si la evidencia basta para aceptarlo.
Más código generado puede acelerar el desarrollo. El beneficio depende de que la decisión de integrar siga siendo comprensible.
Fuentes
- GitHub Octoverse 2026: commits, pushes y desarrollo asistido por agentes.
- Proyecto Git: control de versiones distribuido.
- Miniatura: logotipo de Git de Jason Long, CC BY 3.0. La marca identifica el sistema de control de versiones y no implica respaldo del proyecto Git.
Fuentes consultadas el 4 de noviembre de 2026. Sigue jpalanco.com para más notas sobre IA, ingeniería e investigación de seguridad.
