Hi ha tres regles operatives que separen els equips que escalen amb IA dels equips que només acceleren el seu propi caos. Les tres són tan netes que es poden escriure en un tovalló. I gairebé ningú les aplica. Les articulem com a claims canònics a onext perquè són la base del mètode amb què redissenyem equips de desenvolupament — però el seu valor no depèn del mètode. Són certes per si soles, i qualsevol Tech Lead que les interioritzi la setmana que ve canvia com construeix programari amb IA.
Tres claims. Tres antídots.
Els tres claims són aquests:
Cap és complicat. Cap és nou en absolut si portes anys treballant en enginyeria seriosa. El que sí que és nou és el fàcil que és violar-los quan un equip sencer comença a fer servir Copilot, Cursor o Windsurf simultàniament sense mètode. La velocitat d'adopció de l'eina supera la velocitat d'adopció de la disciplina, i apareix la paradoxa que l'estudi de METR va documentar l'any passat: developers que reporten +20% de productivitat subjectiva mentre són −19% menys productius mesurats en commits, cicle de PR i defectes en producció.
La paradoxa no és un defecte de la tecnologia. És absència dels tres claims. I dels tres antídots que els acompanyen.
Claim 1: el model no és la font de veritat
El model — Claude, GPT-5, Gemini, el que sigui — no recorda. No manté estat entre converses. No és auditable a posteriori. I, sobretot, no codifica les regles reals del projecte: la guia d'estil, les dependències deprecades, les decisions arquitectòniques que l'equip va prendre fa dos mesos per raons que el xat actual ignora. Quan un developer pregunta al model «com faig X en aquest repo?» i accepta la resposta sense contrastar, està confiant en la memòria probabilística del model com si fos la documentació oficial del projecte. No ho és. I cada vegada que es confonen, hi ha deute tècnic latent signat per un agent que demà no podrà explicar per què el va signar.
Antídot operatiu: l'equip necessita una capa externa de context persistent que l'agent consulti cada vegada. No «l'agent recorda» — «l'agent llegeix». Concretament, cal un conjunt de documents versionats que viuen al repo (o en un servei de context) i que codifiquen les decisions reals: la guia d'estil, les regles de naming, les dependències permeses i prohibides, els antipatrons detectats, els acords d'arquitectura. En la nostra feina anomenem això la constitució del projecte — un fitxer o conjunt de fitxers explícits que l'agent rep com a part de cada prompt operatiu, i que mantenen el model dins del marc del projecte en comptes del marc de «què diu el web sobre això en general».
El que importa de la constitució no és la seva sofisticació. És que existeixi i s'actualitzi. Un equip que arrenca amb deu regles escrites en markdown i les refina cada sprint passa de «el model decideix cada vegada» a «el model aplica les nostres decisions». El canvi mental és enorme i es produeix en setmanes, no en anys.
Claim 2: el xat no és el sistema
La segona violació és la més comuna i la més invisible. El developer obre una conversa a Claude o Cursor, fa 40 missatges fins a arribar a un commit que funciona, i tanca la pestanya. Tres setmanes després necessita modificar el que va fer, no recorda per què va prendre cada decisió, obre una altra conversa de zero i torna a iterar 40 missatges per arribar a una variant diferent del mateix problema. La història del raonament s'ha perdut. El coneixement ha viscut només al xat, que és efímer.
Quan això li passa a un developer una vegada, és anècdota. Quan li passa a un equip de cinquanta developers cada setmana, és la raó per la qual l'organització sent que té IA però no acumula avantatge. El xat ha capturat la sortida — el codi — però ha llençat l'entrada, les restriccions, el context, el raonament. I sense entrada no hi ha sistema, hi ha improvisació repetida.
Antídot operatiu: codificar workflows amb quality gates automatitzats que viuen fora del xat. La idea és trivial: en comptes que cada conversa amb el model sigui ad hoc, hi ha un grapat de fluxos definits — idea-a-feature, quick-improvement, spike, audit — que l'equip executa de manera consistent. Cada flux té fases, cada fase té un objectiu i un quality gate que comprova si la sortida compleix criteris objectius abans de passar a la següent. El gate pot ser un linter, una validació de spec, un test, una checklist humana — però existeix, és automàtic i és el mateix per a tothom.
L'equip que codifica quatre o cinc workflows amb els seus gates respectius passa de «cada developer té el seu propi diàleg amb la IA» a «l'equip té un sistema operatiu comú amb IA a dins». No és opcional per escalar més enllà de deu persones treballant en paral·lel: amb menys disciplina, els conflictes de criteri es multipliquen exponencialment. Amb disciplina, la corba s'aplana.
Claim 3: el codi no és l'únic artefacte
La tercera violació és la que més costa corregir perquè va contra una intuïció que el desenvolupament professional porta trenta anys cultivant: «el codi és la veritat; els documents es quedaran desactualitzats igualment; millor estalviar-se el paperam i centrar-se en el que importa, que és el que es compila». És defensable en un món sense IA. En un món amb IA és deute en càmera lenta.
El motiu és que, quan un agent col·labora en el codi, necessita entendre què se suposa que el codi ha de fer — no què fa de fet. La diferència entre «què ha de fer» i «què fa» és on viuen els bugs. Si l'únic artefacte de l'equip és el codi, l'agent només pot inferir la intenció retroactivament, i s'equivocarà en els casos límit que no apareixen als tests però sí a l'esperit de les specs. Si l'equip manté specs, acceptance criteria, regles de negoci i decisions de disseny com a ciutadans de primera — versionats juntament amb el codi — l'agent pot contrastar, i els humans que revisen també.
Antídot operatiu: Spec-Driven Development. Les specs són la font; el codi es deriva. El flux canvia: abans de tocar codi s'actualitza la spec, després es valida que el codi compleix la spec, després es fa el merge. Implementat bé, això vol dir validació pre-commit contra spec (estructura, naming, dependències, cobertura) i un hook de bloqueig de merge si el codi no compleix. No és ciència-ficció — són eines que existeixen des de fa anys. La novetat és la disciplina de fer-les servir com a check obligatori, no com a adorn.
Hi ha un benefici secundari important: les specs ben mantingudes es converteixen en el material que l'agent fa servir per generar tests, documentació, exemples per a l'onboarding de developers nous. L'esforç d'escriure spec s'amortitza tres vegades.
El que separa «instal·lar Copilot» d'«industrialitzar la IA al teu equip»
Tres claims. Tres antídots. Capa externa de context. Workflows amb gates. Spec-driven. Cap és complicat. I, tanmateix, els equips que els apliquen són una minoria — fins i tot entre els qui paguen llicències premium de Cursor o Copilot per a tota la plantilla.
La diferència no és d'eines. És de disciplines. I les disciplines s'instal·len en setmanes si hi ha mètode; no s'instal·len mai si no n'hi ha. Aquesta és la frontera real entre els equips que escalen amb IA i els que només acceleren el seu propi caos.
A onext anomenem això industrialitzar el desenvolupament amb IA, i és el nucli del programa de transformació que oferim a equips de desenvolupament. Però el valor dels tres claims no depèn del programa: qualsevol Tech Lead pot instal·lar-los pel seu compte si té autoritat, criteri i paciència perquè les primeres setmanes facin una mica de mal. Els equips que ho fan pel seu compte arriben al mateix destí que els que contracten ajuda; triguen més i trenquen més vidres pel camí. És una decisió legítima.
La cita honesta que tanca la conversa
«Els agents encara no són prou fiables per a enginyeria complexa.»
— Andrej Karpathy
Qui diu això no és un escèptic anti-IA. És un dels enginyers d'IA més respectats del món. La conclusió operativa no és «no facis servir IA». És: fes-la servir amb mètode. Els agents no són fiables sols; amb els tres claims interioritzats i els tres antídots en producció, són eines notables. Sense ells, són il·lusió de progrés.
Si vols endur-te alguna cosa accionable d'aquesta lectura, hem preparat cinc preguntes per auditar el teu equip dev amb IA el dilluns que ve. Una pàgina A4, sense email obligatori, descarregable directa:
→ Descarrega l'auditoria de 5 preguntes
Si les cinc respostes et deixen satisfet, el teu equip està millor que el 80% del mercat. Si et deixen incòmode, parlem-ne: info@onext.es — assumpte «auditoria dev IA». Conversa de 30 minuts sense compromís.
Fonts: estudi METR 2024 sobre productivitat de developers amb eines IA (paradoxa +20%/−19%); declaracions públiques d'Andrej Karpathy sobre fiabilitat d'agents en enginyeria complexa.
Lectura complementària: Spec-Driven Development: la metodologia · Context Engineering: la disciplina · MVP vs Especificació: el biaix del Quick Ship
