COBOL migrat in Java cu AI — de ce scapa bug-urile si cum le prinzi in 2026

COBOL e limbajul ala de programare pe care toata lumea il crede mort de 20 de ani, dar care inca ruleaza in spatele cardului tau bancar, al asigurarii auto si al dosarului de pensii. Pe 28 iulie 2026, o echipa de cercetatori a publicat pe arXiv o lucrare care a aprins discutii aprinse pe Hacker News: „Agentic Method for Deterministic Validation of Legacy Code Migration”. Pe scurt — AI-ul poate traduce COBOL in Java, dar fara un mecanism de verificare care sa ruleze ambele variante in paralel, bug-urile trec neobservate si ajung direct in productie.

Daca lucrezi intr-o banca, o firma de asigurari sau o institutie publica din Romania, sau pur si simplu te intrebi cum se face migrarea codului vechi fara sa pui in pericol milioane de tranzactii — articolul asta e pentru tine.

Ce vei gasi in acest articol:

• De ce COBOL inca exista si de ce bancile romanesti nu pot renunta la el peste noapte
• De ce esueaza migrarile cu AI cand nu ai un oracol care verifica rezultatul
• Ce este Locksmith Loop — metoda agentic propusa de cercetatori, explicata simplu
• Rezultate concrete: 91,90% acoperire pe ramuri pe un program COBOL real de productie
• Ce inseamna pentru companiile si programatorii din Romania care se confrunta cu COBOL
• Cum aplici principiul validarii deterministe si la proiectele tale mici

Ce este COBOL si de ce mai exista in 2026

COBOL (Common Business-Oriented Language) a fost creat in 1959. Da, ai citit bine — are 67 de ani. Si totusi, conform estimarilor IBM, exista inca intre 200 si 300 de miliarde de linii de cod COBOL in productie la nivel global. Ruleaza pe mainframe-uri IBM si proceseaza:

• 95% din tranzactiile ATM la nivel global
• 80% din tranzactiile financiare din lume
• Guvernul SUA inca foloseste COBOL pentru securitate sociala, IRS si Medicare

In Romania, situatia e similara. Bancile mari (BCR, BRD, Banca Transilvania), companiile de asigurari si institutii publice precum ANAF sau Casa Nationala de Pensii ruleaza sisteme COBOL vechi de zeci de ani. Nu pentru ca asa vor, ci pentru ca:

1. Sunt sisteme critice — un crash inseamna ATM-uri blocate, plati esuate, dosare pierdute
2. Sunt masive — milioane de linii de cod, scrise si rescrise de echipe care nu mai lucreaza acolo
3. Functioneaza — paradoxal, COBOL e stabil. Problema nu e ca e vechi, ci ca nu mai are cine sa-l intretina
4. Mainframe-ul costa enorm — licente IBM zSeries, mentenanta hardware, specialisti care cer salarii de 10.000-15.000 euro/luna

De asta tentatia de a folosi AI-ul pentru migrare e urmatoarea. Si de asta e si periculoasa.

De ce esueaza migrarile COBOL → Java cu AI

Sa zicem ca iei un program COBOL de 4.000 de linii si il dai lui GPT-5.6 sau Claude Sonnet 5 sa-l traduca in Java. Ce obtii?

Cod Java care arata corect. Compileaza. Trec testele de baza. Da rezultate asemanatoare pe cazuri simple. Dar COBOL are particularitati pe care un LLM le pierde in traducere:

Problema fundamentala e simpla: nu ai cum sa stii daca traducerea e corecta doar uitandu-te la codul Java generat. Un LLM nu intelege semantica profunda a COBOL-ului. Pattern-match-uieste. Cand intalneste o constructie pe care n-a vazut-o des in datele de antrenament, improvizeaza. Iar „improvizatia” in sisteme financiare inseamna bani pierduti sau dosare gresite.

Studiul Microsoft despre productivitatea AI la programare arata ca AI-ul te face mai rapid, dar nu neaparat mai corect. La COBOL, viteza fara corectitudine e o bomba cu ceas.

Ce este Locksmith Loop — explicat pe intelesul tuturor

Cercetatorii din lucrarea arXiv:2607.28271 propun o metoda numita Locksmith Loop. Hai sa o explic fara jargon:

Imagineaza-ti ca ai doua masini identice — una veche (COBOL) si una noua (Java). Vrei sa te asiguri ca merg la fel. Ce faci? Le pui pe aceeasi ruta, cu aceeasi pasageri, si compari daca ajung in acelasi loc, in acelasi timp.

Asta face Locksmith Loop, dar cu programe:

Pasul 1 — Rulezi in paralel

Programul COBOL original si codul Java generat de AI ruleaza in paralel, pe acelasi calculator obisnuit (off-mainframe, nu pe mainframe IBM). Ambele sunt instrumentate cu mock-uri — simulatoare care inlocuiesc sistemele externe (CICS, VSAM, DB2) cu versiuni simple care returneaza aceleasi date de test.

Pasul 2 — Witness Search

Un agent AI cauta activ input-uri care duc programele in cat mai multe ramuri de cod (if/else, perform-uri, cicluri). Gandeste-l ca pe un vanator care incearca toate usile sa vada ce e in spatele lor. Cu cat gaseste mai multe combinatii de input care executa cod diferit, cu atat acoperirea e mai mare.

Pasul 3 — Locked Paragraphs

Cand agentul se blocheaza si nu poate patrunde intr-o anumita ramura de cod, un analizor identifica „Locked Paragraph” — conditia specifica care blocheaza explorarea. Poate fi un calcul care produce un anumit numar, un flag care trebuie setat intr-un anumit moment, sau o dependenta intre campuri de date. Analizorul sugereaza input-uri care pot debloca zona respectiva.

Pasul 4 — Verificare determinista de paritate

Dupa ce rulezi programele pe aceleasi input-uri, compari rezultatele. Daca COBOL returneaza 42 si Java returneaza 42, e paritate. Daca COBOL returneaza 42 si Java returneaza 42,0 — ai un bug. Nu un bug vizibil, nu un crash — un bug subtil care ar putea sa treaca neobservat luni de zile pana cand cineva isi da seama ca sumele nu se leaga.

Ideea principala e ca AI-ul nu poate evalua corectitudinea propriului cod fara un oracol extern. Oracolul, in cazul asta, e programul COBOL original care ruleaza in paralel. Daca cele doua nu dau aceleasi rezultate pe aceleasi date, codul Java are o problema. Simplu si determinist — nu depinde de „parerea” unui LLM.

Rezultatele studiului — cifre concrete

Cercetatorii au testat metoda pe trei programe COBOL:

Program	Tip	Linii de cod	Acoperire ramuri	Paritate
Program open-source 1	open-source	430	~100%	✅ 100%
Program open-source 2	open-source	~1.500	~100%	✅ 100%
Program intern de productie	inchis, real	4.114	91,90%	✅ 100% pe testele acceptate

Observatii importante:

• Acoperirea de 91,90% pe programul intern e impresionanta, dar inseamna ca ~8% din ramuri au ramas neexplorate. Acele 8% pot fi exact cazurile rare care produc erori financiare.
• Java generat a corespuns referintei COBOL la toate testele acceptate — cand metoda spune ca e corect, e corect. Fals pozitive zero.
• Fara Locksmith Loop, un LLM traduce codul si trece mai departe. Nu are cum sa stie daca a ratat o ramura sau o particularitate de aritmetica.

Pe Hacker News, discutia de pe 3 august 2026 s-a concentrat exact pe asta: nu ca AI-ul nu poate traduce (poate), ci ca nu poate valida singur rezultatul. Fara un oracol, e ca si cum ai da examen si ai corecta singur foaia.

Tabel comparativ: cum se face migrarea in functie de abordare

	Migrare manuala	Migrare AI fara validare	Migrare AI cu oracol determinist
Viteza	Luni — ani	Zile — saptamani	Saptamani — luni
Cost	Foarte mare (specialisti)	Mic (doar API AI)	Mediu (AI + infrastructura test)
Risc de bug-uri subtil	Mic (expertii cunosc COBOL)	Foarte mare (nimeni nu verifica)	Foarte mic (verificare automata)
Acoperire	Depinde de experti	Necunoscuta	Masurabila (91,90%+)
Nevoia de experti COBOL	Da, multi	Nu, dar nici nu verifica	Da, putini, pentru Locked Paragraphs
Potrivit pentru sisteme critice	Da (daca gasesti oameni)	Nu	Da

Concluzia: migrarea cu AI fara validare e cea mai rapida dar si cea mai periculoasa. Locksmith Loop combina viteza AI-ului cu siguranta verificarii deterministe.

Ce inseamna pentru programatorii si companiile din Romania

In Romania, COBOL e un subiect tabu. Bancile nu vorbesc public despre tehnologiile lor vechi, iar institutiile publice abia daca recunosc ca au sisteme IT din anii ‘90. Dar realitatea e ca:

• Banca Transilvania, BCR, BRD, ING Romania — toate au sisteme de procesare tranzactii care ruleaza pe COBOL sau pe platforme derivate
• ANAF inca foloseste aplicatii vechi pentru procesarea declaratiilor fiscale
• Casa de Pensii, Casa de Sanatate — dosarele tale trec prin cod care are zeci de ani
• Sistemele de plati interbancare (SWIFT, SEPA, TRANSFOND) depind de cod COBOL la nivel global

Daca esti programator in Romania si lucrezi intr-una din aceste institutii, stii deja cat de greu e sa gasesti colegi care stiu COBOL. Salariile pentru specialisti COBOL au ajuns la 10.000-15.000 euro/luna in Europa de Vest. In Romania, un senior COBOL poate cere 15.000-25.000 lei/luna si primeste.

Scandalul Anthropic-Bun-Zig a aratat deja ca hype-ul „AI-ul inlocuieste programatorii” e periculos. La COBOL, consecintele sunt si mai grave — nu e un framework web pe care il refaci intr-un weekend, ci cod care misca bani reali.

Tentatia companiilor romanesti de a folosi AI pentru migrare e mare. Si partial justificata — e mai ieftin si mai rapid decat sa angajezi 10 specialisti COBOL pe salarii de Vest. Dar lucrarea arXiv:2607.28271 arata clar ca AI fara oracol de validare = risc necunoscut.

Daca esti decizie-maker intr-o companie care ia in considerare migrarea COBOL → Java cu AI, intreaba:

1. Cine verifica rezultatul? — Daca raspunsul e „ne uitam pe cod”, e insuficient.
2. Avem un oracol determinist? — Adica ruleaza ambele versiuni pe aceleasi date si compara rezultatele?
3. Ce se intampla cu Locked Paragraph-urile? — Ramai cu zone neexplorate si speri ca-s OK?
4. Ce pierd daca un bug subtil ajunge in productie? — Un ATM care da cu 10 lei mai putin? Un dosar de pensie calculat gresit?

Cum aplici principiul validarii deterministe si la proiectele tale mici

Nu trebuie sa lucrezi la o banca ca sa ai nevoie de validare determinista. Principiul Locksmith Loop se aplica la orice migrare de cod:

Daca folosesti modele AI locale pentru programare, gandeste-te de doua ori inainte sa lasi AI-ul sa rescrie un intreg modul fara sa verifici rezultatul. Un diff vizual nu e suficient — ai nevoie de teste care compara comportamentul, nu doar structura codului.

Si nu uita: Stack Overflow a fost ucis de AI tocmai pentru ca programatorii au inceput sa ceara raspunsuri rapide de la AI in loc de a intelege codul. La migrari, asta e exact reteta pentru dezastru.

Ce se intampla daca un bug COBOL trece in Java?

Cel mai comun scenariu: un calcul de dobanda sau un impozit iese diferit cu 0,01 lei. Pe un cont, e irelevant. Pe un milion de conturi, inseamna 10.000 de lei lipsa in fiecare zi. Daca nu ai un mecanism automat care compara rezultatele, nu afli decat cand clientii incep sa sune.

Locksmith Loop merge doar pentru COBOL?

Nu. Metoda e generica. Oricand migrati cod de la o platforma la alta — RPG, Fortran, Visual Basic vechi, chiar si C legacy — principiul e acelasi: ruleaza ambele versiuni, compara rezultatele, cauta ramuri neexplorate.

De ce nu poti lasa doar AI-ul sa verifice AI-ul?

Pentru ca un LLM nu are capacitatea de a face verificare determinista. Poate spune ca codul „arata bine” sau ca „pare echivalent”, dar nu poate garanta ca 0,1 in COBOL packed decimal e exact acelasi 0,1 in Java double. Validarea determinista inseamna executie reala, pe date reale, cu comparatie bit-cu-bit.

Cat costa sa implementezi Locksmith Loop?

Cel mai mare cost e instrumentarea — adica transformarea programului COBOL sa ruleze off-mainframe cu mock-uri pentru CICS/VSAM/DB2. Odata facut asta, ciclul automat de Witness Search ruleaza pe hardware normal. Pentru un program de 4.000 de linii, estimarea e cateva saptamani de munca pentru un inginer care stie si COBOL si Java. Mult mai putin decat migrarea manuala.

---

Migrarea COBOL → Java cu AI e inevitabila. Nimeni nu mai vrea sa plateasca mainframe-uri IBM si specialisti COBOL pe salarii de Vest. Dar lucrarea arXiv:2607.28271 ne arata ca viteza fara verificare e o iluzie. AI-ul traduce cod, dar nu-l valideaza. Validarea trebuie sa vina dintr-un mecanism extern — oracolul determinist care ruleaza ambele versiuni si compara rezultatele.

Daca lucrezi intr-o banca, o firma de asigurari sau o institutie publica din Romania, sau daca pur si simplu refactoring la cod vechi — nu sari peste verificare. E mai ieftin sa verifici acum decat sa repari in productie.