Si el teu equip treballa amb agents de codi, gairebé segur que programa més. La pregunta que et faran a la propera revisió del pressupost és una altra: lliura més?
Aquest insight defensa una idea que incomoda tots dos bàndols: si l'equip programa més i lliura el mateix, la revisió no és el problema, és on es nota. Arriba a revisió feina que ningú no va definir abans, i la persona ha de reconstruir què es volia abans de poder aprovar-la. Revisar més de pressa, o deixar de revisar, només mou l'embús a producció.
El que va trobar l'estudi de 718 empreses
Fiona Chen, de la Universitat Harvard, i James Stratton han estudiat 300 milions d'esdeveniments de treball en 718 empreses amb un disseny de diferències en diferències escalonat: comparen l'evolució de cada empresa abans i després d'adoptar assistents i agents de codi, aprofitant que cadascuna els va adoptar en un moment diferent. El seu resum diu tres coses:
- Totes dues tecnologies, assistents i agents, augmenten la productivitat a l'hora de programar.
- Aquest guany no es trasllada del tot a la producció de programari ni a l'ocupació.
- En el cas dels agents, la diferència s'explica per un embús a la revisió de codi: les revisions triguen més, més canvis necessiten correccions i cada revisió rep més comentaris.
Dit d'una altra manera: el codi s'escriu abans, però espera més per entrar.
Risc És un treball acadèmic en la versió d'agost de 2026 i no consta que hagi passat revisió per parells. No n'hem pogut llegir el text complet: només citem el que diu el resum públic al web de l'autora i no donem cap percentatge de l'estudi. L'estudi no diu que la IA no serveixi; diu on es perd una part del que aporta.
No és el primer cop que es veu
Faros AI, una empresa que ven analítica d'enginyeria, va publicar el juliol de 2025 un informe amb telemetria de més de 10.000 desenvolupadors en 1.255 equips. Als equips amb molta adopció d'IA va trobar això:
I, sobretot, no va observar cap correlació significativa entre l'adopció d'IA i millores a escala d'empresa. Són dades d'un proveïdor, amb el biaix dels seus propis clients, però apunten al mateix lloc que l'estudi de Harvard amb una metodologia i unes dades diferents: el volum puja molt més que el que surt per l'altre costat.
Una correcció al que vam escriure abans
A revisar codi generat per IA vam sostenir que la revisió gairebé mai no és la restricció de cabal d'un equip, i que si es vol lliurar abans cal mirar el desplegament. Amb agents, l'estudi de les 718 empreses diu una altra cosa: la revisió sí que és on s'embussa el guany. Ho diem aquí perquè no es llegeixi un insight contra l'altre.
La nostra lectura, i això ja no és de l'estudi, és que les dues idees encaixen si es mira què rep la revisió. Quan un agent produeix un canvi gran a partir d'una petició vaga, qui revisa no té amb què comparar-lo. Ha d'endevinar què es volia, llegir-lo sencer i discutir-lo en comentaris. Això explica revisions més llargues, més correccions i més comentaris. L'embús apareix a la revisió, però es fabrica abans.
Una revisió ràpida no és la que llegeix de pressa. És la que compara el canvi amb alguna cosa que es va escriure abans del codi.
El que arriba a revisió i com canviar-ho
Cadascun dels tres senyals que descriu l'estudi té una causa probable abans de la revisió. La taula és nostra, no de l'estudi:
| El que es veu a la revisió | Causa probable abans de la revisió | Què canviar |
|---|---|---|
| Les revisions triguen més | Canvis grans, que barregen diverses coses | Lots petits: un canvi, un propòsit |
| Més canvis necessiten correccions | El que havia de complir el canvi no estava escrit | Criteris d'acceptació escrits abans del codi |
| Més comentaris per revisió | La persona revisa també la part mecànica: estil, proves que falten, convencions | Comprovació automàtica a cada canvi abans de la revisió humana |
Elaboració d'onext a partir dels tres senyals que descriu el resum de Chen i Stratton (2026)
La primera fila té suport independent. En el seu model de capacitats per a equips amb IA, DORA diu que treballar en lots petits amplifica la influència positiva de la IA en el rendiment del producte i redueix la fricció per als equips de desenvolupament.
La segona és la base de Spec-Driven Development (SDD), el desenvolupament guiat per especificacions: el que s'ha de complir s'escriu abans, i així la revisió es converteix en una comparació. Ho expliquem a Spec-Driven Development amb IA, i com aquests criteris passen a ser la porta del merge.
La tercera deixa a la persona el que només pot fer una persona: jutjar la intenció, el disseny i el risc. On el risc és alt, decideix una persona. Són les mateixes pràctiques que protegeixen l'estabilitat, com expliquem a amb IA el teu equip lliura més ràpid, però no més estable; aquí les mirem des del seient de qui revisa. I aprovar sense poder explicar el que s'ha aprovat té un cost que arriba després: el deute de comprensió.
Què dir quan et preguntin pel pressupost
Si l'equip mesura línies de codi, commits o pull requests, la IA gairebé sempre guanya, i per això aquestes xifres no responen la pregunta. El que la respon és la feina resolta que arriba a producció, comparada amb el que l'equip lliurava abans dels agents. Al costat, dues xifres que ensenyen on es perd la diferència: quant triga un canvi des que demana revisió fins que es fusiona i quants tornen amb correccions.
Quins indicadors triar és a KPI d'equips de desenvolupament amb IA, i com plantejar la despesa com una aposta que es pot comprovar, a la tesi de valor que convé demanar a l'equip. Si els canvis s'acumulen esperant revisió, comprar més llicències no accelera el lliurament per si sol: afegeix cua.
Si aquest trimestre només pots canviar una cosa, que sigui aquesta: cap canvi de l'agent no arriba a revisió sense uns criteris d'acceptació escrits abans. És, al nostre parer, el que més redueix el que cal endevinar en revisar, i és el punt de partida de la xarxa que convé muntar abans de l'agent.
Una segona mirada
Si vols veure amb algú de fora on es queda avui la feina del teu equip entre l'agent i producció, el diagnòstic és gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Com és la resta del camí és a AI-Accelerated Development.
Preguntes freqüents
Els agents de codi augmenten la productivitat d'un equip de desenvolupament?
A l'hora de programar, sí. L'estudi de Fiona Chen i James Stratton amb dades de 718 empreses conclou que els assistents i els agents de codi augmenten la productivitat a l'hora de programar. El que no troba és que aquest guany arribi sencer al programari lliurat ni a l'ocupació. La pregunta útil no és si l'equip programa més, sinó si lliura més.
On es perd el guany dels agents de codi?
Segons el resum de l'estudi, en el cas dels agents la diferència s'explica per un embús a la revisió de codi: les revisions triguen més, més canvis necessiten correccions i cada revisió rep més comentaris. El codi s'escriu abans, però espera més per entrar.
Cal revisar més de pressa o deixar de revisar el codi de l'agent?
Ni una cosa ni l'altra. Revisar més de pressa el mateix converteix la revisió en un tràmit, i deixar de revisar mou el problema a producció. El que proposem és canviar el que arriba a la revisió: canvis petits, amb criteris d'acceptació escrits abans del codi i amb la part mecànica ja comprovada per la integració contínua.
Per què el codi generat per un agent és més difícil de revisar?
Perquè sovint la persona que revisa no té amb què comparar-lo. Si el que havia de fer el canvi no està escrit enlloc, el revisor primer ha de reconstruir la intenció i després jutjar el codi. És la lectura d'onext de l'embús que descriu l'estudi, no una conclusió de l'estudi.
Què convé mesurar per saber si la IA millora el lliurament?
Feina resolta que arriba a producció, no línies de codi ni pull requests. I, al costat d'això, quant triga un canvi des que demana revisió fins que es fusiona i quants tornen amb correccions. Si només es mesuren les línies o els pull requests, la IA gairebé sempre sembla que guanya.
Quina fiabilitat té l'estudi de les 718 empreses?
És un treball acadèmic recent de Fiona Chen, de la Universitat Harvard, i James Stratton (versió d'agost de 2026) amb 300 milions d'esdeveniments de treball i un disseny de diferències en diferències escalonat, però no consta que hagi passat revisió per parells. En aquest insight només citem el que diu el seu resum públic i no donem percentatges que no hàgim pogut llegir a l'original.
Fonts
- Fiona Chen i James Stratton, «Artificial Intelligence in the Firm: Bottlenecks in Software Production», versió d'agost de 2026. Resum al web de Fiona Chen (Universitat Harvard), consultat el 24 d'octubre de 2026; no se n'ha pogut llegir el text complet.
- Faros AI, «The AI Productivity Paradox Report 2025», 23 de juliol de 2025 (més de 10.000 desenvolupadors en 1.255 equips).
- Kevin M. Storer i Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de setembre de 2025.
- Les cites de fonts en anglès estan traduïdes per onext. La lectura de l'embús, la taula i la manera de mesurar són elaboració pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →