Si fa mesos que pagues llicències premium de Copilot, Cursor o Windsurf per a tot el teu equip de desenvolupament i la conversa interna continua sent «no estem veient el retorn que esperàvem», és molt probable que estiguis atacant el 30% del problema. L'altre 70% — el que cap vendor no et vendrà perquè no es compra en una factura — és organitzatiu. Aquesta peça explica què hi ha en aquest 70%, per què el confons amb problema tècnic cada trimestre, i les quatre preguntes concretes que el teu proper comitè de tecnologia pot fer servir per distingir totes dues coses.
El malentès més car del trimestre
Fa uns quants mesos que veig el mateix patró en CTOs i VPs d'Engineering d'empreses mitjanes. La conversa amb el seu equip de direcció es reprodueix amb un guió gairebé idèntic: «hem invertit x milers d'euros en llicències de Copilot per als developers; l'enquesta interna diu que l'equip està content amb l'eina; però la velocitat de release no ha canviat, els bugs en producció continuen pujant, i el ràtio de PR review no millora».
És exactament el patró que veiem en empreses mitjanes que passen de llicències per developer al model operatiu d'una plataforma IA empresarial governada pel client: el problema no es resol afegint més seients de Copilot, sinó redefinint com s'opera amb IA al nivell de l'organització.
Quan la conversa arriba al CFO o al consell, la pregunta que apareix sobre la taula és aquesta: «què fem? Comprem una altra eina més potent? Pugem a Cursor Enterprise? Contractem Copilot Workspace?». La intuïció natural és escalar la inversió tècnica: si una eina no retorna, una altra de millor sí que ho farà.
Aquesta intuïció és el que a onext anomenem el malentès del 70%. I és la raó per la qual més del 40% dels projectes basats en agents seran cancel·lats abans de finals de 2027, segons Gartner.
La xifra que pocs vendors t'explicaran
Després de treballar amb dotze equips de desenvolupament que han completat el nostre programa de transformació amb IA — equips d'entre vint i dos-cents developers — la pauta que veiem consistentment és aquesta: aproximadament el 70% de l'èxit de la IA en un equip no és tècnic. És organitzatiu.
El 30% restant sí que és tècnic: l'eina que es contracta, el model, l'stack, la integració amb l'IDE. És important. Però està acotat, és relativament fàcil de comprar, i tots els vendors del mercat competeixen per aquest 30%. L'altre 70% — el que de veritat separa equips productius d'equips encallats — viu en cinc dimensions organitzatives que cap eina no resol tota sola. Són les cinc que una plataforma enterprise com onext Enterprise AI està dissenyada per operacionalitzar des del primer dia — no com a add-on, com a capa primària.
Les cinc es dissenyen amb mètode. No es compren. I això explica per què el CTO que només compra eines millors, cicle rere cicle, continua veient el mateix resultat: l'eina funciona, el problema persisteix.
L'estudi METR com a evidència del gap
L'estudi del Model Evaluation & Threat Research Institute va documentar una cosa que convé tenir sobre qualsevol taula de comitè tècnic: en el seu experiment sobre developers experimentats, els participants que feien servir IA van reportar +20% de productivitat subjectiva mentre eren −19% menys productius mesurats en commits útils, cicle de PR review i defectes en producció.
La paradoxa no és defecte de la tecnologia — la tecnologia en aquell experiment era de primera classe. La paradoxa és la conseqüència directa del gap organitzatiu: developers accelerats per l'eina sense mètode perden temps revisant PRs que l'agent va signar malament, reescrivint tests que l'agent no va entendre, en debugging de bugs latents que el codi generat no exhibeix immediatament. L'acceleració de l'input no es tradueix en acceleració de l'output útil. L'equip sent que va més ràpid. L'equip va més lent.
Aquesta és la signatura operativa del 70% que falta.
Les quatre preguntes per al teu proper comitè
Si portes el tema d'adopció IA al següent comitè tècnic de la teva organització, aquestes són les quatre preguntes que distingeixen un problema tècnic d'un problema organitzatiu.
Pregunta 1: Tenim definits per escrit els carrils humà-agent en cada workflow crític, o cada developer els improvisa amb el seu criteri? Si la resposta és «els improvisa», el problema no és l'eina — és l'absència de govern operatiu. Comprar millor eina no ho resol.
Pregunta 2: Mesurem productivitat real (commits útils, cicle PR, defectes producció, temps onboarding) o productivitat percebuda (com de ràpids ens sentim)? Si la resposta és «percebuda», probablement estem en la paradoxa METR. Comprar millor eina amplifica la paradoxa, no la resol.
Pregunta 3: Tenim persones amb criteri a l'equip per definir i actualitzar els quality gates, o l'equip espera que el vendor ho faci per ells? Si la resposta és «ho fa el vendor», l'organització ha cedit la governança al proveïdor. Això no és transformació — és dependència.
Pregunta 4: L'organització té un pla de sosteniment a sis mesos, o estem assumint que l'eina s'actualitza sola i els processos també? Si la resposta és «assumim que s'actualitza sola», el sosteniment no existeix. La corba s'aplanarà als sis-nou mesos i tornaràs a estar en la conversa d'avui.
Si les quatre respostes apunten a un gap organitzatiu (no tècnic), el següent pas no és comprar una altra llicència. És dissenyar el model operatiu enterprise que tanca aquest gap per mètode — exactament el que fem a onext Enterprise AI per a equips de desenvolupament de 100 a 1.000 persones.
El benchmark intern que sosté la tesi
Quan diem «el 70% de l'èxit de la IA és organitzatiu» no és una intuïció. És la pauta acumulada de dotze equips de desenvolupament als quals hem acompanyat en transformació amb IA — programa d'entre dotze i setze setmanes, amb quatre fases solapades (diagnòstic, redisseny, desplegament, transferència). El resultat consistent quan el programa s'executa bé:
- ×7 velocitat de delivery (cas particular de cada equip, depenent del baseline previ).
- 0 sprints perduts durant el redisseny organitzatiu.
- −50% time-to-production: la meitat del temps entre que el ticket surt de Discovery i aterra en producció.
- +40% consistència de codi mesurada en linting, cobertura de tests i rework post-merge.
- 1-2 FTE senior/any alliberats per equip en tasques ara absorbibles per agents supervisats.
Les cinc xifres vénen del redisseny organitzatiu. L'eina és la mateixa — Claude, principalment, amb Cursor o Copilot a l'IDE. El que canvia és com l'equip es relaciona amb l'eina.
La cita honesta que tanca la conversa
«Els agents encara no són prou fiables per a enginyeria complexa.»
— Andrej Karpathy
Qui ho diu 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.
I el mètode no es compra. Es dissenya, s'instal·la a l'equip, es manté. Les cinc dimensions organitzatives que vaig descriure a dalt — carrils, mètriques, governança de gates, formació dual, sosteniment — són aquest mètode. I són el que el 30% del problema tècnic resolt per Copilot, Cursor o el model del trimestre mai no cobrirà.
Si al teu proper comitè tècnic la conversa és «no veiem retorn amb la IA, quina eina comprem ara?», tens el diagnòstic equivocat. El retorn no vindrà de l'eina — vindrà del mètode amb què la teva organització opera amb ella.
Hem preparat quatre preguntes per al teu proper comitè que distingeixen problema tècnic de problema organitzatiu en menys de deu minuts. Una pàgina A4, sense email obligatori:
→ Descarrega les 4 preguntes per al teu proper comitè
Si les quatre respostes et deixen incòmode, parlem-ne: info@onext.es — assumpte «auditoria organitzativa IA». Conversa de 30 minuts sense compromís.
Fonts: estudi METR sobre productivitat de developers amb eines IA (paradoxa +20%/−19%); Gartner sobre cancel·lació de projectes basats en agents abans de 2027; declaracions públiques d'Andrej Karpathy sobre fiabilitat d'agents en enginyeria complexa.
Lectura complementària: El mes 6: el sistema de sosteniment que ho evita · Els 3 claims canònics de l'AI Engine
