Les quatre perspectives d'un equip de desenvolupament que treballa amb IA: persones, processos, eines i indicadors

Segons l'informe DORA del 2025, el paper principal de la IA en un equip de desenvolupament és el d'amplificador: magnifica les fortaleses i les debilitats que l'organització ja tenia. I afegeix que el major retorn de la inversió en IA no surt de les eines, sinó de l'atenció al sistema organitzatiu que les envolta.

Si és així, la pregunta útil per a un CTO no és quin assistent comprar, sinó què és el que el seu equip està amplificant. Per respondre-la serveix un marc que els equips de TI fa anys que fan servir: mirar quatre perspectives —persones, processos, eines i indicadors— i buscar quina frena les altres.

La tesi d'aquesta peça és que amb IA el marc continua valent, però les preguntes que l'omplen han canviat, i que l'eina, la perspectiva a la qual es dedica més temps, és la que menys decideix el resultat. Una transformació amb IA pot fallar sense que l'assistent en tingui la culpa: sovint és perquè una de les altres tres continua diagnosticada amb les preguntes d'abans.

Un marc clàssic amb preguntes noves

En un diagnòstic sense IA es pregunta per les habilitats i els plans de carrera, per l'automatització, la freqüència de desplegament i les definicions de ready i done, per l'experiència del desenvolupador i pel que es mesura. Totes aquestes preguntes continuen sent legítimes. El que passa és que, quan un agent escriu bona part del codi, cadascuna es desplaça.

Les quatre files tenen una cosa en comú: la pregunta nova ja no mira el codi, mira el que l'envolta. Qui el demana, com es comprova, quin context el guia i com se sap que ha servit. Anem-hi una per una.

Persones: qui sap especificar i qui sap revisar

L'habilitat que escasseja en un equip amb agents no és teclejar. En són dues, i gairebé cap pla de formació no les anomena: escriure una especificació que un agent pugui executar sense endevinar i revisar codi que no has escrit, amb criteri per detectar el que sembla correcte i no ho és. Una prova per a aquesta setmana: tria tres canvis lliurats l'últim mes i pregunta, de cadascun, qui va escriure el que se li va demanar a l'agent i qui entén per què el resultat és correcte. Si la resposta és «ningú en concret», aquesta perspectiva té un buit.

Els plans de carrera canvien amb això. El recorregut clàssic d'un junior passava per escriure el primer esborrany, equivocar-se i depurar el seu error, i aquest exercici és el que ara fa l'agent. Si ningú no el substitueix, l'equip produeix més avui i forma menys gent capaç de signar el codi demà. Ho desenvolupem a desenvolupadors junior amb IA; la sortida passa perquè el junior escrigui l'especificació i expliqui el seu canvi sense l'assistent al davant. El mateix val en incorporar algú: si un agent resol la prova tècnica, el que cal mirar és el criteri.

Un aclariment d'escala. Aquesta perspectiva és la de l'equip de desenvolupament; l'adopció a tota l'empresa, amb les seves resistències i la seva cultura, té una altra dimensió i la tractem a persones i cultura, més enllà de la formació.

Processos: el ready és l'especificació i el done és la verificació

En un equip àgil, ready i done són les dues portes d'una tasca: quan està llesta per començar i quan està acabada. Amb IA, les dues portes canvien de contingut.

• Ready = l'especificació. Una tasca està llesta quan hi ha una especificació amb criteris d'acceptació que es puguin comprovar. És la idea de Spec-Driven Development (SDD, desenvolupament guiat per especificacions): l'especificació és la font de veritat i el codi se'n deriva. Una història d'usuari de tres línies bastava per a una persona que coneixia el producte; no basta per a un agent que no el coneix.
• Done = la verificació, i on signa una persona. Una tasca està acabada quan el resultat s'ha comprovat contra l'especificació i, en els punts de risc, una persona ha signat. Que els tests passin no basta si els ha generat el mateix agent des del seu codi. Tampoc no es tracta d'aprovar-ho tot: aprovar-ho tot no és control, és un embús.

Això desplaça el coll d'ampolla. És un raonament, no una mesura: si l'agent produeix més canvis per hora, la cua ja no es forma en escriure, sinó en revisar i en verificar, i un procés de revisió dissenyat per a un autor que ja no hi és esdevé el límit. Per això la freqüència de desplegament, que abans depenia sobretot de l'automatització, depèn ara també del que costa verificar un canvi. Cada peça l'hem tractada per separat: l'especificació com el lloc on se signa, el mètode SDD i la revisió que encara espera un autor.

Eines: les regles per sobre de l'eina

La tercera perspectiva se sol llegir com «quin assistent fem servir». Amb agents, la pregunta que decideix és una altra: on viu el que l'agent necessita saber. Les regles del projecte, els patrons, els estàndards i les decisions d'arquitectura poden ser al cap de dues persones, a l'historial d'un xat o en fitxers versionats que l'agent llegeix en cada tasca. Només la tercera opció és governable. A això li diem Rules over Tools (les regles per sobre de l'eina) i és la part pràctica de l'enginyeria de context (context engineering).

El mercat va en aquesta direcció. AGENTS.md es defineix com «un README per a agents»: un lloc previsible per al context i les instruccions que necessita un agent de codi, i el llegeixen eines diferents. Claude Code, per la seva banda, carrega fitxers CLAUDE.md i pot llegir també l'AGENTS.md d'un repositori. Quan el coneixement és en fitxers, canviar d'eina no obliga a començar de zero, i això és el que fa secundària l'eina. Secundària no vol dir irrellevant: se segueix triant per seguretat, cost i encaix, però deixa de ser el lloc on és el mètode.

Hi ha un límit que convé conèixer. La documentació de Claude Code ho diu sense embuts: aquests fitxers són context, no configuració que s'imposi, i com més específiques i concises són les instruccions, amb més constància les segueix el model. El que s'ha de complir sempre no ha de viure només en un text: va a una comprovació automàtica, a una regla del repositori o a un ganxo que bloquegi l'acció. Text per orientar; comprovacions per garantir.

L'experiència del desenvolupador, que és el que mesura aquesta perspectiva, té tres dimensions segons Noda, Storey, Forsgren i Greiler: els bucles de retroalimentació, la càrrega cognitiva i l'estat de flux. Amb agents, les dues primeres es tornen concretes. Un agent sense context obliga a reexplicar-li el projecte en cada sessió, i això és càrrega cognitiva. Una revisió lenta és un bucle de retroalimentació llarg. La pregunta de diagnòstic no és «estan contents amb l'assistent?», sinó «què ha de tornar a explicar cada persona cada vegada, i quant espera una resposta?». Com es construeix aquest context és a context engineering, la disciplina que sosté els equips amb IA.

Indicadors: mesurar lliurament i qualitat, no activitat

«El que no es mesura no es pot millorar» continua sent cert, amb una trampa nova: amb IA, el que és fàcil de mesurar és activitat. Línies generades, llicències actives, suggeriments acceptats. Són números que pugen gairebé sols en adoptar una eina i no diuen si el programari arriba abans ni millor. És el mateix problema que descrivim a el ROI de Copilot i Cursor.

DORA mesura el lliurament amb cinc mètriques, en dos grups. Les de rendiment: temps de lliurament d'un canvi (des del commit fins a producció), freqüència de desplegament i temps de recuperació d'un desplegament fallit. Les d'inestabilitat: taxa de canvis fallits i taxa de desplegaments de correcció no planificats. Serveixen perquè es miren juntes: si la IA puja el rendiment però també la inestabilitat, l'equip només està arribant més de pressa a producció amb més problemes. Les dades surten del repositori i del sistema de desplegament, no d'una enquesta.

La segona raó per mesurar és que la percepció falla. A l'assaig aleatoritzat que METR va publicar el juliol del 2025, 16 desenvolupadors amb experiència van resoldre 246 tasques reals de repositoris que coneixien bé. Amb eines d'IA van trigar un 19 % més; esperaven anar un 24 % més de pressa i, en acabar, seguien creient que havien anat un 20 % més de pressa. Els mateixos autors acoten el resultat: mostra petita, desenvolupadors veterans en projectes coneguts i eines de principis del 2025. No prova que la IA no serveixi. Prova que una impressió no és un mesurament, i que cal una línia base abans de començar. Què mesurar exactament, i què deixar de mesurar, ho desenvolupem a els KPIs d'equips de desenvolupament amb IA.

Com fer servir les quatre perspectives aquesta setmana

No cal un projecte per començar. N'hi ha prou amb una sessió de dues hores amb l'equip i un lliurament real de l'últim mes:

1. Tria un canvi que va arribar a producció i reconstrueix-ne el recorregut: qui el va demanar, quina especificació hi havia, què va generar l'agent i quin context va llegir.
2. Marca on va esperar: a l'especificació, a la revisió, a la verificació o en un desplegament.
3. Per a cada perspectiva, anota una pregunta de la taula que l'equip no sàpiga respondre amb una dada.
4. Tria la perspectiva amb més buits i fixa una mètrica de lliurament que revisar d'aquí a un mes.

Una perspectiva dèbil limita les altres: de res serveix un bon context si ningú no sap especificar, ni mesurar el lliurament si la revisió no té amo. I si el dubte és anterior —per on començar amb la IA a tota l'empresa, no només a l'equip de desenvolupament—, la peça que correspon és les set capes de maduresa.

La pregunta que queda per al teu equip és la de sempre, amb una altra forma: lliureu abans que fa un any o només teclegeu més de pressa? Si costa respondre amb una dada, ja saps quina perspectiva revisar primer.

Preguntes freqüents

Quines són les quatre perspectives d'un equip de desenvolupament que treballa amb IA?

Persones, processos, eines i indicadors. Són les perspectives clàssiques de diagnòstic d'un equip de TI, però amb IA canvien les preguntes: en persones, qui sap escriure especificacions i revisar codi generat; en processos, què signifiquen ready i done; en eines, on viu el context que llegeix l'agent; i en indicadors, si es mesura el lliurament i la qualitat o només l'activitat.

Què signifiquen «ready» i «done» quan un agent escriu el codi?

Ready passa a ser una especificació amb criteris d'acceptació que es puguin comprovar, perquè un agent no coneix el producte com una persona de l'equip. Done passa a ser que el resultat s'ha verificat contra aquesta especificació i que, en els punts de risc, una persona ha signat. Que els tests passin no basta si els ha generat el mateix agent des del seu codi.

Què és «Rules over Tools» i per què importa que el context visqui en fitxers?

És el principi que les regles del projecte, els patrons, els estàndards i les decisions d'arquitectura han de viure escrits en fitxers versionats que l'agent llegeix en cada tasca, per sobre de l'eina concreta. Formats com AGENTS.md els llegeixen eines diferents, de manera que canviar d'eina no obliga a començar de zero. És la part pràctica de l'enginyeria de context.

Quins indicadors serveixen per saber si la IA millora el lliurament?

Els de lliurament i estabilitat, no els d'activitat. DORA en proposa cinc: temps de lliurament d'un canvi, freqüència de desplegament, temps de recuperació d'un desplegament fallit, taxa de canvis fallits i taxa de desplegaments de correcció no planificats. Línies generades, llicències actives o suggeriments acceptats pugen en adoptar l'eina i no diuen si el programari arriba abans ni millor.

Per què no basta amb preguntar a l'equip si la IA els fa anar més de pressa?

Perquè la percepció falla. A l'assaig aleatoritzat de METR del juliol del 2025, 16 desenvolupadors amb experiència van trigar un 19 % més amb eines d'IA i, en acabar, creien haver anat un 20 % més de pressa. Els autors adverteixen de la mida reduïda de la mostra i que les eines eren de principis del 2025. La lliçó és mesurar amb dades del repositori i del desplegament, amb una línia base prèvia.

Per on es comença un diagnòstic de les quatre perspectives?

Per un lliurament real de l'últim mes. Es reconstrueix el seu recorregut (qui el va demanar, quina especificació tenia, què va generar l'agent, quin context va llegir), es marca on va esperar i s'anota, en cada perspectiva, la pregunta que l'equip no sap respondre amb una dada. Es tria la perspectiva amb més buits i una mètrica de lliurament que revisar d'aquí a un mes.

Fonts

• DORA (Google Cloud), «State of AI-assisted Software Development 2025».
• DORA, «DORA's software delivery performance metrics» (cinc mètriques: rendiment i inestabilitat).
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren i Michaela Greiler, «DevEx: What Actually Drives Productivity», ACM Queue, març-abril del 2023 (còpia en PDF allotjada per una de les autores).
• METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de juliol del 2025.
• AGENTS.md, format obert per guiar agents de codi.
• Documentació de Claude Code, «How Claude remembers your project».