Els agents ja obren el 40 % de les pull requests de GitHub. Harvard ha mesurat on s'encallen: a la revisió de codi, un 56 % més lenta

La meitat de les pull requests de GitHub comencen avui amb un agent. Els enginyers que les han d'aprovar continuen sent els mateixos.

Aquesta setmana m'han arribat dos documents a la taula. El 28 d'octubre GitHub va publicar l'Octoverse 2026: al setembre, més del 40 % de les pull requests de la plataforma van néixer com a primer esborrany d'un agent, uns 110 milions, davant del 17 % del març. L'1 de novembre, Fiona Chen i James Stratton, doctorands de Harvard, van publicar la versió actual d'Artificial Intelligence in the Firm: Bottlenecks in Software Production, construïda amb dades de Jellyfish de 655 empreses, 720.542 treballadors i 445 milions d'esdeveniments de treball entre el gener del 2021 i l'agost del 2026. De tot el paper, el número que vull que et quedis és un: quan una empresa adopta agents de programació, el temps entre enviar una pull request a revisió i aprovar-la puja un 56,1 %.

No ho escric des de la cadira de l'analista. Gairebé cada setmana reviso codi que ha escrit un agent, sigui per a la nostra plataforma o dins d'una app que un fundador va fer amb Claude Code o amb Lovable i ara necessita en producció. El paper descriu la meva agenda. Escriure codi s'ha abaratit. Decidir que aquell codi és correcte, no.

Els agents afegeixen un 44 % més de codi i, com a molt, un 31 % més de software

El paper separa dues coses que gairebé tots els quadres de comandament barregen. La producció intermèdia és codi: línies afegides, commits, pull requests obertes. La producció final és software: incidències i epics de Jira resolts, que en aquestes empreses vol dir que la feina ha arribat a producció.

En la primera, els agents compleixen. Adoptar assistents va pujar les línies de codi un 38,6 %, els commits un 25,5 % i les pull requests un 25,2 %. Adoptar agents, a sobre, hi va afegir un 44,0 % més en línies, un 36,0 % en commits i un 35,7 % en pull requests. A l'empresa mediana, les línies per treballador i mes van passar de 3.679 a 6.482.

En la segona, poc d'aquest cabal arriba al final. Els assistents van moure les incidències resoltes un 2,0 % i els epics un 1,7 %, xifres que no es distingeixen de zero. Els agents van moure les incidències un 13,7 % i els epics un 18,0 %, i l'estimació de les incidències tot just frega la significació estadística. El que serveix és l'interval de confiança: fins i tot amb agents, les dades descarten un augment del software entregat superior al 30,7 %, molt per sota del 44 % de codi addicional. Els autors van comprovar si les incidències s'havien fet més grosses, estimant amb models la durada de cada tasca a partir del text de Jira, i aquesta explicació no tanca el forat.

L'ocupació tampoc no es va moure. Dotze mesos després d'adoptar agents, l'estimació és d'un −2,6 %, i l'interval descarta caigudes per sota del −15,6 %. Les empreses no acomiaden enginyers per embutxacar-se el guany. L'absorbeixen en algun lloc. El paper diu on.

La cua davant del revisor ha crescut un 60 %, i la revisió mateixa dura un 58 % més

El 56,1 % són dos números. El codi espera un 59,9 % més a la cua abans que algú l'agafi. Un cop agafat, passa un 58,5 % més de temps en revisió activa. El primer és capacitat: la mateixa gent, més diffs. El segon és qualitat: la proporció de canvis que reben com a mínim un comentari puja un 13,1 %, i el nombre de comentaris per canvi puja un 38,6 %. Els revisors no signen més codi a cegues. Hi troben més coses a dir.

Un dels 21 enginyers que els autors van entrevistar ho resumeix en una frase que hauria pogut gravar a la nostra reunió diària: la gent podia fer moltíssims commits molt de pressa, però només un enginyer sènior tenia permís per aprovar canvis perquè era qui coneixia el codi, i podia revisar el seu un cop per setmana. Després d'unes quantes caigudes provocades per commits generats amb IA, l'empresa va afegir una norma que exigia aprovació sènior per al codi generat amb IA, i la cua es va tornar a allargar.

Aquest és el mecanisme, pas a pas. Els agents fan créixer el volum de codi que entra a revisió. Aquest codi entra amb més defectes per unitat. La capacitat de revisió no creix amb el volum, perquè revisar no és una habilitat genèrica aplicada a text genèric. Al conjunt de dades, el 82,8 % de les revisions les fa algú que ja coneix aquell codi, davant del 17,2 % que sortiria si els revisors s'assignessin a l'atzar, i el codi escrit per un sènior el revisa un altre sènior el 75,7 % de les vegades. El revisor és la persona que té el model del sistema al cap, i no hi ha cap API per afegir-ne més.

Els revisors d'IA no han buidat la cua: el 79 % de les empreses ja els fa servir

La solució evident és posar també un agent a revisar. Gairebé totes ho van fer: el 79,1 % de la mostra havia adoptat eines de revisió de codi amb IA al final del període. El coll d'ampolla continua. Quan Chen i Stratton ajusten el seu model de producció a les estimacions, en treuen un guany de productivitat en programar del 73,7 % i un canvi en la productivitat en revisar del −7,0 %. Les empreses van respondre movent gent: el temps de programació va baixar un 22,7 % i el de revisió va pujar un 43,4 %.

Ho llegeixo com la prova més sòlida fins ara de la frase que repeteixo des de fa dos anys: el model és la mercaderia; la bastida que l'envolta és el fossat. Una eina que assenyala estil i comprovacions de nuls treu la part barata de la revisió. La part cara, «aquest canvi fa el que demanava la incidència, i què més ha tocat?», és la bastida: tests que fixen el comportament, evals que fixen els criteris d'acceptació, una arquitectura prou petita perquè una persona la tingui tota al cap. Les evals són l'única suite de regressió que té un sistema d'IA, i un revisor sense elles llegeix 400 línies sense cap oracle.

El contraargument mereix el seu paràgraf, perquè l'informe de GitHub apunta cap a l'altra banda. L'Octoverse diu que les pull requests iniciades per agents es fusionen més: el 90 % en dues setmanes al setembre, davant d'un 86 % de les que no tenen participació detectada d'agents, i des del 83 % del febrer. Totes dues coses poden ser certes alhora. GitHub mesura si una PR acaba fusionant-se; Harvard mesura quant tarda l'aprovació i quanta feina costa. El codi que es fusiona després d'un 56 % més de revisió continua comptant com a «fusionat» en una finestra de dues setmanes. I totes dues xifres porten el seu avís: GitHub ven Copilot, així que la seva recerca és recerca de proveïdor, i el paper de Harvard és un working paper amb dades d'un sol proveïdor d'analítica, encara sense revisió d'experts. Juntes, assenyalen el mateix lloc. El codi entra. Entra més a poc a poc, i a l'enginyera sènior li costa més hores de la setmana deixar-lo entrar.

Aquesta pel·lícula ja l'hem vista: la fàbrica no es va accelerar quan es va accelerar el motor

Els autors es remunten a la dècada del 1880, i fan bé. Els motors elèctrics van arribar a les fàbriques en aquells anys; la producció industrial no es va transformar fins quatre dècades més tard, quan les plantes es van reconstruir al voltant del motor en lloc de l'eix de vapor. La frase de Solow del 1987, que l'era de l'ordinador es veia a tot arreu menys a les estadístiques de productivitat, té la mateixa forma.

El software ja ha viscut una ronda d'això. La recerca DORA darrere d'Accelerate va trobar que la freqüència de desplegament i el lead time milloraven amb pràctiques, lots petits, trunk-based development, integració contínua, i no amb eines soles. Vaig escriure sobre per què aquestes quatre mètriques importen més que la velocitat; els agents són el compilador més ràpid que hem comprat mai, i el lead time és assegut a la columna de revisió. La simulació del mateix paper posa xifres al que hi ha en joc. Si la productivitat de la revisió es queda on és, la producció d'aquestes empreses puja un 57,8 % fins al 2031 i després s'estanca quan la revisió toca sostre. Si la revisió segueix el ritme de la programació, la producció puja un 341,4 %. Tota la diferència entre aquests dos futurs és al pas que ningú no pressuposta.

Què faria aquest trimestre si fos el teu CTO

1. Partir el temps fins a l'aprovació en les seves dues meitats i penjar-les totes dues a la paret. L'espera a la cua i la revisió activa es mouen per motius diferents, i el paper mostra que pugen totes dues. Si el problema és la cua, et falten revisors. Si és la revisió activa, et falten tests. Arregla la que has mesurat.
2. Que les PR d'agent es guanyin la revisió. Cap canvi escrit per un agent no entra a la cua sense el pla que ha seguit, els tests que ha afegit i un diff que es pugui llegir d'una tirada. Els benchmarks 2026 de LinearB sobre 8,1 milions de pull requests, també recerca de proveïdor, situen les PR assistides per IA en unes dues vegades i mitja la mida de les humanes, esperant més de setze hores que algú les agafi davant d'unes tres. La mida és la variable que controles avui.
3. Posar les evals davant del revisor, no darrere. Cada criteri d'acceptació de la incidència es converteix en una eval que l'agent ha de passar abans que un humà obri el diff. Així el revisor gasta el seu 58 % en disseny i radi d'impacte, no a comprovar si la funció retorna la forma correcta.
4. Rotar un revisor de guàrdia i protegir-ne la franja. L'enginyer que té el sistema al cap és la restricció. Tracta les seves hores de revisió com una guàrdia: programades, visibles, sense que la feina de funcionalitat les interrompi.
5. Mantenir la base de codi prou petita perquè una persona l'abasti. El 82,8 % de familiaritat és la troballa silenciosa. Cada mòdul que un sènior no sap explicar és un mòdul que espera una setmana el qui sí que ho sap. Quan portem una app feta amb IA a producció, el primer que entreguem és un mapa d'allò que ningú no entén, perquè és on es formarà la cua.

Sis números per endur-se

• Més del 40 % de les pull requests de GitHub van començar amb un agent el setembre del 2026, uns 110 milions, davant del 17 % del març. (GitHub, Octoverse 2026, 28 d'octubre.)
• Adoptar agents de programació va pujar les línies de codi un 44,0 %, els commits un 36,0 % i les pull requests un 35,7 % a 655 empreses. (Chen i Stratton, Harvard, versió de l'1 de novembre.)
• El software entregat va pujar com a molt un 30,7 %; l'estimació d'incidències resoltes és del 13,7 %, a la vora de la significació.
• El temps entre enviar a revisió i aprovar va pujar un 56,1 %: l'espera a la cua un 59,9 %, la revisió activa un 58,5 %.
• Els comentaris per canvi van pujar un 38,6 %, i el 79,1 % de les empreses ja feia servir eines de revisió amb IA.
• El 82,8 % de les revisions les fa algú que ja coneix el codi. El revisor no escala per API.

Els agents han mogut el cost del software d'escriure'l a decidir que és correcte. Les empreses que guanyin els pròxims cinc anys seran les que dotin, equipin i mesurin aquesta decisió amb la mateixa serietat amb què van dotar l'escriptura. Si tens un repositori on un agent ha escrit gairebé tot i una sola persona el pot aprovar, aquesta és la conversa que tenim cada setmana. Porta la cua.