Modernizare cod legacy cu agenți AI în 2026: Java și .NET

O parte consistentă din industria IT românească trăiește din întreținerea sistemelor pe care alții le-au scris: monoliți Java 8 cu Spring Boot 1.x, aplicații .NET Framework legate de Windows Server, baze de date cu proceduri stocate de zeci de mii de linii. Până în 2025, modernizarea lor era un proiect pe care clientul îl amâna anual. În 2026 se întâlnesc două lucruri: termenele de suport expiră în serie, iar agenții de cod au ajuns la nivelul la care fac o parte reală din muncă. Ghidul de mai jos arată ce pot face agenții pe un codebase vechi, ce unelte există, în ce ordine le folosești și ce nu le delegi niciodată.

Articolul e pentru dezvoltatori și lideri tehnici. Comparația între uneltele de programare asistată e în ghidul Claude Code, Cursor și GitHub Copilot, iar ce automatizezi în review și CI e tratat în articolul despre code review cu agenți. Aici e vorba despre un singur tip de proiect: să iei un sistem vechi, să-l aduci pe versiuni suportate și să-l lași mai bun decât l-ai găsit.

De ce 2026 e anul în care legacy-ul devine urgent

Termenele nu sunt speculații, sunt publicate de vendori:

• Java 8. Politica de ciclu de viață Red Hat pentru OpenJDK stabilește sfârșitul suportului pentru OpenJDK 8 la 30 noiembrie 2026. Oracle oferă suport extins plătit pentru Oracle JDK 8 până în decembrie 2030; alte distribuții au orizonturi proprii, verifică politica distribuitorului tău. Fără actualizări de securitate, o aplicație continuă să ruleze, dar fiecare vulnerabilitate nouă rămâne deschisă.
• .NET Framework. Conform politicii oficiale de suport, .NET Framework 4.8 e tratat ca o componentă a sistemului de operare Windows și e suportat cât timp e instalat pe o versiune de Windows suportată. Problema nu e framework-ul, ci serverul de sub el: Windows Server 2012 R2 își încheie ultimul an de actualizări de securitate extinse în octombrie 2026.
• Cerințele de securitate. Pentru firmele de software care livrează produse cu componente digitale, obligațiile de raportare a vulnerabilităților din Cyber Resilience Act se aplică din 11 septembrie 2026, detaliate în ghidul dedicat CRA. O dependință veche cu vulnerabilitate cunoscută devine un incident de raportat, nu doar un rând într-un backlog.

Clientul care a amânat cinci ani are, brusc, un motiv de audit, un motiv de securitate și un motiv de conformitate să nu mai amâne. Firma de servicii care știe să facă modernizarea repede, sigur și măsurabil are ceva de vândut.

Ce pot face agenții de cod pe un codebase vechi, realist

Un agent de cod din 2026 nu „rescrie aplicația". Face, bine, cinci lucruri și, prost, alte trei.

Ce face bine:

1. Cartografiere. Citește zeci de mii de linii, identifică modulele, dependențele, punctele de intrare și zonele fără teste, și produce un raport pe care un om l-ar scrie în săptămâni.
2. Teste de caracterizare. Scrie teste care fixează comportamentul actual, inclusiv cel bizar, ca să poți schimba codul fără să schimbi ce face. E conceptul lui Michael Feathers din Working Effectively with Legacy Code, iar agenții îl execută la scară; contextul mai larg al testării asistate de AI e în ghidul despre AI în testare și QA.
3. Transformări mecanice ghidate. Înlocuirea API-urilor eliminate, actualizarea dependințelor, adaptarea la schimbările de pachete și de configurare, propagarea unei schimbări de semnătură prin tot codul.
4. Explicarea codului fără autor. „Ce face această procedură stocată și de ce are 14 ramuri?" primește un răspuns pe care îl verifici, nu unul pe care îl inventezi.
5. Automatizare non-interactivă. Rularea aceleiași transformări pe 40 de repository-uri dintr-un pipeline, cu ieșire structurată, nu din editor, unul câte unul.

Ce face prost, dacă îl lași:

• Ghicește reguli de business. Când comportamentul nu e documentat, agentul „repară" ce i se pare bug, iar bug-ul era o cerință a clientului din 2014.
• Inventează API-uri. Metode care nu există în versiunea țintă, parametri plauzibili dar greșiți. Compilatorul le prinde; runtime-ul, nu întotdeauna.
• Scrie teste care trec pentru că nu testează nimic. Aserțiuni triviale, mock-uri care returnează exact ce așteaptă testul.

Diferența dintre un proiect de modernizare care merge și unul care produce un incident stă în modul în care organizezi agentul: memorie de proiect cu convențiile și regulile de business cunoscute, buclă de plan, editare și verificare pe mai multe fișiere, refactorizări transversale fără regresii și rularea în mod non-interactiv din CI. Exact această disciplină, de la fișierul de instrucțiuni al proiectului până la pipeline-uri agentice și guardrails deterministe prin hooks, e subiectul cursului Claude Code Mastery: Coding Agentic din Terminal.

Uneltele din 2026, pe categorii

Nu există o singură unealtă. Există patru categorii, și proiectele bune le combină.

Câteva detalii verificate la sursă:

• GitHub Copilot app modernization e disponibil general pentru Java și .NET din septembrie 2025: evaluează aplicația, aplică transformări, actualizează dependințele, repară build-ul și containerizează. Pentru Java, documentația Microsoft indică suport pentru Maven și Gradle și actualizări între versiunile 8, 11, 17, 21 și 25, cu accent pe Spring Boot; pentru .NET, migrarea de la .NET Framework la .NET modern.
• OpenRewrite e motorul open-source de transformare a codului întreținut de Moderne, construit pe un arbore semantic fără pierderi, cu rețete publice pentru migrări precum Spring Boot 2 la 3 și către Spring Boot 4. E determinist: aceeași rețetă produce aceeași schimbare, ceea ce îl face ideal pentru primul strat al oricărei modernizări.
• Amazon Q Developer nu mai acceptă înscrieri noi din 15 mai 2026, iar actualizările Java prin extensiile IDE nu vor mai fi accesibile după 30 aprilie 2027, utilizatorii fiind direcționați spre Kiro, IDE-ul agentic al AWS prezentat în ghidul despre Kiro și dezvoltarea pe specificații. Dacă ai planificat pe această unealtă, replanifică.
• Agenții generali, Claude Code din terminal și Cursor din IDE, nu sunt specializați pe migrări, dar sunt cei care leagă totul: rulează rețetele, citesc erorile de compilare, scriu testele lipsă, propagă schimbările prin cod și deschid pull request-ul. Refactorizarea masivă cu Composer și agenții de fundal care livrează prin pull request sunt tratate în cursul Cursor ca Pro.

Metoda în șase pași

Ordinea contează mai mult decât uneltele.

1. Inventar și evaluare

Lasă agentul să cartografieze: module, dependințe, versiuni, API-uri eliminate în versiunea țintă, zone fără teste, integrări externe. Rezultatul e un raport pe care îl verifici cu cineva care cunoaște sistemul. Decizi aici ce modernizezi (actualizare de versiune, migrare de framework, containerizare) și ce nu atingi, și scrii totul într-o specificație pe care o primește agentul, unitatea de lucru descrisă în articolul despre agentic engineering.

2. Teste de caracterizare înainte de orice schimbare

Pentru fiecare modul pe care îl vei atinge, agentul scrie teste care fixează comportamentul actual pe intrări reale, anonimizate. Regula: testele se scriu pe codul vechi și trebuie să treacă pe codul vechi. Un test care pică pe codul original nu e un bug găsit, e un test greșit, până când un om confirmă altceva.

3. Transformări deterministe întâi, agent după

Rulează rețetele OpenRewrite sau unealta vendorului pentru tot ce e acoperit mecanic. Abia apoi dai agentului ce a rămas: erorile de compilare rămase, API-urile fără rețetă, configurările specifice. Așa reduci suprafața în care agentul poate greși la ceea ce chiar cere judecată.

4. Arhitectura, incremental

Pentru ce depășește o actualizare de versiune, modelul strangler fig descris de Martin Fowler rămâne cel mai sigur: noul sistem crește în jurul celui vechi, preluând funcționalități una câte una, cu posibilitatea de a reveni. Agentul e bun la a extrage un modul și a-l reimplementa; omul decide granițele.

5. Review uman și porți în CI

Fiecare schimbare generată trece prin aceleași porți ca una scrisă de om: compilare, teste de caracterizare, analiză statică, scanare de dependințe, review de la cineva care înțelege domeniul. Botul comentează, omul aprobă. Rularea agentului în mod non-interactiv din pipeline îți permite să tratezi modernizarea ca pe un job repetabil, nu ca pe o sesiune eroică.

6. Măsurare

Ce raportezi clientului: versiuni înainte și după, vulnerabilități cunoscute închise, acoperire de teste înainte și după, timp de build, incidente în primele 30 de zile după livrare. Fără aceste cifre, modernizarea e o cheltuială; cu ele, e un rezultat.

Ce nu delegi agentului

Patru decizii rămân umane, indiferent cât de bun e modelul:

• Regulile de business nedocumentate. Când agentul propune să „simplifice" o ramură care pare inutilă, răspunsul e o întrebare către deținătorul procesului, nu un merge.
• Migrările de date. Schemele, conversiile și scripturile de migrare se scriu cu agentul, dar se rulează doar cu plan de revenire testat și cu un om care urmărește.
• Codul cu impact de securitate. Autentificare, autorizare, criptare, gestionarea secretelor: agentul poate propune, dar review-ul e obligatoriu și făcut de cineva calificat.
• Deciziile de licențiere. Schimbarea unei dependințe aduce o licență nouă. Agentul nu știe ce ai semnat cu clientul.

Partea contractuală și legală

Modernizarea cu agenți ridică trei întrebări pe care clientul le va pune, mai devreme sau mai târziu.

Cine deține codul generat? Dreptul de autor cere un autor uman, iar riscul practic nu e proprietatea, ci licența dependințelor și a fragmentelor reproduse. Analiza completă, cu termenii furnizorilor și șase controale aplicabile imediat, e în articolul despre proprietatea codului generat cu AI.

Unde ajunge codul clientului? Un agent de cod trimite fragmente din codebase către furnizorul modelului. Înainte de a porni proiectul, verifică în contractul cu furnizorul de AI regimul datelor (dacă sunt folosite la antrenare, cât sunt reținute, în ce regiune) și confruntă-l cu clauzele de confidențialitate din contractul cu clientul. Dacă acestea interzic transmiterea codului către terți, ai nevoie fie de acordul scris al clientului, fie de un plan enterprise cu garanții contractuale, fie de modele rulate local, opțiune tratată în ghidul despre LLM-uri locale.

Ce garantezi? Contractul de modernizare trebuie să spună explicit ce e inclus (versiuni țintă, acoperire de teste, vulnerabilități închise) și ce nu (rescrierea logicii de business, performanța pe date de producție nefurnizate). Un livrabil măsurabil, ca la pasul 6, protejează ambele părți.

Cum arată în practică, pe un proiect tipic de servicii

Scenariul e compus din tipare frecvente, nu dintr-un client anume: un monolit Java 8 pe Spring Boot 1.5, 180.000 de linii, 11% acoperire de teste, două integrări SOAP, un client care vrea Java 21 și containere pentru că auditul de securitate a semnalat dependințe vulnerabile.

Săptămâna 1: agentul cartografiază, echipa validează cu arhitectul clientului, se decide perimetrul (actualizare de versiune plus containerizare, fără schimbări funcționale). Săptămânile 2–3: teste de caracterizare pe modulele de facturare și de integrare, scrise de agent, verificate de echipă pe date anonimizate; acoperirea urcă acolo unde se va schimba cod, nu peste tot. Săptămâna 4: rețete OpenRewrite pentru Spring Boot 1.5 la 2.x și apoi la 3.x, actualizarea Java, dependințele; agentul rezolvă erorile rămase în bucla de compilare–testare. Săptămânile 5–6: containerizare, pipeline, scanare de dependințe, review complet, rulare în paralel cu sistemul vechi pe trafic reflectat. Livrare cu raport: versiuni, vulnerabilități închise, acoperire, timp de build, plan de monitorizare pentru 30 de zile.

Cifrele de efort diferă de la proiect la proiect și nu le estimăm aici; ce nu diferă e ordinea pașilor și faptul că agentul face partea repetitivă, iar oamenii fac deciziile și verificarea.

Întrebări frecvente

Poate un agent AI să migreze singur o aplicație de la Java 8 la Java 21?

Poate face cea mai mare parte a muncii mecanice: actualizarea dependințelor, înlocuirea API-urilor eliminate, repararea erorilor de compilare, scrierea testelor lipsă. Nu poate decide singur ce comportament e cerință și ce e bug, și nu poate garanta rezultatul fără teste de caracterizare și review uman. Proiectele reușite combină transformări deterministe, agent și oameni.

Este .NET Framework 4.8 la sfârșitul suportului?

Nu are o dată proprie de sfârșit de suport. Microsoft îl tratează ca o componentă a Windows și îl suportă cât timp rulează pe o versiune de Windows suportată. Urgența vine de la serverul de sub el și de la faptul că noile capabilități ale platformei .NET nu ajung în .NET Framework.

De ce să folosesc OpenRewrite dacă am deja un agent de cod?

Pentru că e determinist și auditabil: aceeași rețetă produce aceeași schimbare, pe toate repository-urile, fără variație. Agentul e cel mai valoros pe ce rămâne după rețete, adică pe cazurile care cer judecată. Folosite în această ordine, reduci suprafața de eroare a agentului.

Cum protejez codul clientului când folosesc un agent de cod?

Verifică regimul datelor în contractul cu furnizorul modelului (antrenare, retenție, regiune), confruntă-l cu clauzele de confidențialitate din contractul cu clientul și obține acordul scris unde e nevoie. Alternativa pentru cod foarte sensibil sunt modelele rulate local, cu compromisuri de capabilitate.

Ce raportez clientului la finalul modernizării?

Versiuni înainte și după, vulnerabilități cunoscute închise, acoperire de teste înainte și după pe modulele atinse, timp de build și incidente în primele 30 de zile. Sunt cifrele care transformă modernizarea dintr-o cheltuială într-un rezultat verificabil.

Concluzie

Modernizarea codului legacy a fost mereu munca pe care nimeni nu voia să o facă și pe care clientul nu voia să o plătească. În 2026, termenele de suport o fac obligatorie, iar agenții de cod o fac fezabilă la un cost pe care clientul îl acceptă. Rețeta nu e „dă-i agentului repository-ul": e inventar, teste de caracterizare, transformări deterministe, agent pe ce rămâne, review uman, măsurare. Pentru firmele de servicii din România, care întrețin o parte semnificativă din sistemele vechi ale Europei, e una dintre puținele oportunități în care un val tehnologic vine exact peste ce știu deja să facă.

Articol informativ, redactat la 10 septembrie 2026 pe baza documentației oficiale citate în text (Red Hat, Oracle, Microsoft, GitHub, AWS, OpenRewrite), consultate la această dată. Termenele de suport și capabilitățile uneltelor se schimbă; verifică sursele înainte de a planifica. Nu constituie consultanță juridică; pentru clauzele contractuale, consultă un avocat.