Una prova per a aquesta setmana: tria l'últim bug que va tancar algú junior del teu equip i demana-li que t'expliqui, sense obrir l'assistent, per què fallava. No què va canviar al codi, sinó per què fallava. Si la resposta és «el va trobar l'agent», el bug està tancat, però aquella persona no n'ha après res.
No és un retret. És el més raonable quan l'assistent proposa la correcció en trenta segons i l'sprint estreny. El problema no és el junior, sinó que la feina que el formava ha canviat de mans sense que ningú ho decidís.
La tesi d'aquesta peça és que la IA no fa innecessaris els juniors: fa innecessari l'exercici amb què un junior es convertia en sènior. I com que les persones que d'aquí a cinc anys revisaran i signaran el codi generat per agents són els juniors d'avui, aquest exercici s'ha de tornar a posar al procés, a propòsit, al lloc on ara hi ha la feina.
Dos estudis que semblen contradir-se
El primer és un dels experiments de camp més amplis publicats sobre assistents de codi. Cui, Demirer, Jaffe, Musolff, Peng i Salz van analitzar tres assajos aleatoritzats amb GitHub Copilot a Microsoft, Accenture i una empresa del Fortune 100, amb 4.867 desenvolupadors en total. Els qui tenien l'assistent van completar un 26% més de tasques. I el guany no es repartia igual: els desenvolupadors amb menys antiguitat i en llocs més junior l'adoptaven més i milloraven més; en els de més antiguitat i llocs sènior, l'efecte no era significatiu.
El segon és un experiment controlat que Anthropic va publicar el gener del 2026, signat per Judy Hanwen Shen i Alex Tamkin. 52 desenvolupadors, majoritàriament junior i tots amb més d'un any de Python, havien d'aprendre Trio, una llibreria de programació asíncrona que no coneixien, i implementar-hi dues funcionalitats. A la meitat se'ls va donar un assistent d'IA. Després, tots van fer un test sobre els conceptes que acabaven de fer servir. El grup amb IA va treure de mitjana un 50%; el grup sense IA, un 67%. La diferència més gran va aparèixer a les preguntes de depuració. I el grup amb IA no va acabar significativament abans: uns dos minuts, dins del marge d'error.
Llegits junts, no es contradiuen. Mesuren coses diferents. El primer mesura el que surt per la porta aquesta setmana. El segon mesura el que es queda al cap de qui ho ha fet. Una empresa pot millorar molt en el primer mentre empitjora en el segon, i cap tauler de productivitat no l'hi ensenyarà, perquè aquests taulers mesuren tasques tancades, no criteri adquirit. És el mateix parany que descrivíem a el ROI de Copilot i Cursor: el que es mesura fàcilment no és el que decideix el resultat.
El que el junior feia i ja no fa
Un junior no aprenia perquè algú li ensenyés, sinó perquè feia un tipus concret de feina que l'obligava a entendre. Aquesta feina és la que més s'ha automatitzat.
| Tasca de junior | Què ensenyava | Què passa amb un agent |
|---|---|---|
| Escriure el primer esborrany | Com es descompon un problema i quines decisions cal prendre | L'esborrany arriba fet; les decisions ja vénen preses i ningú no les veu |
| Llegir la documentació | El model mental de la llibreria, no només la crida que cal avui | L'agent fa servir la llibreria sense que ningú l'hagi llegida |
| Depurar el seu propi error | A formular hipòtesis i descartar-les: la base del criteri | S'enganxa l'error i s'accepta la correcció; és on l'estudi d'Anthropic va veure la bretxa més gran |
| Escriure els tests | Què ha de fer el codi i en quins casos es trenca | Els tests es generen des del codi i descriuen el que fa, no el que hauria de fer |
| Defensar la seva pull request | A explicar un canvi i a rebre correccions raonades | El revisor discuteix amb el codi d'un agent; l'autor no té res a defensar |
Elaboració pròpia d'onext
Les dues últimes files ja les hem tractat des del costat de la qualitat: els tests generats des del codi que no proven res i la revisió que encara espera un autor. Aquí apareix l'altra cara del mateix fenomen. Quan aquestes tasques se les queda l'agent, no només es perd un control de qualitat: es perd el lloc on la gent aprenia a exercir-lo.
Com feia servir la IA el grup que sí que va aprendre
El més útil de l'estudi d'Anthropic no és la mitjana, sinó el que hi ha a sota. Els autors van revisar els enregistraments de cada sessió i van trobar sis maneres diferents de fer servir l'assistent. Tres s'associaven a notes baixes i tres a notes altes.
- Notes baixes: delegar tot el codi des del principi; començar sol i anar cedint cada cop més; i fer servir la IA per depurar a base d'enganxar errors fins que alguna cosa funcioni.
- Notes altes: generar el codi i després esforçar-se a entendre'l; demanar codi i explicació alhora; i fer servir la IA només per a preguntes conceptuals, escrivint el codi un mateix.
Els grups són petits —entre dues i set persones cadascun—, així que convé llegir-los com a pistes, no com a lleis. Però la conclusió dels autors és clara: els patrons amb esforç cognitiu preserven l'aprenentatge encara que hi hagi IA pel mig. El que fa mal no és l'assistent, és deixar de pensar mentre el fas servir.
Un treball anterior, en un altre context, apunta en la mateixa direcció. Bastani i altres van donar accés a GPT-4 a gairebé mil estudiants de secundària de Turquia durant les sessions de pràctica de matemàtiques, amb dues versions: una que imitava el xat estàndard i una altra amb instruccions dissenyades per protegir l'aprenentatge. Mentre hi tenien accés, totes dues milloraven les notes. Quan els el van retirar, els qui havien fet servir el xat estàndard van treure un 17% menys que els qui no l'havien tingut mai; en els qui van fer servir la versió amb salvaguardes, aquest efecte negatiu es va mitigar en bona part. Publicat a PNAS el 2025, la seva conclusió és gairebé una instrucció per a un CTO: les decisions de disseny del desplegament decideixen si s'aprèn.
Portar l'aprenentatge on ara hi ha la feina
Amb agents, la feina d'enginyeria no desapareix: es desplaça. Passa d'escriure codi a dir què ha de fer i a comprovar que ho fa. És la idea de fons de l'especificació com el lloc on se signa. Si la feina s'ha mogut cap allà, l'aprenentatge s'hi ha de moure amb ella. A la pràctica, això es tradueix en tres canvis concrets.
1. El junior escriu l'especificació i els criteris d'acceptació
Abans que l'agent toqui res, el junior escriu què ha de fer el canvi, quins casos límit hi ha i com se sabrà que funciona. Un sènior la revisa en deu minuts. És l'esborrany que abans era el codi: obliga a descompondre el problema i a prendre les decisions que l'agent prendria en silenci. I té un avantatge que el codi no tenia: els errors de raonament es veuen abans que existeixi una sola línia. Els criteris d'acceptació, a més, són els tests que l'agent no pot escriure pel seu compte sense descriure el seu propi codi.
2. A la revisió, l'autor explica el seu canvi sense l'assistent
Una regla d'equip senzilla: qui obre la pull request n'és l'autor, encara que l'hagi escrita un agent, i ha de poder explicar què fa el canvi, què passa si falla la crida externa i per què es va descartar l'alternativa òbvia. Sense obrir el xat. Si no ho pot fer, el canvi no està llest, encara que els tests passin. Són cinc minuts per pull request i converteixen la revisió en el que era: el lloc on un junior aprèn d'algú amb més criteri. També és la manera de detectar el patró de «delegar-ho tot» que l'estudi associava a les pitjors notes.
3. Per aprendre, l'assistent explica en lloc de resoldre
Les eines ja ho permeten. Claude Code porta un estil de sortida anomenat Learning: l'assistent explica les seves decisions i, quan arriba a una part amb una decisió de disseny real, deixa unes línies marcades amb TODO(human) perquè les escrigui la persona, i s'espera. S'activa per usuari o es fixa a la configuració del projecte per a tot l'equip. No cal fer-lo servir sempre; té sentit les primeres setmanes amb una tecnologia nova, en un mòdul que el junior haurà de mantenir o en depurar un incident. Amb una advertència que fa la mateixa documentació: és una instrucció que el model segueix, no un control garantit. Funciona si l'equip el vol fer servir, igual que les instruccions compartides.
Cap dels tres canvis no frena l'entrega de manera apreciable, i tots tres reforcen controls que l'equip necessitaria igualment. És la diferència entre formar com una activitat a part, que sempre perd contra l'sprint, i formar dins del flux de feina, que és l'única que sobreviu. Ho vèiem en parlar de per què les transformacions es trenquen al mes 6: el que no és al procés no se sosté.
La lliçó incòmoda: el problema arriba d'aquí a tres anys, no ara
Hi ha una lectura còmoda de tot això: si l'agent fa la feina de junior, contractem menys juniors. Les dades suggereixen que algunes empreses ja ho estan fent. Erik Brynjolfsson, Bharat Chandar i Ruyu Chen, de Stanford, van analitzar les nòmines de milions de treballadors registrades per ADP, la principal empresa de gestió de nòmines dels Estats Units. El setembre del 2025, l'ocupació dels desenvolupadors de programari de 22 a 25 anys havia caigut gairebé un 20% respecte al màxim de finals del 2022, mentre que la dels perfils amb més experiència es mantenia estable o creixia. En el conjunt de les ocupacions més exposades a la IA, la caiguda relativa de l'ocupació d'entrada era del 16%.
Dos matisos honestos. Són dades dels Estats Units, i els autors ho presenten com una evidència primerenca compatible amb un efecte de la IA, no com una prova de causalitat. Però el raonament que ens interessa no depèn d'aquesta xifra. Tot el model de treball que defensem amb agents —especificar, verificar i que una persona signi on hi ha risc— necessita persones amb criteri per signar. Aquest criteri no es compra fet al mercat de manera indefinida: algú l'ha de formar. Una empresa que deixa de formar juniors avui està decidint qui no signarà el seu codi el 2030, i ho descobrirà quan intenti contractar seniors i competeixi amb totes les altres que van prendre la mateixa decisió.
Per això no és un tema de recursos humans, sinó d'arquitectura de l'equip. Ho plantejàvem des de l'entrada a què mesurar en contractar desenvolupadors: si l'agent resol la prova tècnica, el que cal avaluar és el criteri. Aquesta peça n'és la continuació: un cop a dins, aquest criteri es forma o s'atrofia segons com estigui muntada la feina. I això sí que depèn del CTO.
Preguntes freqüents
Els desenvolupadors junior aprenen menys si fan servir IA?
Depèn de com la facin servir. En l'experiment controlat que Anthropic va publicar el gener del 2026, 52 desenvolupadors, majoritàriament junior, van aprendre una llibreria nova de Python amb assistent i sense. El grup amb IA va treure un 50% al test posterior i el grup sense IA un 67%, i la diferència més gran va ser a les preguntes de depuració. Però els qui van fer servir la IA per preguntar conceptes o demanar explicacions, i no per delegar-hi el codi, van conservar l'aprenentatge.
Si la IA fa més productius els juniors, on és el problema?
En el fet que la productivitat i l'aprenentatge es mesuren en llocs diferents. Els experiments de camp amb GitHub Copilot a Microsoft, Accenture i una empresa del Fortune 100 van trobar un 26% més de tasques completades, amb els guanys més grans en els perfils junior i en les incorporacions recents. Això mesura el que surt avui. El test de comprensió mesura si aquella persona podrà revisar i signar codi d'aquí a uns anys. Una empresa pot guanyar en el primer i perdre en el segon sense adonar-se'n.
Cal prohibir l'assistent d'IA als juniors?
No. A les dades d'Anthropic, els patrons d'ús que van preservar l'aprenentatge feien servir la IA: demanaven explicacions, feien preguntes conceptuals o generaven codi i després s'esforçaven a entendre'l. En l'estudi de Bastani i altres amb gairebé mil estudiants, un tutor amb instruccions pensades per protegir l'aprenentatge va mitigar en bona part l'efecte negatiu. El problema és l'ús sense disseny, no l'eina.
Què és l'estil Learning de Claude Code?
És un dels estils de sortida que porta Claude Code. Amb aquest estil, l'assistent explica les seves decisions i, quan arriba a una part amb una decisió de disseny real, deixa unes línies marcades amb TODO(human) perquè les escrigui la persona, i s'espera. S'activa per usuari o es fixa a la configuració del projecte per a tot l'equip. La mateixa documentació avisa que és una instrucció que el model segueix, no un control garantit.
Com es comprova a la revisió de codi si l'autor entén el seu canvi?
Demanant-li que l'expliqui sense l'assistent al davant: què fa el canvi, quins casos cobreix, què passa si falla la crida externa i per què es va descartar l'alternativa òbvia. Si no ho pot fer, la pull request no està llesta, encara que els tests passin. És una pregunta de cinc minuts i és la que converteix la revisió en un moment d'aprenentatge i no només en un filtre.
Les empreses estan deixant de contractar desenvolupadors junior per la IA?
Hi ha indicis als Estats Units. Brynjolfsson, Chandar i Chen, de Stanford, van analitzar nòmines d'ADP i van trobar que l'ocupació dels desenvolupadors de 22 a 25 anys havia caigut gairebé un 20% el setembre del 2025 respecte al màxim de finals del 2022, mentre que la dels perfils amb més experiència es mantenia estable o creixia. Els autors ho presenten com una evidència primerenca compatible amb un efecte de la IA, no com una prova de causalitat.
Fonts
- Judy Hanwen Shen i Alex Tamkin (Anthropic), «How AI assistance impacts the formation of coding skills», 29 de gener de 2026, i l'article complet, «How AI Impacts Skill Formation», arXiv:2601.20245.
- Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng i Tobias Salz, «The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers», versió de febrer de 2025.
- Hamsa Bastani, Osbert Bastani, Alp Sungu, Haosen Ge, Özge Kabakcı i Rei Mariman, «Generative AI without guardrails can harm learning: Evidence from high school mathematics», PNAS 122 (26), 2025 (text complet a PubMed Central).
- Erik Brynjolfsson, Bharat Chandar i Ruyu Chen, «Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence», Stanford Digital Economy Lab, 13 de novembre de 2025.
- Documentació de Claude Code, «Output styles».

Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →