Salta al contingut principal
onext technology
IA 18 maig 2026 - 8 min de lectura

El mes 6: per què la transformació IA del teu equip dev es trenca en aquest punt — i el sistema de sosteniment que ho evita

El redisseny inicial és la part fàcil. El difícil és que continuï funcionant quan la novetat desapareix.

Jordi García
Tech Lead a onext
Tech Lead revisant el dashboard de mètriques de workflows IA de l'equip en una pantalla de codi

Fa uns quants anys que entro en repos d'equips que han fet transformació IA. El patró és sempre el mateix: els primers mesos són entusiasme, els carrils funcionen, els quality gates fan la seva feina. Després ve el mes 6. I el mes 6, gairebé sempre, és on la transformació mor en silenci.

El que trobo quan em truquen al mes 9

Quan un CTO m'escriu per demanar-me que entri a revisar el seu setup d'IA, la conversa gairebé sempre comença igual: «ho vam implantar fa uns mesos, els developers estan contents amb les eines, però alguna cosa no funciona. No sabem què.»

Quan entro al repo i als workflows, sé exactament què hi trobaré. No ho sé per deducció — ho sé perquè ja ho he vist en dotze equips de desenvolupament de diferents verticals, mides i nivells de maduresa tècnica.

El diagnòstic és gairebé sempre el mateix: els workflows d'IA estan desactualitzats. Les regles de validació bloquegen coses que ja no haurien de bloquejar. La constitució del projecte continua dient coses que el codi ja no respecta. I ningú no ho ha actualitzat — no perquè l'equip sigui descurat, sinó perquè ningú no tenia el mandat de fer-ho.

Això és el mes 6.

Com funciona la transformació IA en els primers tres mesos

Per entendre per què el mes 6 és on es trenca tot, cal veure què passa abans.

Els primers dos o tres mesos d'una transformació IA ben feta són entusiasme amb mètode. L'equip instal·la els carrils: qui decideix què, qui revisa què, en quin punt del flux l'humà signa. Es defineix la constitució del projecte — el document que codifica les regles immutables que la IA ha de respectar: arquitectura, convencions de codi, restriccions de seguretat. S'estableixen els quality gates: què valida l'agent, què valida l'humà, què es bloqueja d'ofici.

Si el procés d'instal·lació està ben acompanyat, al mes tres l'equip veu resultats tangibles. Els cicles de PR review baixen. Els defectes en producció cauen. El temps d'onboarding de developers nous es redueix. L'equip sent que va més ràpid — i aquesta vegada, ho està mesurant, així que sap que no és només sensació.

L'organització conclou que la transformació ha funcionat. Aquesta conclusió és el primer error.

Anatomia del mes 6: el que es trenca i en quin ordre

La transformació no ha acabat al mes 3. Ha arrencat. I el que passa en els tres mesos següents determina si la inversió dels primers tres se sostindrà o s'evaporarà.

En els dotze equips que he acompanyat, el col·lapse del mes 6 segueix sempre el mateix ordre:

Primer

Es desactualitzen els workflows

La guia d'estil canvia, l'stack pivota, s'afegeixen dependències noves. La constitució del projecte continua dient el que deia al mes 1. L'agent genera codi conforme a regles que ja no reflecteixen la realitat. Ningú no ho ha actualitzat perquè «ja funcionava».

Després

Es disparen els falsos positius als quality gates

Les regles de validació comencen a bloquejar coses que ja no haurien de. L'equip comença a esquivar-los en silenci per no trencar el flux de delivery. Primer un developer. Després dos.

Llavors

Desapareix la constitució com a font de veritat

Els developers confien menys en el document versionat i més en el seu criteri personal. La consistència del codi generat per IA decau. Els code reviews s'allarguen perquè cal reescriure parts que l'agent va signar malament.

Al final

L'organització torna al punt de partida

Als 8-9 mesos la velocitat de delivery ha tornat al baseline previ. I al comitè tècnic la conversa és: «amb això no estem veient retorn, quina eina provem ara?» El bucle es tanca.

Per què sembla un problema tècnic quan no ho és

El col·lapse del mes 6 té una signatura operativa molt específica: quan passa, tots els símptomes apunten a l'eina. «Copilot signa coses que després cal reescriure.» «L'agent no entén la nostra arquitectura.» «Els tests que genera no cobreixen els casos que necessitem.»

Són símptomes reals. Però la causa no és l'eina. L'eina funciona exactament igual que al mes 1 — probablement millor, perquè el model subjacent ha millorat. El que ha canviat és el context en què opera. La constitució del projecte ja no reflecteix la realitat. Els carrils humà-agent estan desactualitzats. L'agent té menys informació fiable sobre què pot i què no pot fer en aquest projecte específic.

Actualitzar l'eina en aquest moment és comprar més velocitat per a un cotxe que no té carretera. El problema no és la velocitat. És la carretera.

Aquesta és la mateixa tesi que articula l'article del gap del 70%: el 70% de l'èxit de la IA en un equip no és tècnic, és organitzatiu. El col·lapse del mes 6 és aquest 70% fent-se visible de cop, després de mesos acumulant-se en silenci.

El sistema de sosteniment que evita el col·lapse

Després de veure el patró prou vegades, els elements que distingeixen els equips on la transformació continua funcionant al mes 9 i al mes 12 no són complicats. Però han d'existir de manera deliberada — no s'instal·len sols.

Peça 1

Owner rotatiu

Un rol rotatiu entre 2-3 senior devs amb criteri, que canvia cada sprint o cada dos sprints. Mandat únic: revisar si la constitució del projecte i els quality gates continuen reflectint la realitat del codi. Si no la reflecteixen, actualitza. Si la reflecteixen, no fa res. Són dues hores de feina per sprint.

Peça 2

Mètrica única de salut

El percentatge de PRs on l'agent va signar alguna cosa que l'humà va haver de revisar a fons — no un ajust menor, sinó una reescriptura significativa. Si aquesta mètrica puja mes a mes: workflows desactualitzats. Si baixa o s'estabilitza: aneu bé. Fàcil d'extreure de qualsevol eina de code review. No requereix dashboard sofisticat.

Peça 3

Ritual mensual de 30 minuts

Un cop al mes, l'owner rotatiu convoca 30 minuts amb Tech Lead + 1-2 seniors. Ordre del dia fix: revisar la mètrica única, revisar si la constitució necessita actualització, revisar si algun gate genera falsos positius que l'equip està esquivant. Si no hi ha res a actualitzar: 10 minuts i a córrer.

Quant costa no tenir el sistema

El cost del col·lapse no és només la pèrdua de productivitat. És el temps invertit a reconstruir la transformació quan ja està trencada.

En els dos casos on he entrat a reparar una transformació col·lapsada, el temps necessari per reconstruir els workflows, actualitzar la constitució del projecte, recalibrar els quality gates i tornar la confiança de l'equip en el mètode va ser d'entre sis i vuit setmanes. Sis a vuit setmanes de feina de l'equip, mentre continuava entregant en producció.

Comparat amb això, dues hores per sprint d'un senior dev rotant com a owner de sosteniment és una inversió trivial.

La frase que millor resumeix el problema

«Els agents encara no són prou fiables per a enginyeria complexa.»

— Andrej Karpathy

La conclusió operativa no és «no facis servir IA». És: fes-la servir amb context fiable i supervisió activa. Els workflows, la constitució del projecte, els quality gates — això és el context fiable. L'owner rotatiu i el ritual mensual — això és la supervisió activa.

Sense totes dues coses, l'eina no és menys capaç. Simplement està operant amb informació degradada sobre l'entorn en què treballa. I el resultat és el mes 6.

El mes 6 no és inevitable. És el resultat d'assumir que la transformació acaba el dia que la instal·les.

Si portes un equip de desenvolupament i vols diagnosticar si el teu setup actual aguantarà més enllà del mes 6, l'article amb les cinc dimensions organitzatives i les quatre preguntes per al comitè és el punt de partida: El gap del 70%.

Si vols parlar de com hem instal·lat el sistema de sosteniment en els equips que acompanyem: info@onext.es · assumpte «sosteniment IA mes 6».

Jordi García
Escrit per
Jordi García
Tech Lead a onext

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 →

La teva transformació IA té sistema de sosteniment?

A onext instal·lem el sistema complet — carrils, constitució del projecte, quality gates i pla de sosteniment — sense paralitzar lliuraments.

Veure com treballem

Sense paralitzar lliuraments. Sense mesos de planificació.