La majoria d'equips que han incorporat IA al seu desenvolupament continuen mesurant el seu rendiment exactament igual que fa tres anys. Velocitat. Story points. Nombre de tickets tancats. Hores imputades. El problema no és la IA. El problema és que el sistema de mesura no ha evolucionat.
I quan canvies la manera de produir programari però no canvies la manera de mesurar-lo, les mètriques comencen a mentir.
El problema: continuem mesurant equips amb mètriques pre-IA
Abans de la IA generativa, el cost de produir codi era relativament proporcional a l'esforç humà. Avui no.
Un desenvolupador amb IA pot generar més codi en menys temps, prototipar més ràpid i resoldre tasques repetitives en segons. Però això no significa necessàriament que l'equip lliuri més valor.
Les mètriques tradicionals comencen a distorsionar-se:
Si la IA redueix l'esforç d'implementació, els story points deixen de representar complexitat real.
Un augment de velocitat pot amagar un augment de retreball.
Més línies poden significar més deute tècnic.
Tancar més tasques no implica que el producte avanci estratègicament.
Què canvia realment quan la IA entra a l'equip
1. El cost marginal del codi tendeix a zero
El codi deixa de ser el recurs escàs. L'escàs passa a ser:
- La claredat en les decisions
- El context compartit
- La qualitat arquitectònica
Quan el codi és barat, les males decisions són molt més cares.
2. El coll d'ampolla es desplaça
Abans el coll d'ampolla era tècnic. Ara sol estar a:
- Definició de problema
- Priorització
- Arquitectura
- Alineació entre producte i tecnologia
La IA accelera. Amplifica les bones pràctiques, l'arquitectura sòlida i les decisions clares.
La IA multiplica el caos. Més codi inconsistent, més variabilitat, més deute acumulat en menys temps.
3. El risc arquitectònic augmenta
La IA pot generar solucions "aparentment correctes" que no respecten patrons del sistema, introdueixen complexitat innecessària i dificulten el manteniment futur.
Si no hi ha un sistema sòlid (SDD, context estructurat, criteris clars), l'impacte apareix mesos després.
Les 5 mètriques que sí que importen en equips que treballen amb IA
Si el codi ja no és el coll d'ampolla, què hauríem de mesurar? Aquestes són les mètriques que realment indiquen productivitat sostenible.
No des de "In Progress". Des de la decisió estratègica fins que la funcionalitat genera impacte en producció.
Si la IA funciona, aquest número hauria de reduir-se de manera consistent.
Quant del codi generat necessita ser reescrit, refactoritzat o corregit en menys de 30 dies?
Si aquest ràtio puja, la IA no està accelerant: està generant deute més ràpid.
Cada feature s'hauria d'analitzar en termes de complexitat afegida, acoblaments nous i cost futur de manteniment.
Si el deute creix més ràpid que la capacitat de simplificar, el sistema es degrada.
Quant tarda l'equip a entendre correctament què ha de construir? Quan la implementació és ràpida, els errors d'interpretació es tornen més cars.
Aquí és on realment es guanya productivitat.
En lloc de mesurar output tècnic, mesura impacte generat per cada decisió presa i valor lliurat per cicle estratègic.
Un equip madur amb IA no produeix més codi. Produeix millors decisions per unitat de temps.
Mètriques que hauries d'abandonar (o reinterpretar)
No significa que les hagis d'eliminar, però sí deixar de fer-les servir com a mètriques principals:
Mètriques d'activitat, no d'impacte
A l'era de la IA, mesurar activitat és perillós: pot donar sensació de progrés mentre augmenta la fragilitat del sistema.
Mini diagnòstic per a CTOs
Si estàs incorporant IA al teu equip, fes-te aquestes preguntes:
Autodiagnòstic: la IA està amplificant problemes estructurals?
Si respons "sí" a tres o més, la IA probablement està amplificant problemes estructurals.
Conclusió: mesurar malament és més perillós que implementar malament
Implementar IA sense canviar el sistema és arriscat. Però mesurar malament l'impacte és encara pitjor.
Perquè pots creure que estàs accelerant quan en realitat estàs acumulant complexitat.
A l'era de la IA, el codi deixa de ser el coll d'ampolla.
El sistema passa a ser-ho.
I si vols saber si el teu equip està millorant realment la seva productivitat, comença per mesurar el que ha canviat.
El que SDD resol: A onext implementem Spec-Driven Development precisament perquè els equips mesurin el que importa: impacte per decisió, no output per hora. Especificacions estructurades que alineen l'equip abans d'escriure codi. Els equips que treballen amb SDD redueixen un 75% el temps per feature perquè eliminen retreball des de l'origen: la definició.
Lectura complementària: Qualitat del codi a l'era de l'AI Coding | Mesures incidències, però ignores les mètriques que importen
Metodologia: A onext ajudem els CTOs a redissenyar els seus sistemes de mesura com a part dels nostres Centres d'Excel·lència d'IA. De mètriques d'activitat a mètriques d'impacte sostenible.
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 →