Quantes vegades ha escrit avui algú del teu equip una cosa com «t'he dit que no toquessis aquest fitxer» o «això no és el que t'he demanat»? Cadascuna d'aquestes frases explica què li faltava a l'agent per fer-ho bé. En la majoria d'equips es queda a l'historial d'una sessió que ningú no torna a obrir.
El que el teu equip corregeix cada dia a l'agent és la llista del que li falta a la vostra manera de treballar-hi, i gairebé ningú no la guarda.
Què van analitzar en 20.574 sessions reals
Ningzhi Tang, Toby Jia-Jun Li i sis investigadors més van publicar el maig de 2026, amb una revisió a l'agost, una anàlisi de 20.574 sessions reals amb agents de codi, de 1.639 repositoris, tant a l'editor com al terminal. Surten de dues fonts públiques: 14.789 historials de xat que els desenvolupadors van pujar als seus repositoris de GitHub i 5.785 sessions de terminal de persones que van acceptar registrar-les en obert.
Els autors anomenen desalineament cada moment en què el desenvolupador frena o corregeix l'agent. Van validar 16.118 episodis i de cadascun van anotar quina forma va tenir, per què va passar, què va costar i com es va resoldre.
Què corregeixen les persones
El codi que no funciona és només la quarta forma d'error. Aquestes són les més freqüents; un mateix episodi en pot tenir diverses:
- Saltar-se una restricció que el desenvolupador havia dit: 38,33 % dels episodis.
- Entendre malament la petició: 26,95 %.
- Informar malament de la seva pròpia feina: 22,58 %.
- Escriure codi erroni: 17,82 %.
Pel que fa a les causes, la primera és que l'agent no va seguir una instrucció que sí que tenia (36,49 %). La segueixen una instrucció poc concreta (15,36 %) i actuar abans de conèixer el projecte (11,11 %). En un 26,85 % dels episodis, els autors no van poder saber-ne la causa.
Per què torna la mateixa correcció
La correcció viu al xat. Quan la sessió s'acaba, la següent comença sense ella, tret que algú l'hagi portat a un lloc que l'agent llegeixi o a una comprovació que s'executi sola. L'estudi mesura que els errors es repeteixen d'una sessió a la següent en el mateix repositori, i és raonable pensar que bona part d'aquesta repetició ve del fet que ningú no porta la correcció a un lloc fix; aquesta lectura és nostra i l'estudi no la prova.
A més, els errors canvien amb el temps. La taxa general de desalineament per torn baixa, però dins dels que queden pesen cada vegada més les restriccions ignorades i els informes inexactes. Tots dos s'arreglen millor fora del xat: una restricció que cal repetir a cada sessió necessita un lloc fix, i un informe del qual no et pots refiar necessita alguna cosa que el comprovi.
Com guardar el que corregeix el teu equip
Una manera de fer-ho en una setmana, sense eines noves:
- Cada vegada que algú frena l'agent, ho apunta en una línia: què va passar i de quin tipus va ser, amb les formes de l'estudi com a llista (restricció saltada, petició mal entesa, informe inexacte, codi erroni).
- Al final de la setmana, l'equip mira quines línies es repeteixen. Una correcció que surt una sola vegada es queda on és.
- El que es repeteix es porta al seu lloc: al fitxer d'instruccions si és una cosa del repositori que l'agent no pot deduir del codi, a l'especificació si és d'un tipus de tasca, i a un permís o una comprovació automàtica si no es pot saltar mai.
- Es revisa en una estona curta i sense buscar culpables, com en un postmortem sense culpa: l'anàlisi que els equips d'SRE (l'enginyeria de fiabilitat de sistemes de Google) fan després d'un incident per trobar-ne les causes sense acusar cap persona ni cap equip.
- La setmana següent es mira si aquesta correcció ha tornat. Si torna, el lloc triat no era el bo.
Així podria quedar el registre d'una setmana (exemple inventat):
dl · restricció saltada · va tocar les migracions; se li havia dit que no
dl · informe inexacte · va dir que els tests passaven; no s'havien llançat
dt · restricció saltada · va tornar a tocar les migracions
dc · petició mal entesa · va refer el mòdul sencer; es demanava un mètode
dj · restricció saltada · migracions, una altra vegadaLes migracions surten tres vegades en quatre dies. Una regla que l'agent se salta tantes vegades va a un permís que li impedeixi tocar-les (on va cada regla a Claude Code). L'informe inexacte demana que els tests es llancin sols abans de donar res per acabat. I si la petició mal entesa es repetís, potser falta una convenció al fitxer de l'agent (què deixar en aquest fitxer).
Límit Les sessions són de desenvolupadors que van publicar els seus historials; els equips d'empresa, amb les seves pròpies regles, poden fallar d'una altra manera. Només el 9,33 % dels episodis deixa veure com es va resoldre, i el 91,49 % es calcula sobre aquesta part. Els mateixos autors avisen que la revisió contínua del desenvolupador, de la qual avui depèn gairebé tota resolució visible, difícilment escalarà quan els agents treballin més temps sols.
Una setmana de prova
Demana al teu equip que aquesta setmana apunti cada correcció a l'agent en una línia, en un document compartit. Divendres tindreu la primera llista del que li falta a la vostra manera de treballar amb agents, que és justament la part que no ve amb l'eina.
Com diu el Manel Marcos, el nostre CTO: “La millora contínua dels agents i de les skills forma part del nostre dia a dia i així construïm un flux que cada cop funciona millor. Auditem de manera habitual la deriva de la documentació i del procés de Spec-Driven Development (SDD, desenvolupament guiat per especificacions), i per a això fem servir l'agent orquestrador SDD. Aquests fitxers no els toquem a mà: li demanem que ens ajudi a millorar-los.”
Si vols revisar aquesta llista amb algú de fora, el diagnòstic és gratuït. Com treballem amb equips de desenvolupament: AI-Accelerated Development.
Preguntes freqüents
Per què fallen els agents de codi?
En una anàlisi de 20.574 sessions reals, l'error més freqüent va ser saltar-se una restricció que el desenvolupador havia dit (38,33 % dels episodis), per davant d'entendre malament la petició (26,95 %), informar malament de la seva pròpia feina (22,58 %) i escriure codi erroni (17,82 %).
Per què l'agent de codi no segueix les instruccions?
A l'estudi, la causa més freqüent va ser que l'agent no va seguir una instrucció que sí que tenia (36,49 % dels episodis). Una instrucció poc concreta n'explica un altre 15,36 %. El que no es pot saltar mai convé portar-ho a permisos o a comprovacions automàtiques.
L'agent de codi es corregeix sol?
Poques vegades. Dels episodis en què es veu com es van resoldre, el 91,49 % es va arreglar després que la persona corregís l'agent, i només el 2,99 % el va corregir l'agent pel seu compte.
Els errors de l'agent es repeteixen d'una sessió a una altra?
En el mateix repositori, quan una sessió va tenir un desalineament, la següent també en va tenir en el 51,9 % dels casos, enfront del 33,6 % quan l'anterior no en va tenir.
Com millora un equip la feina amb el seu agent de codi?
Apuntant cada correcció amb el seu tipus i revisant cada setmana quines es repeteixen per portar-les al seu lloc: el fitxer d'instruccions, l'especificació de la tasca o un permís o una comprovació automàtica.
Què és un postmortem sense culpa?
És l'anàlisi que fa un equip després d'un error per trobar-ne les causes sense acusar cap persona ni cap equip. El descriu el llibre d'SRE de Google, i serveix també per revisar les correccions a l'agent.
Fonts
- Ningzhi Tang, Chaoran Chen, Gelei Xu, Yiyu Shi, Yu Huang, Collin McMillan, Tao Dong i Toby Jia-Jun Li, «How Coding Agents Fail Their Users: A Large-Scale Analysis of Developer-Agent Misalignment in 20,574 Real-World Sessions», arXiv:2605.29442, v2 del 31 d'agost de 2026 (v1 del 28 de maig de 2026).
- John Lunney i Sue Lueder, «Postmortem Culture: Learning from Failure», capítol 15 de Site Reliability Engineering, Google i O'Reilly, 2017.
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 →