Si estàs comparant un taller de dos dies amb un acompanyament de diverses setmanes perquè el teu equip treballi amb agents de codi, el més probable és que estiguis comparant preus. És la comparació equivocada.
La idea que defensa aquest insight: un taller ensenya què fa l'eina; el que canvia el lliurament d'un equip és com escriu el que cal construir, com revisa el que produeix l'agent i on decideix una persona. Això no s'aprèn en una aula, s'instal·la treballant. Per això la pregunta útil no és quant costa el taller, sinó què queda a l'equip al cap de tres mesos.
Per a què serveix un taller (i per a què no)
Un taller no és una pèrdua de temps. Serveix perquè tot l'equip vegi el mateix, comparteixi un vocabulari i perdi la por de provar. El que no pot fer en dos dies és canviar hàbits que es construeixen amb decisions repetides sobre codi real: què es demana a l'agent, amb què es compara el que retorna i qui ho aprova. La taula és nostra:
| Cap en un taller | Només s'instal·la treballant |
|---|---|
| Què fa l'agent i com se li demana una cosa | Escriure l'especificació d'una tasca real abans de demanar el codi |
| Exemples preparats per aprendre | Els casos del codi de l'equip, que no sempre surten bé |
| Bones pràctiques de revisió en general | Revisar cada canvi contra uns criteris d'acceptació acordats abans |
| Un vocabulari comú | Un context escrit al repositori (convencions, decisions, límits) que l'equip manté |
| Entusiasme el dilluns següent | Algú a qui preguntar quan l'agent s'equivoca la tercera setmana |
Elaboració d'onext
El que diu l'evidència, i el que no
No coneixem cap estudi que mesuri quant triga un equip de desenvolupament a canviar la manera de treballar amb agents. Hi ha indicis solts que apunten en la mateixa direcció.
El primer és de DORA, el programa de recerca sobre equips de programari de Google Cloud. El seu informe de 2025 sobre el desenvolupament assistit per IA diu que el paper principal de la IA és el d'un amplificador, que magnifica les fortaleses i les debilitats que l'organització ja tenia, i que els retorns més grans no vénen de les eines, sinó del sistema organitzatiu que hi ha a sota. Si el que s'amplifica és el mètode de l'equip, el mètode és el que cal treballar.
El seu model de capacitats per a equips amb IA va en la mateixa línia. Les set capacitats que identifica inclouen una postura clara i comunicada sobre l'ús de la IA, pràctiques sòlides de control de versions i treballar en lots petits. La nostra lectura: són pràctiques d'equip, no continguts d'un curs. Es tenen o no es tenen en el dia a dia.
El tercer és una menció de passada, però significativa: la pàgina de l'informe de DORA sobre el retorn de la IA en desenvolupament, actualitzada el 22 d'abril de 2026, parla de gestionar la «caiguda de productivitat» inicial d'un desplegament nou. No diu quant dura ni quant cau. Diu que existeix, i això ja n'hi ha prou per no esperar resultats el dilluns després del taller.
La xifra que més circula sobre el temps d'adopció és de Microsoft: segons una enquesta a 1.300 usuaris de Microsoft 365 Copilot, a les 11 setmanes la majoria diu que l'eina millora la seva feina, i Microsoft recomana animar la gent a continuar fent-la servir fins aleshores perquè crear hàbits nous porta temps.
Risc La dada de les 11 setmanes és una enquesta de percepció publicada pel mateix fabricant el març de 2024, entre usuaris de Microsoft 365 Copilot (inclosos empleats de Microsoft) amb almenys tres setmanes d'ús. No són desenvolupadors ni agents de codi. La citem només com a senyal d'ordre de magnitud: setmanes, no dies.
I després hi ha l'obvi, que també té evidència: el que no es practica s'oblida. Jaap Murre i Joeri Dros van replicar el 2015 la corba de l'oblit d'Ebbinghaus, amb un sol subjecte que aprenia llistes i les reaprenia al cap de minuts, hores o dies. És un experiment de memòria i no diu res sobre equips de programari; el fem servir només per recordar que un taller sense pràctica posterior s'oblida.
En comparar formats, la pregunta útil no és quant costa el taller, sinó què queda a l'equip al cap de tres mesos.
Què s'instal·la treballant
El centre del mètode és escriure abans de demanar. Amb Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, el que ha de complir un canvi s'escriu abans del codi, i l'agent treballa contra això. Ho expliquem a Spec-Driven Development amb IA. Les plantilles per començar són a l'abast de qualsevol; el que no ve a la plantilla és el mètode del mateix equip, i aquest mètode s'ajusta tasca a tasca.
El mateix passa amb la revisió. Revisar contra uns criteris escrits abans és més ràpid que llegir un canvi sencer i intentar endevinar què es volia, però només s'aconsegueix quan l'equip ho ha fet desenes de vegades. Quan no es fa, el guany de l'agent es queda esperant a la revisió, com expliquem a més codi, el mateix lliurament. I sense aquest mètode, el que puja és la velocitat, no l'estabilitat: amb IA el teu equip lliura més ràpid, però no més estable.
La tercera part del mètode és la xarxa: control de versions, proves i una manera clara de desfer el que faci l'agent, que convé tenir abans de donar l'agent a l'equip. I l'última, una persona que decideix on hi ha risc. Cap d'aquestes parts s'aprèn mirant; totes s'aprenen equivocant-se amb una cosa que importa i corregint-ho amb ajuda.
Com es fa sense aturar els lliuraments
L'objecció habitual a un acompanyament de setmanes és que l'equip no es pot aturar. No cal aturar els lliuraments: el Quick-start treballa amb un equip pilot, sobre feina real ja planificada i en paral·lel al seu sprint. Es treballa sobre una cosa que calia lliurar igualment.
Començar per un equip concret té un avantatge més. L'ús dels agents de codi s'estén sobretot entre companys, i amb ell viatja la manera de fer-los servir, com vam veure a els agents de codi no s'adopten per decret, es contagien. Un equip pilot que treballa amb mètode i a la vista és el que després copien els altres.
La prova dels tres mesos
Sigui quin sigui el format que triïs, als tres mesos es pot comprovar si el mètode s'ha quedat a l'equip. No cal cap enquesta; n'hi ha prou de mirar el repositori i una reunió de revisió:
- Els canvis de l'agent neixen d'una especificació escrita abans del codi, no d'una petició al xat que ningú més ha llegit.
- La revisió compara el canvi amb uns criteris d'acceptació; no es limita a llegir-lo i deixar comentaris.
- El context de l'equip (convencions, decisions, límits de l'agent) és escrit al repositori i algú el manté.
Si als tres mesos no es veu cap de les tres coses, l'equip va aprendre l'eina, però no va canviar el mètode. Quins indicadors de lliurament mirar, a més, és a KPIs d'equips de desenvolupament amb IA.
Comença amb un taller, continua amb el mètode. Si vols fer el primer pas, tens el taller en línia d'SDD d'onext.
Si vols veure amb algú de fora què li caldria al teu equip, 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
Serveix un taller d'IA per a un equip de desenvolupament?
Serveix per començar: l'equip veu què fa l'eina, comparteix un vocabulari i perd la por de provar-la. El que no canvia en dos dies és com lliura l'equip: com escriu el que cal construir, com revisa el que produeix l'agent i on decideix una persona. Això s'instal·la amb la feina real de l'equip.
Quant triga un equip de desenvolupament a adoptar la IA?
No coneixem cap xifra fiable per a equips de desenvolupament. La que més circula, les 11 setmanes de Microsoft, és una enquesta de percepció a usuaris de Microsoft 365 Copilot publicada pel mateix fabricant. DORA, per la seva banda, parla d'una caiguda de productivitat inicial en desplegar la IA, sense dir quant dura. Microsoft parla de setmanes i DORA no dona cap termini; cap de les dues no parla de dies.
Quina diferència hi ha entre formar en una eina i canviar el mètode de l'equip?
Formar en l'eina ensenya què pot fer l'agent. Canviar el mètode és decidir com treballa l'equip amb ell: especificacions escrites abans del codi, criteris contra els quals es revisa, canvis petits i una persona que decideix on hi ha risc. El primer cap en una aula; el segon només es comprova amb feina que arriba a producció.
Cal aturar els lliuraments per implantar un mètode nou amb IA?
No cal aturar els lliuraments: el Quick-start treballa amb un equip pilot, sobre feina real ja planificada i en paral·lel al seu sprint. És la diferència amb un taller: es treballa sobre una cosa que l'equip havia de lliurar igualment.
Què convé preguntar abans de contractar un taller o un acompanyament d'IA?
Una sola pregunta ordena la comparació: què quedarà a l'equip i al seu repositori d'aquí a tres mesos. Si la resposta és el material del curs, és formació. Si són especificacions, criteris de revisió i un context escrit que l'equip manté, és mètode.
Què es pot comprovar als tres mesos per saber si el mètode s'ha instal·lat?
Tres coses que es veuen sense enquesta: si els canvis de l'agent neixen d'una especificació escrita abans, si la revisió compara el canvi amb uns criteris i no només el llegeix, i si el context de l'equip (convencions, decisions, límits) és escrit al repositori i algú el manté.
Fonts
- DORA, «State of AI-assisted Software Development 2025» (la pàgina només indica l'any), consultat el 25 d'octubre de 2026.
- Kevin M. Storer i Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de setembre de 2025.
- DORA, «ROI of AI-assisted Software Development report», pàgina actualitzada el 22 d'abril de 2026.
- Microsoft WorkLab, «AI Data Drop: The 11-by-11 Tipping Point», 19 de març de 2024 (enquesta a 1.300 usuaris de Microsoft 365 Copilot).
- Jaap M. J. Murre i Joeri Dros, «Replication and Analysis of Ebbinghaus' Forgetting Curve», PLOS ONE, 6 de juliol de 2015.
- Les cites de fonts en anglès estan traduïdes per onext. La taula, la prova dels tres mesos i la lectura de les capacitats de DORA com a pràctiques d'equip 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 →