Datoria tehnică nu a dispărut cu AI. S-a mutat în mentenanță.
- datorie tehnica
- AI
- mentenanta
- calitatea codului
În 2023 se scria cod mai încet decât azi. Asta e singurul lucru asupra căruia toată lumea e de acord.
Restul e mai complicat. Echipele livrează mai repede ca oricând, iar în același timp raportează mai multe incidente, mai multe reveniri și mai mult timp pierdut cu reparat ceva ce funcționa săptămâna trecută. Cele două nu se contrazic. Datoria tehnică nu a dispărut odată cu asistenții de cod — s-a mutat. Din faza de construcție, unde era vizibilă și bugetată, în faza de întreținere, unde nu e nici una, nici alta.
Merită să te uiți la cifre înainte de a decide dacă te privește.
Ce arată datele
GitClear a analizat 623 de milioane de modificări de cod între 2023 și 2026, urmărind opt semnale de calitate. Direcția e consecventă și neplăcută:
| Semnal | Evoluție |
|---|---|
| Refactorizare | 21% din liniile modificate în 2022 → 3,8% în 2026 |
| Duplicare de blocuri | +81% față de 2023 |
| Apeluri de funcții între fișiere | −35% (343 → 223 la mia de linii) |
| Construcții care maschează erori | +47% |
| Cod rescris în două săptămâni | +15% |
| Întreținerea codului vechi | −74% |
Trei dintre rânduri spun aceeași poveste din unghiuri diferite. Refactorizarea aproape a dispărut, duplicarea a crescut, iar apelurile între fișiere s-au rărit. Împreună, descriu un cod care încetează să mai fie o rețea de piese care se cheamă una pe alta și devine o grămadă de copii aproape identice. Fiecare copie funcționează. Fiecare copie trebuie reparată separat, când vine ziua.
Raportul DORA din 2025 adaugă cealaltă jumătate. 90% dintre respondenți folosesc AI la muncă și peste 80% cred că le-a crescut productivitatea. Adoptarea se corelează clar cu creșterea vitezei de livrare. Și tot ea se corelează, la fel de clar, cu scăderea stabilității: mai multe eșecuri la schimbare, mai mult rework, cicluri mai lungi până la rezolvarea unui incident. Trei din zece dezvoltatori spun că au încredere mică sau deloc în codul pe care îl primesc de la un model.
Partea care ar trebui să te neliniștească
Cel mai instructiv studiu nu e despre cod, e despre percepție. METR a rulat un experiment randomizat cu 16 dezvoltatori experimentați, pe 246 de sarcini reale, în proiecte pe care le cunoșteau de ani de zile. Fiecare sarcină a fost alocată aleatoriu: cu asistent de cod sau fără.
Cu asistent, au fost cu 19% mai lenți.
Înainte de experiment estimaseră că vor fi cu 24% mai rapizi. După ce l-au terminat, convinși că totul a mers bine, au estimat că fuseseră cu 20% mai rapizi. Măsurătoarea spunea invers.
Nu e o poveste despre unelte slabe. E o poveste despre faptul că senzația de progres și progresul real s-au desprins una de alta. Iar dacă asta se întâmplă în timpul unei sarcini de câteva ore, pe care o poți măsura, imaginează-ți cât de bine funcționează intuiția pe un orizont de trei ani, unde nimeni nu măsoară nimic.
Unde s-a mutat costul, mai exact
Datoria tehnică nu s-a inventat în 2023 și nu s-a evaporat. S-a mutat pe două axe.
În timp. Înainte, un cod prost scris te încetinea din prima lună: era greu de citit, review-ul dura, integrarea scârțâia. Acum trece de review — e curat, e comentat, respectă convențiile. Costul apare în luna opt, când cineva trebuie să schimbe o regulă de business care există în șapte locuri ușor diferite și găsește doar șase.
În factură. Faza de construcție are buget, are termen și are pe cineva care semnează la final. Faza de întreținere are un abonament lunar pe care nimeni nu-l analizează. Datoria s-a mutat din bugetul de proiect în cheltuiala recurentă, unde e mult mai greu de văzut și mult mai ușor de plătit la nesfârșit.
Rândul cel mai discret din tabel e și cel mai grav: construcțiile care maschează erori, plus 47%. Un try/catch care înghite excepția și continuă. O verificare care returnează o valoare implicită în loc să se oprească. Cod care face ca lucrurile să pară că merg. Într-o demonstrație nu se vede. În producție înseamnă că afli despre problemă de la client, nu din alerte — și că afli mult mai târziu decât ai fi putut.
De ce ne interesează pe noi mai mult decât pe alții
Aici trebuie să fim direcți despre propriul interes, pentru că e chiar argumentul.
Modelul nostru e ca proiectul să pornească ieftin și să rămână în întreținerea noastră lunar. Asta înseamnă că noi suntem cei care plătesc datoria pe care o livrăm. Un cod duplicat în șapte locuri nu e problema clientului peste un an — e problema noastră, în fiecare lună în care trebuie schimbat ceva. Un catch gol nu îi strică lui weekendul, ni-l strică nouă.
Un furnizor plătit pe oră și plecat după recepție are exact stimulentul opus. Nu spunem că profită de el conștient. Spunem că nimeni nu rezistă la nesfârșit unui stimulent care îl împinge într-o direcție.
Ce facem concret
Nu sunt intenții, sunt reguli pe care le poți verifica citind codul pe care ți-l livrăm.
Un singur loc pentru fiecare lucru. Configurarea se citește într-un singur fișier, care se plânge zgomotos dacă lipsește ceva, la pornire, nu la prima cerere. Interogările SQL stau într-un singur strat; restul aplicației nu scrie SQL. Când o regulă se schimbă, se schimbă într-un loc, iar noi nu trebuie să ne amintim de câte ori a fost copiată.
Comentariile explică de ce, nu ce. Un comentariu care repetă ce face linia de sub el e zgomot. Unul care explică de ce a fost aleasă varianta ciudată în locul celei evidente e singurul lucru care te salvează peste doi ani, când altcineva e pe cale să „curețe" exact acea ciudățenie. Fiecare decizie neevidentă din codul nostru are motivul scris lângă ea.
Nu mascăm erorile, alegem explicit ce se întâmplă la eșec. Există locuri unde o funcție trebuie să continue chiar dacă o dependență a picat — de exemplu, o cerere de ofertă se salvează în baza de date chiar dacă serviciul de email e căzut. Diferența față de un catch gol e că alegerea e deliberată, e comentată și lasă urmă în jurnal. Nimic nu eșuează în tăcere.
Refactorizarea intră în muncă, nu în „când o să avem timp". Nu există timp mai târziu. Un cod care nu e curățat pe măsură ce e scris nu se curăță niciodată, iar cifra de 3,8% de mai sus e demonstrația statistică a acestei propoziții.
Fiecare linie trebuie să poată fi explicată de un om. Folosim asistenți de cod. Ar fi absurd să nu o facem. Dar regula e simplă și fără excepții: dacă cineva din echipă nu poate explica de ce o bucată de cod arată așa, ea nu ajunge în proiect. Un model îți dă un răspuns care compilează; nu îți dă și responsabilitatea pentru el.
Verificăm în producție, nu în demonstrație. Backupurile se restaurează de probă, nu doar se fac. Monitorizarea trebuie să ne anunțe pe noi înaintea clientului. O procedură scrisă și neîncercată e o presupunere.
Codul e al tău de la prima zi. În repository-ul tău, cu documentație de operare. E cea mai bună garanție că regulile de mai sus sunt reale: oricine le poate verifica, oricând, inclusiv un alt furnizor la care ai vrea să te muți.
Ce nu susținem
Că AI-ul ar fi problema. Cifrele nu spun asta. Aceleași rapoarte arată creșteri reale de viteză, iar DORA e explicit: instabilitatea apare acolo unde volumul de schimbări crește fără sisteme de control pe măsură — testare automată, versionare disciplinată, feedback rapid. Uneltele nu au stricat nimic. Au scos la iveală ce lipsea deja.
Nu susținem nici că avem cifre proprii care demonstrează superioritatea noastră. Nu avem. Nimeni serios nu are, la scara asta, iar cine îți arată așa ceva îți vinde ceva.
Ce poți întreba pe oricine îți construiește software
Trei întrebări, la care răspunsurile se verifică ușor:
- Arată-mi un loc din cod unde ați ales varianta mai complicată. De ce? Dacă nu există niciunul, fie proiectul e trivial, fie nimeni nu s-a gândit.
- Ce se întâmplă când pică serviciul X? Un răspuns bun sună a decizie. Unul prost sună a „n-ar trebui să pice".
- Cine plătește dacă peste un an codul e greu de schimbat? Răspunsul la asta îți spune mai mult despre calitatea pe care o vei primi decât orice listă de tehnologii.
Datoria tehnică s-a mutat în viitor. Întrebarea utilă nu mai e cât costă să construiești, ci cine plătește când vine nota.
Surse
Cifrele din articol nu sunt ale noastre. Le poți verifica direct:
- GitClear — The Maintainability Gap: 2026 AI Code Quality Research — 623 de milioane de modificări de cod, 2023-2026. De aici vin toate cifrele din tabel.
- GitClear — AI Copilot Code Quality: 2025 Research — analiza anterioară, pe 211 milioane de linii, care a semnalat prima dată creșterea duplicării.
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — experimentul randomizat cu cei 19%. Lucrarea completă: arXiv:2507.09089.
- DORA — Balancing AI tensions: moving from AI adoption to effective SDLC use — relația dintre adoptarea AI, viteza de livrare și stabilitate.