La majoria dels canvis que proposa un agent de codi als projectes públics de GitHub no els revisa ningú, i quan algú els revisa, sol ser un altre agent. Si al teu equip passa una cosa semblant, el teu tauler de mètriques probablement no ho distingirà: una aprovació compta igual tant si l'ha donada una persona com si l'ha donada un bot.
Aquest any han sortit tres treballs amb dades sobre com es revisa el codi que escriuen els agents, i un article que proposa deixar de revisar-lo. Llegits junts, deixen al teu equip una pregunta que va abans de quant cal revisar: què llegeix avui una persona abans que el canvi entri.
Un pull request és la petició per integrar un canvi en el codi comú de l'equip, i la revisió és el moment en què una altra persona el llegeix i decideix si entra. Quan un agent n'obre uns quants al dia, aquest és el primer punt que es tensa: un estudi amb dades de 718 empreses ja va veure que el guany dels agents es queda esperant a la revisió. Els treballs d'aquest any miren què passa quan aquesta espera es resol aprovant.
El que es veu a GitHub
Kacper Duma i el seu equip, de la Universitat Nicolau Copèrnic de Toruń (Polònia), van comparar com es revisen els pull requests generats per IA i els escrits per persones als mateixos repositoris, amb el conjunt de dades públic AIDev. La seva conclusió, en un treball acceptat a la conferència EASE 2026: la majoria dels pull requests d'agents no reben cap revisió i, quan en reben, la fan sobretot altres agents. La participació humana, quan n'hi ha, sol prendre la forma d'instruccions a l'agent perquè corregeixi alguna cosa.
Els autors avisen que això complica llegir les mètriques de revisió com a prova de supervisió humana en els estudis a gran escala. Per a un equip passa el mateix a petita escala: el percentatge de canvis revisats abans de fusionar-se pot ser del 100 % sense que cap persona hagi llegit el codi de l'agent.
Shyam Agarwal, Courtney Miller, Christian Kästner i Bogdan Vasilescu parteixen d'una anàlisi semblant de l'activitat pública de GitHub: els pull requests d'agents es revisen menys sovint i es fusionen diverses vegades més de pressa que els de persones. I avisen de seguida que la direcció d'aquestes tendències s'inverteix amb altres decisions d'anàlisi igual de defensables. Per això no es queden en les traces, que segons ells mostren què canvia sense explicar per què: reuneixen 38.709 textos de professionals (blogs d'enginyeria i fils de Reddit) i codifiquen una mostra de 3.100 sobre revisió de codi. La seva conclusió és que la revisió és el punt de control on es decideix l'efecte de l'agent sobre el programari, i que aquest efecte el marca l'equip amb la seva experiència i amb com organitza la revisió.
Qui més fa servir l'agent aprova més i també l'atura més
La tercera dada ve de l'ús real de Claude Code, l'agent de codi d'Anthropic. El seu equip de Societal Impacts va publicar al febrer com canvia la supervisió amb l'experiència, a partir de sessions de finals del 2025 i principis del 2026:
Qui més el fa servir deixa de donar permís per a cada acció i atura l'agent més sovint quan alguna cosa no li quadra. Anthropic ho planteja així: supervisar bé no exigeix aprovar cada acció, exigeix estar en posició d'intervenir quan importa. Aquestes dades mesuren accions dins d'una sessió de treball i les de GitHub mesuren pull requests, però en tots dos casos el permís pas a pas deixa de ser la manera habitual de supervisar.
L'article que proposa deixar de revisar
Martin Monperrus va més lluny en un article de posició publicat al juny. Segons ell, els agents de codi «han creuat un llindar de capacitat» i poden complir tots els objectius declarats de la revisió de codi amb menys cost i a més ritme. L'esquema d'agents que escriuen i persones obligades a revisar li sembla «un carreró sense sortida», perquè no dona garanties reals i no aguanta el ritme del desenvolupament accelerat per IA.
En la pràctica té part de raó. Una persona no llegeix amb atenció una desena de diffs al dia d'un agent (el diff és la llista de línies que canvien), i les dades de GitHub diuen que molts projectes ja han deixat d'intentar-ho sense decidir-ho. Per a un equip d'empresa, la seva conclusió deixa oberta una altra pregunta: qui respon del que arriba a producció. Algú ha d'haver decidit quins canvis entren sense que els llegeixi una persona i per què, i aquesta decisió ha d'estar escrita on l'equip la vegi.
On no hi estic d'acord és en les primeres fases. La revisió humana continua sent imprescindible mentre es construeixen el harness (tot allò que guia el model: subagents, skills, plantilles i controls) i el context. És llavors quan una persona ajuda a ajustar-los i a millorar-los.
També ho és al principi de cada funcionalitat, quan es defineix, perquè no quedi cap pregunta oberta sense resposta. És el que ara en diuen grilling.
Límit Els dos estudis de GitHub són de projectes de codi obert (un equip d'empresa té les seves pròpies regles de revisió), i els seus resums no donen percentatges, així que aquí no se citen xifres. Agarwal i els seus coautors avisen que les tendències que observen no són estables. El de Monperrus és un article de posició, sense dades pròpies. Les dades de Claude Code són d'un sol producte i del seu fabricant; Anthropic recorda que per defecte el producte demana aprovació manual, de manera que part de l'augment pot venir del fet que els usuaris canviïn la configuració, i que les etiquetes de supervisió les va assignar un model.
Què cal mesurar abans de decidir quant revisar
Abans de discutir si el teu equip revisa massa o massa poc, convé saber què passa ara. Amb un mes de dades del teu repositori pots respondre tres preguntes:
- Dels pull requests de l'agent que s'han fusionat, quants tenen una aprovació o un comentari d'una persona? Els de bots i altres agents no compten.
- Quant triguen a fusionar-se, comparats amb els de persones? Un canvi de 400 línies aprovat en dos minuts difícilment s'ha llegit.
- Quants s'han hagut de revertir o corregir les setmanes següents?
Amb aquests números, l'equip pot deixar de banda el debat entre «cal revisar-ho tot» i «ja no cal revisar» i decidir quins canvis llegeix sempre una persona i quins poden entrar sense que ningú els llegeixi. Com repartir la revisió segons el risc de cada canvi ho tractem en llegir el Technology Radar 35.
El que no convé és deixar que aquesta regla l'escrigui el ritme de l'agent. Si ningú decideix què es llegeix, l'equip acaba aprovant gairebé tot igualment, però sense saber què ha deixat passar ni qui ho ha decidit.
És part de la feina d'AI-Accelerated Development. Construïm amb el teu equip dues coses que es queden a casa teva: el context en què treballa la IA i el procés amb què treballeu, de la idea a la documentació actualitzada. Si vols mirar amb algú de fora què es revisa avui al teu equip, el diagnòstic és gratuït.
Preguntes freqüents
Cal revisar el codi que escriu un agent de codi?
Sí, però cada equip ha de decidir amb quina profunditat i quins canvis llegeix sempre una persona. Els estudis del 2026 sobre GitHub mostren que molts pull requests d'agents es fusionen sense revisió humana, així que la decisió ja s'està prenent, encara que ningú l'hagi escrit.
Què diuen els estudis sobre com es revisen els pull requests d'agents?
Un estudi acceptat a EASE 2026 conclou que la majoria dels pull requests generats per IA a GitHub no reben revisió i que, quan en reben, la fan sobretot altres agents. Un altre treball del 2026 veu que es revisen menys i es fusionen diverses vegades més de pressa, amb l'avís que aquesta tendència s'inverteix amb altres decisions d'anàlisi.
Per què les mètriques de revisió poden enganyar quan treballen agents?
Perquè una aprovació o un comentari compten igual si els fa una persona o un agent. Els autors de l'estudi d'EASE 2026 avisen que això complica llegir les mètriques de revisió com a prova de supervisió humana. En un equip, la manera de saber-ho és comptar quants canvis de l'agent tenen una aprovació o un comentari d'una persona.
Què és l'aprovació automàtica en un agent de codi?
És deixar que l'agent executi les seves accions sense demanar permís a cada pas. Segons Anthropic, a Claude Code està activada en prop del 20 % de les sessions de qui en porta menys de 50 i en més del 40 % a partir de 750, i qui té més experiència també interromp l'agent més sovint.
S'acaba la revisió humana del codi?
Martin Monperrus ho sosté en un article de posició de juny del 2026: segons ell, els agents ja compleixen els objectius de la revisió i obligar una persona a revisar-ho tot no dona garanties ni escala. Per a un equip d'empresa continua fent falta algú que respongui de quins canvis entren sense llegir.
Què pot mesurar un equip per saber què revisa de debò?
Amb un mes de dades del seu repositori: quants pull requests d'agents fusionats tenen una aprovació o un comentari d'una persona, quant triguen a fusionar-se comparats amb els de persones i quants s'han hagut de revertir o corregir les setmanes següents.
Fonts
- Kacper Duma, Patryk Wróblewski, Jagoda Bobińska, Julia Winiarska i Piotr Przymus, «These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests», arXiv:2605.02273, 4 de maig de 2026 (acceptat a EASE 2026).
- Shyam Agarwal, Courtney Miller, Christian Kästner i Bogdan Vasilescu, «3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse», arXiv:2607.07980, 8 de juliol de 2026.
- Miles McCain et al. (Anthropic, Societal Impacts), «Measuring AI agent autonomy in practice», 18 de febrer de 2026.
- Martin Monperrus, «The End of Code Review: Coding Agents Supersede Human Inspection», arXiv:2606.13175, 11 de juny de 2026.
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 →