Los agentes abren las pull requests

El 28 de octubre, GitHub publicó Octoverse, su informe anual sobre la actividad en la plataforma, y hay una línea que destaca: en septiembre de 2026, más del 40 por ciento de las pull requests en GitHub empezaron con un primer borrador de un agente, frente al 17 por ciento de marzo. Fueron 110 millones de pull requests solo en septiembre. Ese mismo día, en su conferencia Universe, GitHub lanzó Copilot Projects en vista previa pública y puso Agentic Workflows a disposición general.

Una semana después, Meta compró Conductor, una start-up creada para ejecutar varios agentes de programación a la vez. En conjunto, las noticias apuntan en una dirección: escribir código ya no es la parte escasa de hacer software. Lo escaso es especificarlo, revisarlo, probarlo y responder de él.

Qué contó GitHub

Son cifras de la propia GitHub, medidas en su propia plataforma, y así hay que leerlas. Octoverse cuenta una pull request como iniciada por un agente cuando su primer borrador procede de un agente de programación que GitHub puede detectar, y el informe califica esa señal de «un mínimo, ya que puede que no se detecte todo el uso de agentes». Abarca repositorios públicos y privados, y las cifras de años anteriores se recalcularon con la misma base.

El informe también dice que las pull requests de agentes ya se fusionan al menos con la misma frecuencia que las demás. En febrero, el 83 por ciento de las pull requests con participación de agentes se fusionaron en dos semanas, frente a alrededor del 86 por ciento de las que no tenían ningún agente detectado; en septiembre, la proporción de las de agentes había llegado al 90 por ciento. También son más amplias: alrededor del 87 por ciento modifican más de un archivo, frente al 79 por ciento de las demás. Según nuestra lectura, una fusión demuestra que un revisor aceptó un cambio, no que el cambio fuera correcto.

Más agentes por persona

Los productos que GitHub lanzó ese mismo día dan por hecho que esta proporción seguirá creciendo. Copilot Projects da al trabajo que abarca varios repositorios un único lugar para su contexto, sus agentes y sus resultados. Describes un objetivo, Copilot ejecuta agentes en paralelo, «te consulta cuando te necesita» y te devuelve resultados, como pull requests para que las revises. Agentic Workflows permite a un equipo describir en Markdown tareas como la clasificación de incidencias o el análisis de una compilación fallida y hacer que un agente de programación las lleve a cabo en GitHub Actions, con permisos de solo lectura por defecto y un trabajo independiente que analiza los cambios propuestos antes de aplicarlos.

La entrada de GitHub sobre Universe describe el reparto del trabajo en una frase: «Los desarrolladores marcan la dirección, toman las decisiones y siguen siendo responsables de lo que se publica». Un analista citado por InfoWorld detalló lo que eso significa en la práctica. «Diez sesiones de agentes en paralelo, por ejemplo, podrían generar diez pull requests que hay que revisar», dijo Amit Kumar Jena, que dirige el desarrollo de IA en la consultora Kanerika.

Setenta por ciento no es haber terminado

Una nueva prueba ajena a GitHub muestra por qué no se puede saltar esa revisión. El 26 de octubre, investigadores de Alibaba y de varias universidades publicaron Co-Design Bench: 273 tareas extraídas de 26'314 sesiones reales de programación de usuarios, cada una evaluada frente a criterios de aceptación ocultos redactados por expertos, 2'331 en total. El más potente de diez modelos, ejecutados con la misma configuración de agente, cumplió de media el 69,9 por ciento de los criterios por tarea, pero solo satisfizo por completo el 26,4 por ciento de las tareas. The Decoder, que informó del estudio el 8 de noviembre, escribió que los agentes de programación aún «necesitan una limpieza humana en casi tres de cada cuatro tareas».

El estudio tiene limitaciones. Cada tarea es una única petición fija, así que los agentes no podían hacer preguntas ni ser corregidos por el camino, la evaluación la hacen jueces de IA que pueden equivocarse, y varios autores proceden de Alibaba, cuyo propio modelo Qwen estaba entre los evaluados. Aun así, la brecha que mide, entre la mayoría de los requisitos y todos ellos, es exactamente la que un revisor está ahí para cerrar.

Qué hacen ahora los buenos equipos

Nada de esto requiere tanto herramientas nuevas como la disciplina de siempre, aplicada con más rigor. Empieza por la especificación: cuando un agente redacta el cambio, la tarea escrita es la verdadera fuente, y Jena advirtió de que «las tareas mal definidas podrían provocar ejecuciones repetidas, retrabajo y un mayor consumo de créditos de IA». Escribe qué significa terminado antes de que empiece el agente, igual que Co-Design Bench fija primero sus criterios de aceptación.

Mantén los cambios lo bastante pequeños como para leerlos. GitHub dice que las stacked pull requests, que dividen un trabajo relacionado en cambios más pequeños que se revisan en secuencia, ya las habían usado más de 264'000 desarrolladores en septiembre, dos meses después del lanzamiento de su vista previa. Haz de las pruebas el filtro: un cambio no debería llegar a una persona hasta que las supere, y las propias pruebas merecen la revisión más atenta, porque un agente que puede editar sus propias pruebas puede hacer que cualquier cosa las supere.

Por último, designa a la persona. Cada cambio que se publica necesita a alguien que lo haya aprobado y pueda explicarlo, y ese alguien no puede ser el agente. El consejo de Jena a los CIO es el mismo: «exigir aprobación humana antes de fusionar las pull requests generadas por agentes».

Las herramientas se pueden apagar

La operación de Conductor añade una lección más discreta. TechCrunch informó el 4 de noviembre de que Meta había adquirido esta start-up, fundada en 2024, cuyos equipos de agentes están «diseñados para ayudar a los ingenieros de software a trabajar de forma coordinada en partes separadas y compartimentadas de un proyecto», con agentes de laboratorios como Anthropic y OpenAI. Meta confirmó la compra, pero no dio las condiciones.

El propio aviso de Conductor fija el calendario. Los nuevos registros se cerraron el 4 de noviembre, sus espacios de trabajo en la nube pasan a ser de solo lectura el 13 de noviembre y el 20 de noviembre la empresa empieza a borrar los datos de usuario en la nube, así que los clientes tienen dieciséis días para exportar lo que guardan allí. La app de escritorio sigue funcionando por ahora y empezará a retirarse a principios de 2027. Conductor dice que nunca ha vendido datos de usuario ni ha entrenado con ellos, y ofrece una exportación y una transferencia a la app local.

Nada de esto apunta a mala fe. Muestra lo nueva e inestable que sigue siendo la capa que ejecuta los agentes: un servicio que guarda los espacios de trabajo y los chats de tus agentes puede ser comprado y cerrado en cuestión de semanas. Guarda lo que importa en lugares que controlas: el código y su historial en tu propio repositorio, las especificaciones y las decisiones por escrito junto a él, y pruebas que cualquier agente debe superar, sea cual sea el proveedor que lo suministre.

Dónde estamos

Werk, nuestra plataforma de apps, ya está disponible y se basa en este reparto del trabajo. La IA escribe la mayor parte del código sobre un framework que hemos construido nosotros y en el que confiamos, las personas deciden qué construir, diseñan cómo se siente y revisan cada versión, y cada versión se prueba. El código es tuyo, y la plataforma sigue creciendo por debajo. El siguiente paso hacia el que trabajamos son agentes que publiquen por sí solos cambios y correcciones rutinarios, probados y revisados antes de publicarse, algo que solo funciona cuando la especificación, las pruebas y la revisión ya están en su sitio.