Nikt mi nie powiedział, że się nie da

Spłata długu technicznego jeszcze nigdy nie była tak tania jak dziś!

---

Zacznijmy od liczb. GitClear przeanalizował 623 miliony zmian w kodzie: refaktoryzacja, czyli modernizacja kodu bez zmiany jego efektu biznesowego, spadła z 21% zmienianych linii (2022) do 3,8% (2026). Zmiany w kodzie starszym niż rok — w dół o 74%. Duplikacja — rekord wszech czasów. Przestaliśmy naprawiać stary kod, a nigdy nie było to tańsze niż dziś.

W całej swojej karierze spędziłem w „korporacji” równo dwa lata. Przyszedłem jako programista — nawet nie senior — i niemal od progu wpuszczony zostałem w kod w Javie, wokół którego w całym zespole panowała pewna nieformalna zgoda. Trwała, oficjalnie nigdzie niezapisana, że się go nie dotyka.

Spring (taki framework do tworzenia aplikacji, popularny, gdy „ludzie rzucali kamieniami do dinozaurów”) był tam używany tak, jak Spring nigdy nie powinien być używany. Gdzieś w środku jakiś komponent ustawiał referencje na statycznym obiekcie — ręcznie robione wstrzykiwanie zależności do globalnego, mutowalnego stanu, wewnątrz frameworka, który istnieje po to, żeby tego właśnie nie robić, a zamykanie strumienia było wyjątkiem. Bajzel nad bajzlami.

Nikt niczego w tej sprawie specjalnie nie robił, może poza narzekaniem. Ludzie powielali zastany wzorzec — i szli dalej. Kod często eroduje, dlatego że kopiowanie raz porządnie spierniczonych rzeczy to nadal najszybsza droga do wdrożenia, a nikt w „korpo” nie ma w zakresie obowiązków bycia tym, który się zatrzyma i pomyśli.

Więc poprawiłem ten kod do stanu używalnego. Nie z odwagi. Z niewiedzy — nikt mi nie powiedział, że się nie da, a byłem zbyt „świeży”, po całkiem rozsądnym wdrożeniu w bardzo fajnych „startupach”, żeby wiedzieć, że oczekiwana reakcja to spojrzeć, wzruszyć ramionami i dołożyć kolejną warstwę spaghetti.

AI nie było. Było IDE, które przy odrobinie szczęścia podpowiadało prawidłową nazwę metody, i było bardzo dużo czytania — czytania ze zrozumieniem.

Rewolucja

Cała praca nad zmianami była głównie rozumieniem — i to nie moja przypadłość, tylko reguła. Xia i współautorzy zmierzyli to w IEEE TSE: programiści spędzają około 58% czasu na rozumieniu kodu i około 5% na jego edytowaniu.

A rozumienie jest dokładnie tym, w czym obecne „pokolenie” modeli LLM jest znakomite.

IBM w projekcie NOSI zmierzył 79-procentowy spadek czasu potrzebnego na zrozumienie aplikacji. CodeConcise od Thoughtworks skrócił inżynierię wsteczną (reverse engineering — po polsku brzmi dziwnie, przepraszam) 1500 modułów (~10 tysięcy linii każdy) z sześciu tygodni do zaledwie dwóch na moduł. AgentModernize wyciąga z kodu legacy 91,2% reguł biznesowych. Morgan Stanley użył DevGen.AI na dziewięciu milionach linii kodu i kazał mu produkować specyfikacje po angielsku, a nie kod.

Współtwórca Buna, dziś w Anthropic, użył Claude Code do przeniesienia rozwiązania z Ziga do Rusta — milion linii w niecałe dwa tygodnie, za mniej więcej 165 tysięcy dolarów w tokenach. Zalando zmigrowało bibliotekę komponentów z ponad 90-procentową trafnością za niecałe 40 dolarów na repozytorium. Allegro — najlepiej udokumentowany polski przypadek — zeszło z migracją modułu z Koina na Hilta z mniej więcej tygodnia do niecałych dwóch dni.

No i staniało coś jeszcze — dla mnie najważniejszego, bo kiedyś robiłem to ręcznie: całe zaplecze do sprawdzania, czy niczego nie zepsuliśmy. Testy utrwalające obecne zachowanie systemu (razem z bugami — tak, celowo), porównywanie wyników starej i nowej wersji na tych samych danych, dashboard z metrykami i ich historią. Kiedyś taki porządny zestaw to był miesiąc roboty. Dziś składa się go w godziny, albo i mniej — i to skrojony pod konkretny projekt i technologię. American Express nie pisał ręcznie testów do swojej migracji COBOL-a — wygenerował je sześcioma różnymi algorytmami naraz, a o tym, czy stare i nowe działały tak samo, decydowało zwykłe, deterministyczne porównanie wyników.

Jedno „ale”

Sedno problemu nie leży w samym rozumieniu. Leży w wiernej reimplementacji.

Ten sam AgentModernize, który wyciąga 91,2% reguł, przy odbudowie tego, co zrozumiał, osiąga zaledwie 9,4–19,4% zgodności zachowania. I to nie wybucha nagle i z hukiem — kod się ładnie kompiluje, tylko robi trochę co innego niż stara wersja. Mój ulubiony przykład z tej pracy: nowa wersja skompilowała się bez zarzutu, „po cichu gubiąc jednak wyjątek dla zawieszonych kont, który działał na produkcji od piętnastu lat”. Wszyscy wiemy, że takie „wyjątki” są raczej regułą w kodzie, który powstaje latami i który tworzą często różne zespoły i osoby.

„No ale od tego mamy testy” — otóż nie do końca. Eq@DFuzz pokazał, że mniej więcej jedna na pięć zepsutych w ten sposób refaktoryzacji przechodzi istniejące testy (podkreślmy: istniejące). Pokrycie mówi tylko, że linia się wykonała — nie mówi, czy zrobiła to co trzeba. Na szczerość modeli też nie ma co liczyć — w badaniu AWS Articulate but Wrong model zatwierdził 31,7% przypadków, w których sam coś zepsuł.

Trzeba przy tym pamiętać, że wszystkie te badania są „stare” — licząc czas po AI-owemu. Cobolowy pesymizm mierzono na GPT-4 i GPT-4o, a nowsze testy całych repozytoriów też robiono na modelach sprzed paru generacji. Od okolic GPT-4o minęły „wieki” rozwoju — mamy Fable 5 i GPT-5.6! Te wyniki to najgorsze, co mogło się przytrafić, bo robione na modelach z innej epoki.

I to jest całe „ale” — czyli lista rzeczy, które trzeba dobrze zaplanować i weryfikować.

7 kroków do bezpiecznej modernizacji kodu z AI

Zaznaczam, że to nie jest żadna metodyka — nie ma tu czego certyfikować. To elementy, które sprawdzają się na prawdziwych, realnych projektach. W gruncie rzeczy to ta sama robota, którą dwadzieścia lat temu odwalało się ręcznie, tyle że dziś większość z niej robią automaty i można to dowieźć w czasie o rzędy wielkości krótszym.

1. Zaczynamy od triażu, czyli od identyfikacji skali problemu: inwentaryzacja wszystkiego, co działa na produkcji, plus analiza bezpieczeństwa — jedno i drugie świetnie robią dziś narzędzia AI. Do tego decyzja przy każdym elemencie: tolerujemy, migrujemy albo kasujemy. Najtańsza spłata długu to skasowanie czegoś, czego nikt już nie używa (to też trzeba zmierzyć i wykazać).

2. Następnie agenci przekopują repozytorium i spisują specyfikację. Ludzie znający biznes czytają kilkadziesiąt stron, a nie czterdzieści tysięcy linii diffa. Nawet gdyby projekt skończył się w tym miejscu, coś zostaje: wiedza o systemie przestaje rezydować tylko w jednej głowie.

3. Na bazie specyfikacji budujemy oprzyrządowanie — właściwy produkt całego przedsięwzięcia. Testy utrwalające obecne zachowanie systemu (z bugami włącznie), testy specyficznych przypadków użycia systemu, uruchamiane potem na obu wersjach, porównywanie wyników na tych samych danych i dashboard metryk z historią. Część testów „trzymamy w ukryciu przed agentami”.

4. Zanim cokolwiek przeniesiemy, sprzątamy. Martwy kod wylatuje, konfiguracja idzie na zewnątrz, ukryte globale wychodzą na światło dzienne.

5. Dopiero teraz zmiany — najpierw automaty, potem AI. Co da się opisać regułą, robi reguła (codemody, receptury OpenRewrite), a model tylko dobiera i parametryzuje recepty. Slack to zmierzył: sam codemod 45%, sam LLM 40–60%, połączenie — 80%. Resztę dostają agenci: małe kawałki, jedna zmiana naraz, po każdej testy i porównanie zachowań. Airbnb tak przerobiło testy 3500 komponentów w 6 tygodni (oryginalnie zrobienie tego ręcznie szacowano na 1,5 roku).

6. Przed wdrożeniem osobny agent — najlepiej na innym modelu — dostaje jedno zadanie: udowodnić, że nowe działa inaczej niż stare.

7. I to wszystko zostaje na stałe. Narzędzia wspomagające przechodzą do regularnego CI, agenci robią cotygodniowe porządki (Spotify ma na liczniku 2,5 miliona takich PR-ów), review działa według ryzyka (w Zalando bot sam zatwierdza około jednej trzeciej PR-ów).

Czyli obie rzeczy naraz: naprawianie starego kodu nigdy nie było tańsze — i nigdy nie było rzadziej robione. Taki mały paradoks.

Przekonanie, że starych systemów nie da się modernizować, zawsze było błędne. Teraz również błędem jest myślenie, że to drogie.

— Konrad

---

PS. Nie ma tu detali promptów ani tego, którego modelu użyć — bo to dziś commodity, narzędzie jak kiedyś zwykły edytor.