Deute tècnic i pair programming amb IA: la guia del CTO per gestionar-lo amb intel·ligència
El deute tècnic és l'únic problema que tots els CTOs amb qui parlo admeten tenir — i que gairebé cap no pressuposta.
He passat prou anys dins de codebases enterprise per dir-ho sense embuts: el deute tècnic no és un problema que se solucioni, és un problema que es gestiona. Totes les organitzacions d'enginyeria n'acumulen. La pregunta no és si tens deute; és si les decisions sobre el deute les prens deliberadament o per accident.
El que ha canviat el 2025 és que l'economia d'amortitzar deute s'ha capgirat. El pair programming amb IA — no com a novetat, no com l'autocomplete de Copilot, sinó com un co-desenvolupador de debò — ha reduït el cost del refactoring, les migracions i la modernització a una fracció del que costaven fa 18 mesos. Això no t'arregla el problema de deute per si sol. Però sí que vol dir que les converses sobre deute que anaves ajornant perquè «no tenim temps» ara tenen una resposta diferent.
Aquest és el playbook que jo seguiria per gestionar el deute tècnic amb intel·ligència el 2025.
Què és realment el deute tècnic (i què no és)
La majoria de discussions sobre deute tècnic fracassen perquè el terme es fa servir amb imprecisió. Abans de muntar cap framework de gestió, categoritza bé.
Deute deliberat: compromisos conscients en què vas triar velocitat per davant de perfecció. Una startup que treu un MVP amb tests mínims, una scale-up que ajorna un refactor perquè la funcionalitat no podia esperar. És deute útil — va servir per comprar alguna cosa valuosa. Cal fer-ne seguiment i, tard o d'hora, pagar-lo.
Deute heretat: codi escrit per gent que ja no és a l'equip, o per a requisits que ja no existeixen. És la categoria més habitual. Sol ser més car d'arreglar del que sembla, perquè el context original s'ha perdut.
Deute arquitectònic: decisions estructurals de fons que ja no encaixen amb l'escala del sistema, els casos d'ús o l'estructura de l'equip. És la categoria més cara. Proliferació de microserveis, monòlits que s'haurien d'haver partit fa tres anys, models de dades que no donen per a noves línies de producte.
Deute accidental: codi trencat o ineficient perquè el van escriure enginyers que no en sabien prou. És la categoria més barata d'atacar de manera aïllada — aquí el pair programming amb IA hi excel·leix — però el problema organitzatiu (contractació, qualitat de les revisions, mentoria) sovint pesa més que el codi.
Deute per deteriorament: codi que estava bé quan es va escriure però que s'ha fet malbé perquè l'ecosistema del voltant ha avançat. Biblioteques deprecated, frameworks a final de vida, vulnerabilitats de seguretat a les dependències. S'acumula constantment si no el gestiones de manera activa.
Cada categoria demana un enfocament diferent. Tractar-les totes igual és el motiu pel qual fracassen la majoria d'«iniciatives de reducció de deute tècnic».
Mesura el deute en cost de negoci, no en mètriques de codi
No pots gestionar allò que no mesures. Però «mesurar el deute tècnic» sol voler dir alguna cosa vaga — puntuacions de complexitat del codi, percentatges de cobertura de tests, avisos del linter. Això són senyals, no mesures.
Les mesures que importen són les que connecten el deute amb el cost per al negoci:
Impacte en la velocitat: quant més lenta surt una funcionalitat típica en una zona carregada de deute que en una de neta? Mesura-ho comparant funcionalitats de complexitat similar a diferents parts del codebase. Una diferència de 3x és habitual, i material.
Correlació amb incidents: quin percentatge dels incidents de producció té l'origen en codi legacy? Si passa del 40%, el deute t'està costant més del que t'estalvies ajornant-lo.
Temps d'onboarding: quant triga un enginyer sènior acabat d'arribar a ser productiu a cada zona del codebase? A les zones amb molt deute triga 2–3 vegades més. És un cost real cada vegada que contractes.
Risc de canvi: quina probabilitat hi ha que un canvi no trivial en un mòdul provoqui una regressió en un altre lloc? Un risc de canvi alt és un símptoma directe de deute arquitectònic.
Sentiment dels desenvolupadors: una enquesta trimestral als enginyers preguntant quines zones eviten. Les zones que tothom evita solen ser allà on el deute està matant la velocitat.
Aquestes mesures no necessiten cap dashboard. Necessiten existir en algun lloc on l'equip les pugui veure, perquè el deute es faci visible en lloc de quedar invisible.
Prioritza per impacte de negoci, no pel que empipa els enginyers
Amb les mesures a lloc, prioritzar el deute esdevé abordable. El framework que funciona:
| Impacte / Esforç | Arreglar-ho costa poc | Arreglar-ho costa molt |
|---|---|---|
| Alt impacte de negoci | Fes-ho ara mateix — són els guanys fàcils que recuperen valor compost | Planifica-ho i finança-ho — són les iniciatives arquitectòniques que necessiten capacitat dedicada |
| Baix impacte de negoci | Arregla-ho de manera oportunista quan ja siguis dins del codi | No ho arreglis — accepta el deute, documenta'l i passa pàgina |
Els errors habituals:
- Tractar tot el deute com d'alt impacte perquè els enginyers se'n queixen. Els enginyers es queixen del deute que els empipa, que no sempre és el deute que fa mal al negoci.
- Tractar tot el deute com d'alt esforç perquè hi ha una peça difícil que es veu molt. La major part del deute té arranjaments barats si els busques.
- Arreglar deute que ningú no ha demanat arreglar perquè «és el que toca». Les correccions de deute haurien d'anar lligades a prioritats de producte, no a estètica d'enginyeria.
El resultat de la priorització hauria de ser una llista curta: els 3–5 ítems de més impacte i menys esforç que s'abordaran aquest trimestre, més les 1–2 iniciatives arquitectòniques que es planifiquen i es financen a part.
El pair programming amb IA com a eina d'amortització de deute
És aquí on el 2025 és genuïnament diferent del 2023. El pair programming amb IA — al nivell de Cursor, Claude Code, Copilot Workspace o eines similars — ja no és una ajuda a la productivitat en feina greenfield. És un multiplicador seriós per a la feina metòdica i carregada de context que demana amortitzar deute.
Les tasques concretes on el pair programming amb IA excel·leix:
1. Migracions de llenguatge i de framework
Passar de JavaScript a TypeScript, de Python 2 a Python 3, d'Express a Fastify, de class components a hooks. Són feines mecàniques però sensibles al context — d'aquelles que a un sènior li costen setmanes i a un júnior, mesos. Ben utilitzat, el pair programming amb IA ho comprimeix a dies.
El patró que funciona: un enginyer sènior emparellat amb un assistent d'IA fa uns quants fitxers a mà, codifica els patrons en un prompt ben especificat, i després fa servir la IA per executar la mateixa transformació a la resta del codebase amb revisió humana. El paper de l'enginyer passa d'escriure a revisar i caçar edge cases — un guany d'efecte palanca de 5–10x.
2. Millores de cobertura de tests
Afegir tests a codi legacy és una feina ingrata i carregada de context, perfecta per al pair programming amb IA. Amb una funció i uns quants casos de test d'exemple, la IA actual genera scaffolding de tests útil més de pressa que un enginyer. El paper de l'enginyer és verificar que els tests posin a prova la lògica de debò, afegir els edge cases que la IA hagi passat per alt i detectar quan una funció «coberta» continua fonamentalment trencada.
3. Documentació i comentaris de codi
Molt deute és, en el fons, deute de context — codi que funciona però que ningú no recorda per què. El pair programming amb IA pot llegir un mòdul, extreure'n el comportament i generar documentació arquitectònica amb una qualitat raonable. Només això ja amortitza l'eina a la majoria d'equips.
4. Refactoring per millorar la llegibilitat
Reanomenar variables perquè s'entenguin, extreure funcions auxiliars, partir funcions llargues, eliminar codi mort. La IA fa el gruix de la feina mecànica; l'enginyer verifica que el refactor millori les coses de debò.
5. Actualitzacions de dependències i pedaços de seguretat
Actualitzar un framework sovint demana centenars de canvis petits — imports, signatures d'API, patrons deprecated. El pair programming amb IA pot fer aflorar l'abast complet dels canvis necessaris, esbossar les modificacions i marcar les zones que demanen criteri humà. El que abans costava un sprint pot costar una tarda.
On el pair programming amb IA no funciona
Per ser precisos amb els límits:
- Redissenys arquitectònics. La IA pot ajudar a implementar una arquitectura nova, però no et pot dir quina és l'arquitectura correcta. Les decisions estratègiques demanen criteri sènior.
- Entendre el coneixement tribal. Si el deute existeix per una regla de negoci que no és ni al codi ni als comentaris, a la IA se li escaparà. L'arqueologia humana continua sent necessària.
- Deute entre sistemes. El pair programming amb IA rendeix sobretot amb deute a nivell de codi. El deute a nivell de sistema — serveis que s'haurien de consolidar, models de dades que travessen fronteres de responsabilitat — demana feina estratègica humana.
Desplega la IA com a eina de la squad, no com a avantatge individual
La majoria d'equips no extreuen tot el valor del pair programming amb IA perquè el despleguen com a eina de productivitat individual. El patró de desplegament que multiplica la velocitat d'amortització de deute:
1. Squads dedicades a amortitzar deute
En lloc d'escampar la feina de deute per tot l'equip, reserva 2–4 enginyers amb el pair programming amb IA com a eina principal, centrats en una àrea de deute concreta durant una finestra de temps concreta. El focus concentrat més l'efecte palanca de la IA donen resultats que l'esforç dispers no pot igualar.
2. Biblioteca compartida de prompts
Els enginyers que treuen més profit del pair programming amb IA tracten els prompts com a artefactes. Desen els que funcionen per a cada tipus de refactoring, els comparteixen amb l'equip i els van refinant. Una biblioteca compartida de 30–50 prompts provats per a patrons de deute habituals val més que la majoria d'eines.
3. Cultura de revisar primer
El pair programming amb IA funciona quan els humans ho revisen tot. Falla quan els humans aproven l'output de la IA sense mirar-se'l. Una squad d'amortització de deute hauria de tenir com a mínim una ràtio 2:1 de temps de revisió respecte de generació, amb els sèniors marcant el llistó de qualitat.
4. Mesura abans i després
Tota iniciativa d'amortització de deute hauria de tenir mesures d'abans i de després en les mètriques que importen: cobertura de tests, taxa d'incidents, risc de canvi, sentiment dels desenvolupadors. Si no, només estàs remenant codi.
Les eines no arreglen el deute: les organitzacions, sí
I les organitzacions només l'arreglen quan ho decideixen. La disciplina que separa les que gestionen bé el deute de les que es limiten a acumular-lo:
El deute es finança, no es tolera. El pressupost d'enginyeria assigna capacitat explícita a amortitzar deute. Típicament entre el 15 i el 25% de la capacitat d'enginyeria. No «quan tinguem temps» — capacitat compromesa.
Les decisions de deute es documenten. Cada decisió de deute deliberat es recull en un ADR breu (architectural decision record) que explica què es va triar, per què, i quant costaria pagar-ho més endavant. Això evita el problema del «no sabem per què això és aquí».
Les revisions de deute són trimestrals. Cada trimestre, el CTO i els tech leads revisen el registre de deute, les mesures i el pla d'amortització. És el mecanisme que evita que el deute torni a quedar invisible.
La velocitat d'amortització es mesura. La quantitat de deute amortitzat per trimestre hauria de ser mesurable i anar en la bona direcció. Si no hi va, o falla l'assignació de capacitat o falla la priorització.
Les squads nearshore desencallen la política de la feina de deute
Un patró que funciona especialment bé per a organitzacions amb problemes de deute de debò: fer servir capacitat d'enginyeria nearshore com a squads dedicades a amortitzar deute.
La lògica: amortitzar deute és feina d'alt impacte però políticament poc lluïda. Els equips interns s'hi resisteixen perquè no es veu a les demos. Les squads nearshore, desplegades en col·laboracions acotades de 3–6 mesos específicament per amortitzar deute, tenen el focus i el nivell per executar sense la fricció política.
L'estructura de col·laboració que funciona:
- Sessió de descoberta amb un CTO per entendre el mapa del deute i prioritzar què val la pena abordar.
- Disseny de la squad: 2–4 enginyers sèniors nearshore més un tech lead, amb pair programming amb IA com a eina estàndard.
- Abast acotat: mòduls concrets, resultats concrets, mesurables abans i després. No «reduir el deute» — «retirar el middleware d'autenticació legacy i consolidar tres response handlers abans de final de Q3».
- Pla de traspàs: transferència clara de la propietat de tornada a l'equip intern quan s'acaba la col·laboració.
Això no és externalitzar el nucli de la teva enginyeria. És afegir una squad dedicada a amortitzar deute durant un període acotat per accelerar feina a la qual el teu equip intern no arriba — sense fer créixer la plantilla permanent.
El deute que no hauries de pagar mai
Un apunt contraintuïtiu: hi ha deute que no s'hauria d'amortitzar mai. S'ha de deixar tal com està, documentar-lo i oblidar-lo.
- Deute en codi que estàs a punt de retirar. Si d'aquí a 6 mesos hauràs migrat fora d'un sistema legacy, no el refactoritzis. Dedica la capacitat a una altra banda.
- Deute en codi que es toca poc. Si un mòdul no ha canviat en 18 mesos i no provoca incidents, el deute és teòric. Ignora'l.
- Deute que és pragmatisme suficient. No cal que tot el codi sigui elegant. Si funciona, s'entén i no bloqueja res, ja està bé.
La disciplina consisteix a distingir el deute que et fa mal del deute que només és estèticament desagradable. El pair programming amb IA fa que el primer sigui més barat d'arreglar; ni la IA ni els enginyers haurien de perdre el temps amb el segon.
Tens al davant un programa d'amortització de deute que no pots cobrir amb l'equip intern? Parla amb un CTO sobre desplegar una squad nearshore dedicada, amb pair programming amb IA, per amortitzar deute en un calendari acotat i mesurable.
