Un exemple inventat, però versemblant: es demana a un agent que afegeixi un camp a un mòdul de facturació de fa quinze anys. L'agent llegeix el codi, veu que l'arrodoniment es fa en un ordre poc habitual, l'«arregla» de passada i deixa els tests en verd. Tres setmanes després, l'informe que un client concilia cada mes amb la seva comptabilitat no quadra per uns cèntims per línia. L'arrodoniment estrany no era un error: era el comportament del qual depenia aquest client.
Ningú no va fer res malament, en aparença. L'agent va trobar una cosa que semblava un error i la va corregir. El problema és que ningú no li havia dit quin comportament no podia canviar, perquè ningú no l'havia escrit mai. En un sistema legacy, la documentació més fiable és el mateix codi, amb les seves casualitats incloses. I un agent que treballa sense saber quines d'aquestes casualitats són contracte és un risc, per bo que sigui el model.
El que la IA ja fa bé amb el legacy
Convé començar pel que funciona, perquè funciona molt. El novembre de 2025, el Technology Radar de Thoughtworks va col·locar a «Adopt», la seva categoria més alta, l'ús d'IA generativa per entendre codi legacy: segons la seva experiència amb diversos clients, ha passat a ser «una opció pràctica per defecte, no un experiment». Eines com Claude Code, Cursor o Copilot fan aflorar regles de negoci, resumeixen la lògica i identifiquen dependències en sistemes que ningú de l'equip actual no va escriure. Ho expliquem amb més detall a GenAI per comprendre codi legacy.
El cas més citat és el de Morgan Stanley. Segons va publicar The Wall Street Journal el juny de 2025, recollit per Entrepreneur, l'eina interna DevGen.AI havia revisat nou milions de línies de codi antic en cinc mesos, amb un estalvi estimat de 280.000 hores de desenvolupament. El més interessant és què fa exactament: tradueix codi en llenguatges antics a especificacions en anglès planer, que els desenvolupadors fan servir després com a referència per reescriure'l. No escriu el codi nou; això continua sent feina de persones.
És a dir, el valor no és que la IA reescrigui el sistema, sinó que produeixi un text que digui què fa. Aquest text és el punt de partida correcte. El que cal entendre és quin tipus de text és.
Una descripció no és una especificació
Quan una IA llegeix codi legacy i explica el que fa, produeix una descripció. Diu el que el codi fa, no el que hauria de fer. Inclou l'arrodoniment estrany, el camp que s'omple amb zeros quan arriba buit i el cas límit que es resol de manera inesperada perquè el 2011 algú tenia pressa. Una especificació és una altra cosa: diu el que el sistema ha de fer i algú la signa.
La diferència importa perquè en un sistema amb usuaris reals, bona part del que sembla un error és, a la pràctica, un contracte. Ho va formular Hyrum Wright, i avui es coneix com la llei de Hyrum: amb prou usuaris d'una API, tant és el que prometi el contracte, algú dependrà de qualsevol comportament observable del sistema. Un sistema legacy fa anys que acumula usuaris de comportaments que ningú no va prometre.
El mateix Radar de Thoughtworks ho apunta en una altra entrada de novembre de 2025, en què proposa fer servir descripcions generades per IA com a pas intermedi per reescriure sistemes: l'objectiu no és amagar els detalls d'implementació, sinó introduir «una abstracció temporal» que permeti raonar sobre què fa el sistema abans de decidir com refer-lo. Temporal és la paraula clau. La descripció és una eina per pensar, no un requisit.
Dos documents, no un
D'aquí surt la idea central d'aquesta peça. Abans que un agent modifiqui un mòdul heretat, calen dos documents diferents, amb regles diferents:
| Acta del comportament actual | Especificació del canvi | |
|---|---|---|
| Què afirma | El que el codi fa avui, errors inclosos | El que serà diferent després del canvi, i res més |
| Qui la produeix | La IA llegeix el codi; una persona revisa i marca el que és sospitós | Una persona, amb qui coneix el negoci |
| Com es verifica | Amb tests de caracterització que fixen cada comportament | Amb tests nous que fallen abans del canvi i passen després |
| Qui la signa | Ningú: és una acta, no un requisit | Qui respon del canvi |
| Què pot fer l'agent | Res que la contradigui, llevat del que digui l'especificació del canvi | Implementar exactament això |
| Quant viu | Mentre existeixi el mòdul; s'actualitza amb cada canvi aprovat | Fins que el canvi s'integra; després passa a l'acta |
Proposta d'onext. Els noms són el de menys; el que importa és no barrejar els dos documents
La regla que fa funcionar el parell és simple: l'agent només pot canviar un comportament de l'acta si l'especificació del canvi l'anomena. Tota la resta es queda com està, encara que sembli un error. Si l'agent troba una cosa sospitosa, l'apunta; no l'arregla. Arreglar-la és una decisió de negoci, i entra a la següent especificació del canvi amb la seva signatura i el seu test.
En l'exemple de l'arrodoniment, l'acta hauria dit «l'import s'arrodoneix per línia abans de sumar, no sobre el total», amb un test que ho fixa i una marca de «sospitós, preguntar a finances». L'agent hauria afegit el camp sense tocar l'arrodoniment. I algú hauria preguntat, en lloc d'assabentar-se'n pel client.
És la mateixa lògica que defensem per a codi nou a l'especificació és on se signa, amb una diferència: en legacy hi ha un document previ que ningú no signa, perquè ningú no el va decidir. Només es constata.
La xarxa: tests de caracterització
Una acta en text és una hipòtesi. La IA pot haver entès malament una branca, i el text no ho dirà. El que converteix l'acta en una cosa fiable és fixar cada afirmació amb un test que s'executa.
Per a això existeix des de fa vint anys una tècnica amb nom propi. Michael Feathers va encunyar el terme test de caracterització el 2004, a Working Effectively with Legacy Code: un test que descriu el comportament real d'un codi existent per protegir-lo de canvis no intencionats. No diu si el codi és correcte; diu si ha canviat. Quan un falla, algú decideix si el canvi era el que es buscava.
Aquí hi ha un gir que convé assenyalar, perquè contradiu una cosa que hem escrit. A tests generats per IA expliquem que un test escrit a partir del codi no el prova: només el descriu, i per això no detecta errors. En codi nou és un problema. En legacy és justament el que es busca. Un test de caracterització és, per definició, una descripció del codi. Que la IA els generi de pressa i en quantitat és un avantatge real, amb una condició: algú revisa quins comportaments s'han fixat i marca els que són errors coneguts, perquè d'aquí a un any ningú no els llegeixi com a requisits.
Especificar la costura, no el sistema
L'objecció òbvia és el cost. Especificar tot un sistema legacy abans de tocar-lo és un projecte de mesos que queda obsolet abans d'acabar. I les eines de Spec-Driven Development no ajuden tant com caldria esperar: en la seva anàlisi de Kiro, Spec Kit i Tessl d'octubre de 2025, Birgitta Böckeler va apuntar que introduir-ne dues en un codi existent semblava costar encara més feina, i en provar Kiro amb un error petit el flux complet li va semblar com fer servir una maça per trencar una nou.
La sortida és la que fa servir la modernització gradual des de fa vint anys. Martin Fowler en diu strangler fig: en lloc de reescriure de cop, s'identifiquen costures per on dividir el sistema i es va movent funcionalitat a poc a poc, de manera que la inversió i el retorn també arriben a poc a poc. Aplicat a les especificacions, vol dir especificar només la costura per on entra el canvi: el mòdul que es tocarà, les seves entrades i sortides, i els comportaments que els seus veïns n'esperen. L'acta creix al ritme dels canvis, no abans.
A la pràctica, l'ordre és aquest. Primer, la IA llegeix el mòdul i redacta l'acta. Segon, es generen els tests de caracterització i una persona marca el que és sospitós. Tercer, s'escriu l'especificació del canvi, curta, anomenant cada comportament de l'acta que canviarà. I només aleshores actua l'agent, amb la instrucció explícita de no canviar res més. La revisió del resultat ja no pregunta «això està bé?», que en legacy gairebé ningú no pot respondre, sinó «ha canviat alguna cosa que no fos a l'especificació?», que els tests contesten sols. És la pregunta que vam proposar a la revisió que encara espera un autor.
El que es guanya, a més del canvi
Hi ha un efecte secundari que sol valer més que el mateix canvi: després d'unes quantes iteracions, l'equip té per primera vegada un document fiable del que fa el sistema, avalat per tests que ho demostren. És el que gairebé cap sistema legacy no té, i el que fa possible tota la resta, des de la següent modificació fins a una migració completa. I és exactament el tipus d'artefacte que Spec-Driven Development posa al centre: no el codi, sinó la descripció verificable del que ha de fer.
El que no es guanya és velocitat en el primer canvi. El primer costa més que demanar a l'agent que el faci directament. El segon, al mateix mòdul, costa menys. I el tercer és el que es pot delegar amb tranquil·litat, perquè la xarxa ja hi és. També és una bona manera de veure què sap fer un desenvolupador: qui troba un comportament estrany i l'apunta en lloc d'arreglar-lo està demostrant el criteri que descrivim a què mesurar en contractar desenvolupadors.
Preguntes freqüents
Es pot aplicar Spec-Driven Development a un sistema legacy?
Sí, però no començant per especificar tot el sistema. Les eines de SDD es van pensar sobretot per a codi nou, i Birgitta Böckeler, de Thoughtworks, va apuntar l'octubre de 2025 que introduir-ne dues de les tres que va analitzar en un codi existent semblava costar encara més feina. El que funciona és especificar només la part que es tocarà, amb dos documents diferents: un que descriu el que el codi fa avui i un altre que diu què canviarà.
Quina diferència hi ha entre una descripció del codi i una especificació?
Una descripció diu el que el codi fa, inclosos els seus errors i les seves casualitats. Una especificació diu el que ha de fer, i algú la signa. Quan una IA analitza codi legacy produeix descripcions, i són molt útils. El problema apareix quan es tracten com a especificacions i un agent «corregeix» un comportament que algú a producció necessita tal com és.
Què és un test de caracterització?
És un test que fixa el comportament real d'un codi existent, no el que hauria de tenir. El terme el va encunyar Michael Feathers el 2004, a «Working Effectively with Legacy Code». No serveix per saber si el codi és correcte, sinó per saber si ha canviat: si un test de caracterització falla després d'una modificació, algú ha de decidir si aquest canvi era el que es buscava o un efecte secundari.
Pot la IA generar els tests de caracterització?
Sí, i és un dels pocs casos en què un test generat a partir del codi és exactament el que cal. En codi nou, un test escrit des de la implementació només la descriu. En legacy, descriure el comportament actual és l'objectiu. La condició és que una persona revisi quins comportaments s'han fixat i marqui els que són errors coneguts, perquè ningú no els confongui amb requisits.
Què faig amb els bugs que troba la IA en analitzar el codi legacy?
Apuntar-los, no arreglar-los en la mateixa passada. Un comportament estrany pot ser un error o una cosa de la qual depèn un client, un informe o una integració que ningú no recorda. Es fixa amb un test de caracterització marcat com a sospitós, es pregunta a qui coneix el negoci i, si es decideix corregir-lo, entra a l'especificació del canvi com una modificació explícita, signada i amb el seu propi test.
Quina part del sistema cal especificar abans de començar?
El mínim per al canvi que es farà: el mòdul o la costura per on entra la modificació, les seves entrades i sortides i els comportaments que no poden canviar. Especificar tot un sistema legacy abans de tocar-lo és un projecte de mesos que queda obsolet abans d'acabar. S'especifica a trossos, al ritme dels canvis, com en una migració gradual.
Fonts
- Thoughtworks Technology Radar (novembre de 2025), «Using GenAI to understand legacy codebases» (Adopt) i «GenAI for forward engineering» (Assess).
- Birgitta Böckeler, «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 d'octubre de 2025.
- Entrepreneur, sobre DevGen.AI de Morgan Stanley, 3 de juny de 2025, a partir de la informació de The Wall Street Journal.
- Hyrum Wright, Hyrum's Law.
- Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004); definició de test de caracterització.
- Martin Fowler, «Strangler Fig», martinfowler.com, 22 d'agost de 2024.
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 →