AI migruje COBOL, na którym stoją banki. Co to znaczy dla firm z legacy

Krótka odpowiedź

Ponad 40% systemów bankowości internetowej, 80% transakcji kartą kredytową przy kasie i 95% transakcji w bankomatach: według danych, które przytacza OpenAI, wszystko to obsługuje COBOL. To szacunki z 2017 r.: grafika Reuters „COBOL blues” podawała wtedy 43% systemów bankowych, 80% transakcji dokonywanych osobiście i 95% transakcji w bankomatach. Te same szacunki podaje dziś IBM w artykule „What is COBOL?”. Według IBM pierwsza wersja tego języka powstała w 1960 roku, a programistów COBOL-a jest dziś stosunkowo niewielu. 19 października 2026 r. OpenAI napisało, że jego najnowsze modele znacznie lepiej przepisują takie programy na współczesne języki.

Od razu zastrzeżenie: wyniki pochodzą z testowej ewaluacji OpenAI, a nie z migracji systemu w prawdziwym banku ani z wdrożenia u klienta. Według firmy GPT-6.1 Sol uzyskał w ewaluacji migracji 86,6% dokładności przy niskim nakładzie rozumowania (reasoning effort), a GPT-5.6 Sol w tym samym ustawieniu 5,4%. To deklaracja producenta, nie niezależny test, i sama firma pisze, że w produkcji potrzebny jest przegląd ekspertów i testy.

Modernizacja systemów legacy z AI nie zaczyna się więc od wyboru modelu. Zaczyna się od jednego modułu, testów, które zapisują jego obecne zachowanie, i osoby, która wie, dlaczego ten kod liczy tak, a nie inaczej. Dopiero na takim zestawie warto sprawdzić, czy model przepisze moduł bez zmiany wyników.

Poniżej: co dokładnie mierzy ta ewaluacja, czego nie dowodzi, jak zaplanować pilotaż migracji, jakie są ryzyka i lista kontrolna na start. Tekst opiera się na źródłach podlinkowanych na dole, według stanu na 21.10.2026. Niczego nie testowaliśmy na własnym kodzie COBOL; opisujemy wyniki tak, jak podaje je OpenAI.

Kod, którego nikt już nie rozumie

Znacie ten system. Działa od lat, liczy faktury, odsetki albo stany magazynowe, a każda zmiana wymaga telefonu do jednej osoby, która „jeszcze pamięta”. Dokumentacja jest niepełna, autorzy dawno odeszli, a część reguł biznesowych istnieje tylko w kodzie. To nie nasza diagnoza: dokładnie takie problemy wymienia OpenAI we wpisie, powołując się na opinie programistów i klientów firmowych.

Języki takie jak COBOL, Fortran czy Visual Basic OpenAI nazywa językami „low-resource”: jest w nich mniej publicznego kodu i dokumentacji, na których modele mogą się uczyć, niż w Pythonie czy JavaScripcie. Programiści i klienci firmowi mówili OpenAI, że modele kodujące często mają z nimi kłopot. Dla firmy oznacza to prostą rzecz: asystent, który świetnie pisze w TypeScripcie, nie musi tak samo dobrze rozumieć programu z lat 90.

Przy migracji nie chodzi o to, żeby nowy kod był ładniejszy. Chodzi o to, żeby robił dokładnie to samo co stary, łącznie z zachowaniami, o których nikt już nie pamięta. Wpis OpenAI podaje dobry przykład: arytmetyka stałoprzecinkowa w COBOL-u odrzuca nadmiarowe cyfry po przecinku, jeśli zaokrąglenie nie jest wprost zażądane. Przepisany program, który te wartości zaokrągla, uruchomi się bez błędów, a mimo to da inne wyniki finansowe.

Co ogłosiło OpenAI: migracja COBOL z AI w liczbach

Ewaluacja migracji COBOL polega na przeniesieniu istniejących programów do C++, Javy, Kotlina, Pythona albo Rusta z zachowaniem tego, co robią. OpenAI sprawdza wynik ukrytymi testami, które wymagają zgodności bajt po bajcie na obserwowalnych wyjściach. Migracja liczy się jako udana tylko wtedy, gdy przejdą wszystkie testy. Z tego opisu wynika, że „dokładność” oznacza tu udział migracji, które przeszły komplet testów, a nie ocenę czytelności czy stylu nowego kodu.

MultiLangBench mierzy co innego: czy model zbuduje od zera silnik bazy danych zgodny z SQLite w wybranym języku. Program dostaje bazę i zapytanie SQL, zwraca zmienioną bazę, a referencyjny SQLite sprawdza, czy zawartość się zgadza. Testy zaadaptowano z zestawu testów samego SQLite. Wynik to średni odsetek zaliczonych testów w dłuższej sesji programowania; OpenAI podaje też koszt API.

Wszystkie liczby poniżej to deklaracje OpenAI z wpisu z 19.10.2026. Przepisaliśmy je bez zmian i bez przeliczania.

Czego ten wpis nie dowodzi

Wyniki są duże i warto je potraktować poważnie. Warto też uczciwie powiedzieć, gdzie się kończą.

Po pierwsze, to ewaluacja producenta na własnym zestawie zadań. Wpis nie podaje, ile programów COBOL zawiera ewaluacja migracji, jak są duże ani skąd pochodzą. OpenAI pisze, że publikuje na GitHubie zestaw MultiLangBench, ale o publikacji zestawu do migracji COBOL wpis nie wspomina. Nie da się więc samodzielnie powtórzyć wyniku 86,6%.

Po drugie, benchmark to nie wasz kod. Programy w ewaluacji mają zdefiniowane wejścia i wyjścia oraz testy przygotowane przez autorów. Prawdziwy system ma zależności od baz danych, plików wsadowych, harmonogramów zadań, innych programów i ludzi, którzy wiedzą, że „w piątek po zamknięciu miesiąca” coś działa inaczej. Tego żadna ewaluacja nie widzi.

Po trzecie, „wszystkie testy przeszły” znaczy tylko tyle, ile znaczą testy. Jeśli zestaw nie sprawdza jakiegoś przypadku, migracja może go zmienić niezauważenie. Po czwarte, wysoki wynik w MultiLangBench mówi o budowie nowego programu według znanej specyfikacji (SQLite), a nie o zrozumieniu nieudokumentowanych reguł waszej firmy.

Samo OpenAI pisze to wprost: zachowywanie działania programu jest przydatne przy utrzymaniu i modernizacji starszych systemów, ale zastosowanie go do oprogramowania produkcyjnego nadal wymaga przeglądu przez ekspertów i testów względem reguł biznesowych i zależności systemu.

Testy zachowania ważniejsze niż wybór modelu

Najciekawsze w tym wpisie nie jest dla nas 97,9%, tylko sposób liczenia sukcesu: ukryte testy i zgodność bajt po bajcie. To jest przepis na pilotaż w firmie. Zanim model napisze pierwszą linijkę nowego kodu, potrzebujecie zestawu testów, który opisuje, co stary moduł robi dziś.

Takie testy nazywa się testami charakteryzacyjnymi (ang. characterization tests). Pojęcie wprowadził Michael Feathers w książce „Working Effectively with Legacy Code”, a w artykule z 2016 r. pisze, że ich celem jest udokumentowanie faktycznego zachowania systemu, a nie sprawdzanie zachowania, jakie chcielibyśmy mieć. Nie sprawdzają, czy kod działa „dobrze”. Zapisują, jak działa teraz: dla tych danych wejściowych wychodzi dokładnie ten plik, ten raport, ta kwota. Jeśli stary system zaokrągla w dziwny sposób, test to utrwala, a decyzja, czy to błąd, czy reguła biznesowa, należy do człowieka.

W praktyce materiał na takie testy zwykle już jest: archiwalne pliki wejściowe i wyjściowe z prawdziwych przebiegów, raporty z zamknięć miesiąca, przypadki brzegowe zgłaszane latami do działu IT. Uruchamiacie stary moduł na wybranym zestawie danych, zapisujecie wyniki i porównujecie je z wynikami nowej wersji. Każda różnica jest albo błędem migracji, albo odkryciem reguły, której nikt nie spisał. Oba wyniki są cenne.

Przy takim zestawie model staje się wymienny. Możecie porównać dwa narzędzia na tym samym module i ocenić je po liczbie zaliczonych testów, kosztach i czasie przeglądu, a nie po wrażeniu z prezentacji.

Rola eksperta od domeny i kodu

AI może przeczytać tysiące linii COBOL-u szybciej niż człowiek, ale nie wie, które zachowanie jest celowe. Potrzebujecie dwóch kompetencji, czasem w jednej osobie: kogoś, kto zna stary kod i środowisko (kompilator, zadania wsadowe, formaty plików), i kogoś z biznesu, kto powie, jak ma się zachować faktura z ujemną pozycją.

Ekspert nie musi pisać nowego kodu. Jego zadania w pilotażu to: wybrać moduł i dane do testów, rozstrzygać różnice wyników, przejrzeć zmiany przed wdrożeniem i zatwierdzić odbiór. Bez tej osoby testy powiedzą wam, że coś się różni, ale nie powiedzą, czy to problem.

Modernizacja systemów legacy z AI: pilotaż na jednym module

Martin Fowler opisuje podejście nazywane Strangler Fig: zamiast wymieniać cały system naraz, stopniowo przenosi się kolejne fragmenty działania do nowego kodu, a stary i nowy system przez jakiś czas działają obok siebie. Fowler pisze, że prosty plan „zbudujmy to samo w nowej technologii” w większości przypadków, które widział z kolegami, kończył się porażką. Pilotaż z AI dobrze pasuje do tego podejścia: jeden moduł, jasna granica, mierzalny wynik.

Dobry kandydat na pilotaż ma wyraźne wejście i wyjście (plik, rekord, raport), niewielką liczbę zależności i znaczenie dla biznesu, ale nie jest sercem rozliczeń. Moduł naliczania odsetek w głównym systemie transakcyjnym to zły pierwszy wybór, nawet jeśli to on najbardziej boli. Generator raportu albo walidacja plików wejściowych bywają lepszym startem.

Ustalcie z góry, co uznacie za sukces: na przykład 100% zgodności na uzgodnionym zestawie testów, czas przeglądu zmian przez eksperta i koszt API. Kryteria zapiszcie przed startem, żeby po fakcie nie dopasowywać ich do wyniku.

Odcinek 1: AI-owy chaos? Odpal Claude Code i zacznij gadać →Odcinek 2: Jak pisać prompty, żeby AI cię zrozumiało →

Ryzyka: dane, bezpieczeństwo, ukryte reguły, uzależnienie i koszt

Dane. Testy charakteryzacyjne najłatwiej budować na prawdziwych danych, a w starych systemach to często dane klientów, transakcje i pensje. Do pilotażu użyjcie danych zanonimizowanych albo syntetycznych tam, gdzie się da, i sprawdźcie, czy dostawca modelu może je przetwarzać w ramach waszej umowy.

Bezpieczeństwo. Agent programistyczny potrzebuje dostępu do kodu, a często też do kompilatora i środowiska testowego. Dajcie mu kopię repozytorium i odizolowane środowisko, nie dostęp do produkcji. Zasady opisaliśmy w checkliście uprawnień agenta AI.

Ukryte reguły biznesowe. To największe ryzyko i jednocześnie największa korzyść pilotażu. Reguła, której nikt nie spisał, wyjdzie przy porównaniu wyników albo nie wyjdzie wcale, jeśli zestaw testów jej nie obejmuje. Dlatego zestaw testów warto budować z ekspertem, a nie tylko z losowej próbki danych.

Uzależnienie od dostawcy (vendor lock-in). Wynik migracji to zwykły kod w Javie czy Pythonie, który zostaje u was. Uzależnić może za to proces: jeśli tylko jeden model rozumie wasz stary kod, każda zmiana cennika albo wycofanie modelu uderza w projekt. Testy zachowania i dokumentacja reguł, które powstaną w pilotażu, zostają niezależnie od narzędzia.

Koszt. OpenAI podaje koszty względne i szacunkowe koszty API na próbkę w swojej ewaluacji, a nie koszt migracji waszego systemu. Do kosztu pilotażu doliczcie czas eksperta, budowę testów, środowisko i przegląd zmian. Często to one, a nie tokeny, będą największą pozycją.

Checklista uprawnień agenta AI w firmie →Ile kosztuje wdrożenie AI w małej firmie →

Checklista pilotażu migracji z AI

Lista dotyczy pierwszego modułu. Jeśli większości punktów nie da się dziś odhaczyć, pilotaż warto zacząć od zbudowania testów, a model wybrać później.

Najczęstsze pytania

Czy AI potrafi już samo zmigrować system w COBOL-u? Nie ma na to dowodu. OpenAI podaje, że GPT-6.1 Sol uzyskał w ewaluacji OpenAI dotyczącej migracji 86,6% dokładności przy niskim nakładzie rozumowania i 97,9% przy wyższym, ale to własny zestaw zadań producenta. Firma sama zastrzega, że wdrożenie produkcyjne wymaga przeglądu ekspertów i testów względem reguł biznesowych i zależności systemu.

Co dokładnie mierzy ewaluacja migracji COBOL od OpenAI? Czy model przeniesie istniejący program w COBOL-u do C++, Javy, Kotlina, Pythona albo Rusta z zachowaniem działania. Wynik sprawdzają ukryte testy wymagające zgodności bajt po bajcie na obserwowalnych wyjściach, a migracja jest udana tylko wtedy, gdy przejdą wszystkie testy.

Od czego zacząć migrację COBOL z AI w firmie? Od jednego modułu z jasnym wejściem i wyjściem oraz od testów, które zapisują jego obecne zachowanie na archiwalnych danych. Dopiero potem warto dać modelowi zadanie migracji i porównać wyniki starej i nowej wersji.

Czym są testy charakteryzacyjne? To testy, które zapisują, jak system działa dziś, a nie jak powinien działać. Dla określonych danych wejściowych utrwalają dokładny wynik starego modułu. Przy migracji pozwalają wykryć każdą zmianę zachowania, także taką, której nikt wcześniej nie opisał.

Czy potrzebujemy programisty COBOL, jeśli używamy AI? Tak, przynajmniej do pilotażu. Ekspert wybiera moduł i dane do testów, rozstrzyga, czy różnica wyników to błąd, czy reguła biznesowa, i przegląda zmiany przed wdrożeniem. OpenAI również wymienia przegląd przez ekspertów jako warunek użycia w produkcji.

Jakie są największe ryzyka modernizacji z AI? Ukryte reguły biznesowe, których testy nie obejmują, dane klientów użyte do testów, zbyt szeroki dostęp agenta do systemów, uzależnienie procesu od jednego dostawcy oraz koszt czasu ekspertów, który zwykle przewyższa koszt samego API.

Co dalej

Jeśli dopiero zaczynacie pracę z agentami programistycznymi, seria „Jak zacząć z AI” pokazuje pierwsze kroki z Claude Code i pisanie poleceń. Jeśli chcecie zaplanować pilotaż migracji na własnym module, zobaczcie, jak pracujemy.

Usługi QKI Analytics →