L'1 d'octubre de 2026, David Pralong, soci sènior de McKinsey, va escriure a Fortune que els èxits més citats de la IA enganyen els consellers delegats. Entre els seus exemples hi havia els equips de software, i el motiu és incòmode: aquests equips ja tenien alguna cosa abans que arribessin els models.
El que tenien, segons Pralong, eren «pràctiques de testing, integració contínua i revisió de codi» que feien possible aprofitar la IA. I afegeix que aquests casos són «un punt de partida, no una plantilla» que es pugui traslladar a qualsevol empresa.
D'aquí surt la tesi d'aquesta peça: per implantar IA en un equip de desenvolupament, el primer pas no és triar l'agent, sinó revisar la xarxa que detecta els errors. Si l'equip no pot comprovar el que entra, un agent produeix més codi del que ningú pot verificar.
Per què l'eina no és la primera pregunta
DORA, el programa de recerca de Google sobre equips de software, ho resumeix en el seu informe del 2025 sobre desenvolupament assistit per IA: el paper principal de la IA és el d'un amplificador, que magnifica les fortaleses i les debilitats que l'organització ja té. Un equip que integra cada dia i reverteix sense drama guanya velocitat. Un equip que desplega amb por desplega més de pressa amb la mateixa por.
El setembre de 2025, DORA va publicar un model amb set capacitats que, segons la seva anàlisi, amplifiquen o desbloquegen els beneficis de la IA. Tres són de dades i plataforma, una és de focus en l'usuari i una altra és tenir una postura clara sobre la IA. Les altres dues són exactament la xarxa de què parla Pralong:
Sobre la primera, DORA escriu que, a mesura que la IA augmenta la velocitat dels canvis, el control de versions es converteix en una xarxa de seguretat crítica, i recomana que els equips dominin les funcions de revertir. Sobre la segona, que treballar en lots petits és «especialment potent» en un entorn assistit per IA.
Un agent no porta qualitat: porta volum. La qualitat la posa la xarxa que l'equip ja té per comprovar cada canvi.
La xarxa, peça a peça
Aquestes són les peces que convé mirar abans de donar un agent a un equip. Cap no és nova; el que canvia és quant pesen quan el ritme de canvis puja.
| Peça de la xarxa | Què detecta o evita | Pregunta per al teu equip |
|---|---|---|
| Tests en què l'equip confia | Que un canvi trenqui alguna cosa que ja funcionava | Quan un test falla, algú l'investiga o es torna a llançar fins que passa? |
| Integració contínua | Que el canvi només funcioni a la màquina de qui l'ha fet | Cada canvi passa per la mateixa bateria abans de barrejar-se? |
| Canvis petits | Que una revisió sigui impossible perquè el canvi és enorme | Quant triga a revisar-se un canvi típic, i quantes línies té? |
| Control de versions i revertir | Que un error costi hores en lloc de minuts | Quan va ser l'última vegada que vau revertir alguna cosa, i quant vau trigar? |
| Revisió amb criteri | Que entri codi que ningú entén | La revisió comprova què fa el canvi i per què, o només l'estil? |
| Criteris d'acceptació escrits | Que el codi compleixi el que s'ha demanat però no el que es necessitava | Abans de començar, està escrit com se sabrà que la feina està bé? |
Les cinc primeres peces surten de Pralong (McKinsey) i del model de DORA; la sisena i les preguntes són lectura pròpia d'onext
La revisió és la peça que més canvia: quan l'autor és un agent, la revisió ja no pot donar per fet que hi ha algú que sap per què es va escriure cada línia. Ho expliquem a revisar codi generat per IA. I els criteris d'acceptació poden convertir-se en la condició per integrar el canvi, com expliquem a la teva spec ja és un eval; és la base del desenvolupament guiat per especificacions (Spec-Driven Development, SDD), que resumim a què és SDD i com manté el codi controlat.
El que diu la dada de productivitat, i el que no
L'estudi més citat sobre assistents de codi en empreses reals és el de Cui, Demirer, Jaffe, Musolff, Peng i Salz (Microsoft Research, juny de 2025). Combina tres experiments aleatoritzats a Microsoft, Accenture i una empresa anònima de la llista Fortune 100, amb 4.867 desenvolupadors: els que tenien accés a l'assistent van completar un 26,08 % més de tasques, amb un error estàndard del 10,3 %. Els desenvolupadors amb menys experiència el van adoptar més i hi van guanyar més.
Límit És una mitjana de tres grans empreses, amb un marge d'error ampli, i l'estudi no descriu com era la xarxa de cada equip. No demostra que sense tests ni integració contínua no hi hagi guany. El que no es pot fer és prendre aquest 26 % com una promesa per al teu equip: l'única xifra que val és la que mesuris tu, abans i després.
El que sí que és raonable llegir al costat de Pralong i DORA: els guanys que cita Pralong apareixen en equips que ja sabien comprovar i desfer els seus canvis. I sense aquesta xarxa, encara que l'equip vagi més de pressa, ningú no pot saber si va millor.
L'ordre que proposem
Implantar IA no exigeix aturar l'equip ni reescriure de cop la seva manera de treballar. Exigeix un ordre:
- Revisa la xarxa amb un equip pilot. Les sis preguntes de la taula, amb dades del mateix equip, no amb opinions.
- Arregla el forat més gran. Si els tests no són fiables o els canvis són enormes, això va abans que qualsevol llicència.
- Mesura la línia de base. Quant triga avui un canvi a arribar a producció i quants se'n reverteixen. Sense aquesta dada, després no sabràs què ha canviat.
- Introdueix l'agent sobre feina ja planificada. En paral·lel a l'sprint de l'equip, amb permisos acotats i la revisió de sempre.
- Compara i decideix si s'amplia. Amb les teves dades, no amb les d'un estudi.
Aquest ordre no nega que l'adopció també és organitzativa, com expliquem a l'èxit de la IA en equips de desenvolupament és organitzatiu, ni que cal mirar persones, processos, eines i indicadors alhora, com a les quatre perspectives d'un equip de desenvolupament amb IA. Aquesta peça respon una pregunta més estreta: què va primer. I quan l'agent ja és dins, les regles que ha de complir no van en un text que el model pot ignorar, sinó en controls que s'apliquen sols, com expliquem a Claude Code per a equips: context no és control.
On encaixa onext
Si estàs pensant en com implantar IA al teu equip de desenvolupament, el primer pas d'AI-Accelerated Development és un diagnòstic gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Quan hi ha Quick-start, no cal aturar els lliuraments: treballa amb un equip pilot, sobre feina real ja planificada i en paral·lel al seu sprint. I en el procés, una persona decideix on hi ha risc.
Tria un canvi petit que sortís malament els darrers mesos. Pregunta en quin punt el detectaria avui el teu equip i quant trigaria a desfer-lo. Si la resposta és «a producció» i «no ho sabem», ja saps per on començar, i no és per l'agent.
Preguntes freqüents
Què és «la xarxa» d'un equip de desenvolupament?
És el conjunt de pràctiques que detecten un error abans que arribi a producció o permeten desfer-lo ràpidament: tests en què l'equip confia, integració contínua, canvis petits, control de versions amb el costum de revertir i una revisió del codi amb criteri. No és una eina: és com treballa l'equip.
Per què revisar la xarxa abans de comprar llicències o agents?
Perquè la IA accelera el que ja hi ha. L'informe de DORA del 2025 la descriu com un amplificador de les fortaleses i les debilitats de cada organització. Si l'equip no té com comprovar el que entra, un agent produeix més codi del que ningú pot verificar.
Sense tests ni integració contínua la IA no serveix de res?
No hi ha dades per afirmar-ho. El que sí que diu McKinsey, a la peça de David Pralong a Fortune, és que els equips de software que van aconseguir guanys ja tenien pràctiques de testing, integració contínua i revisió de codi. El guany observat venia amb xarxa; sense ella, ningú sap si un canvi ràpid també és un canvi bo.
Quant millora la productivitat un assistent de codi?
Un estudi amb 4.867 desenvolupadors de Microsoft, Accenture i una empresa de la llista Fortune 100 va mesurar un 26,08 % més de tasques completades, amb un error estàndard del 10,3 %. És una mitjana de tres grans empreses, no una promesa per a la teva: la manera de saber-ho és mesurar-ho al teu equip, abans i després.
Cal aturar els lliuraments per preparar la xarxa?
No. El raonable és començar amb un equip pilot, sobre feina que ja estava planificada i en paral·lel al seu sprint, arreglar primer el forat més gran de la xarxa i mesurar abans d'ampliar.
Com sé si el meu equip té la xarxa preparada?
Amb una prova senzilla: tria un canvi petit que hagi sortit malament els darrers mesos i pregunta en quin punt s'hauria detectat avui (un test, la integració contínua o la revisió) i quant es trigaria a desfer-lo. Si la resposta és «a producció» i «no ho sabem», aquesta és la primera feina, abans de l'agent.
Fonts
- David Pralong (McKinsey), «McKinsey senior partner: Why AI's easiest wins are misleading CEOs», Fortune, 1 d'octubre de 2026.
- Kevin M. Storer i Derek DeBellis (Google Cloud), «Introducing the DORA AI Capabilities Model: 7 keys to succeeding in AI-assisted software development», 23 de setembre de 2025.
- DORA, «State of AI-assisted Software Development 2025» (consultat el 13 d'octubre de 2026).
- Zheyuan (Kevin) 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», Microsoft Research, juny de 2025.
- Les cites de fonts en anglès estan traduïdes per onext. La taula de preguntes, l'ordre proposat i la prova final són lectura 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 →