El 1985, Peter Naur va escriure que un programa mor quan es dissol l'equip que en té la teoria: la idea de per què el codi és com és. Amb agents de programació, un programa pot començar a morir sense que se'n vagi ningú.
Aquesta peça defensa una tesi incòmoda: el risc de programar amb agents no és només el codi que falla, sinó el codi que funciona i que ningú de l'equip sap explicar. L'especificació escrita abans del codi en paga una part, però no tot. L'altra part només es paga amb una regla: un canvi no entra fins que una persona de l'equip el sap explicar, no només aprovar.
Un deute que no avisa
Addy Osmani ho va descriure el març de 2026 com a deute de comprensió: la distància creixent entre quant codi hi ha al teu sistema i quant d'aquest codi entén de veritat alguna persona. Una frase seva ho resumeix: que el codi sigui barat de generar no fa barat saltar-se entendre'l.
La diferència amb el deute tècnic de sempre és que aquest no dona senyals. Cap prova no falla, cap mètrica de la revisió no es mou. Es descobreix tard, quan un error a producció obliga a depurar un mòdul que ningú no va escriure de veritat.
| Deute tècnic | Deute de comprensió | |
|---|---|---|
| Què és | Dreceres al codi que caldrà refer | Codi que ningú de l'equip sap explicar |
| Com es nota | Canvis que costen cada vegada més | No es nota: funciona i passa les proves |
| Quan apareix | De mica en mica, en el dia a dia | De cop, en depurar o canviar aquest codi |
| Què el fa créixer | Les presses i les dreceres | Generar més de pressa del que es llegeix |
Comparació elaborada per onext a partir de l'article d'Addy Osmani (2026)
Què diu un estudi amb grup de control
El gener de 2026, Judy Hanwen Shen i Alex Tamkin van publicar amb Anthropic un experiment amb 52 enginyers, sobretot júniors, que aprenien una biblioteca nova. Un grup va treballar amb ajuda d'IA; l'altre, a mà. Després, tots van fer una prova de comprensió.
Cal llegir-ho amb cura. Els mateixos autors avisen que la mostra és petita i que van mesurar la comprensió just després de la tasca; no saben si això prediu com aprèn algú a llarg termini. No és una dada de quant deute de comprensió hi ha als equips: ningú no l'ha mesurat. El que sí que suggereix és on es nota primer, en depurar, que és just quan el deute es cobra. Què significa això per a qui comença ho expliquem a desenvolupadors júnior amb IA: aprendre a revisar.
Quina part en paga l'especificació
Amb Spec-Driven Development (SDD, desenvolupament guiat per especificacions), el canvi es descriu per escrit abans que l'agent escrigui codi: què ha de fer, per què i com es comprova. Això en paga una part. Quan algú hagi de tocar aquest codi d'aquí a un any, sabrà què es pretenia, com expliquem a SDD: codi controlat.
No el paga sencer, i convé dir-ho. Osmani recorda que passar d'una especificació a codi implica moltíssimes decisions implícites que cap especificació no recull del tot: dos enginyers amb la mateixa especificació construeixen sistemes que es comporten diferent. Naur ho va veure fa més de quaranta anys: el codi i la seva documentació no són suficients per transmetre algunes de les idees de disseny més importants. Aquestes idees viuen en les persones.
L'especificació diu què havia de fer el canvi. Només una persona que l'ha entès pot dir per què el codi ho fa així i què es trenca si es toca.
L'altra part: explicar, no només aprovar
Aprovar una revisió i entendre un canvi no són el mateix. Amb agents, la revisió tendeix a comprovar que el canvi compleix el que s'ha demanat i que les proves passen, cosa necessària però no suficient. El que el procés de revisió detecta i el que no ho tractem a revisar codi generat per IA.
La regla que proposem és senzilla d'enunciar: un canvi no entra fins que una persona de l'equip el sap explicar amb les seves paraules, què fa i per què d'aquesta manera. Si ningú no ho sap, el canvi es divideix, es reescriu o s'acompanya del que falta. És la mateixa lògica d'on es signa en un cicle amb agents: una persona decideix on hi ha risc.
Risc Aquesta regla només funciona si dir «no entenc aquest codi» és normal a l'equip. Si admetre-ho es viu com un fracàs personal, la gent aprovarà el que no entén i el deute continuarà creixent en silenci.
Dues peces ajuden a fer que l'explicació tingui on recolzar-se. Les decisions que no es poden revertir sense cost, escrites amb el seu context, com expliquem a decisions d'arquitectura. I una xarxa de proves que detecti els errors abans que l'agent acceleri, a abans de l'agent, la xarxa. En codi heretat, el punt de partida és especificar primer la part que l'agent tocarà: especificar el codi legacy abans dels agents.
Tres preguntes per al teu equip aquesta setmana
- De l'últim canvi gran que va entrar amb ajuda d'un agent, qui el sabria explicar sense obrir el codi?
- Si demà falla a producció, qui el depura i quant trigaria a entendre què fa?
- Algú ha dit en una revisió d'aquest mes «no entenc aquest canvi»? Si ningú no ho ha dit, és perquè tot s'entén?
On encaixa onext
A AI-Accelerated Development construïm amb el teu equip el context en què treballa la IA i el procés amb què treballeu. Tots dos es queden a casa teva. Una persona decideix on hi ha risc. El primer pas és un diagnòstic gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start.
Preguntes freqüents
Què és el deute de comprensió?
Addy Osmani el defineix com la distància creixent entre quant codi hi ha al teu sistema i quant d'aquest codi entén de veritat alguna persona. És codi que funciona i passa les proves, però que ningú de l'equip sap explicar.
En què es diferencia del deute tècnic?
El deute tècnic acostuma a notar-se: canvis que costen cada vegada més o dependències embolicades. El deute de comprensió no avisa. Apareix el dia que cal canviar o depurar aquest codi i ningú no sap per què fa el que fa.
Per què creix més de pressa amb agents d'IA?
Perquè generar codi s'ha tornat barat i entendre'l no. Osmani ho resumeix així: que el codi sigui barat de generar no fa barat saltar-se entendre'l. Un agent produeix canvis més de pressa del que una persona els llegeix amb calma.
Hi ha dades que mostrin que la IA redueix la comprensió del codi?
Hi ha un estudi d'Anthropic amb 52 enginyers, sobretot júniors: el grup que va aprendre una biblioteca amb ajuda d'IA va treure un 50 % en una prova de comprensió, davant del 67 % del grup sense IA, i la diferència més gran va ser en depuració. Els autors avisen que la mostra és petita i que van mesurar just després de la tasca. No diu fins a quin punt el problema està estès en els equips.
L'especificació escrita abans del codi resol el problema?
En paga una part: deixa per escrit què havia de fer el canvi i per què. No el paga sencer. Osmani recorda que passar d'una especificació a codi implica moltíssimes decisions implícites que cap especificació no recull del tot, i Naur ja va escriure el 1985 que el codi i la seva documentació no són suficients per transmetre algunes de les idees de disseny més importants.
Quina regla convé afegir a la revisió?
Que un canvi no entri fins que una persona de l'equip el sàpiga explicar, no només aprovar. I que dir «no entenc aquest codi» sigui una cosa normal a l'equip, no una confessió.
Fonts
- Addy Osmani, «Comprehension debt», 14 de març de 2026; reeditat a O'Reilly Radar com a «Comprehension Debt: The Hidden Cost of AI-Generated Code», 13 d'abril de 2026.
- Peter Naur, «Programming as Theory Building», 1985 (còpia del text complet).
- Judy Hanwen Shen i Alex Tamkin, «How AI assistance impacts the formation of coding skills», Anthropic, 29 de gener de 2026 (article complet: arXiv 2601.20245).
- Les cites de fonts en anglès estan traduïdes per onext. La comparació entre deutes, la regla d'explicar abans d'aprovar i les tres preguntes són elaboració pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →