Najlepszy ROI AI jest teraz naprawianie starego kodu, a nie pisanie nowego

Każdy demo produktu AI, na którym się znajduję, zaczyna się w ten sam sposób: pusty pola promptu, prośba w zwykłym języku angielskim i działająca aplikacja po kilku minutach. To naprawdę imponujący trick. To również, jak twierdzę, najmniej interesująca rzecz, która dzieje się w enterprise AI w tej chwili.

Bardziej konsekwentna praca odbywa się gdzieś znacznie mniej glamour: wewnątrz piętnastoletnich baz kodu, których nikt nie chce dotykać, napisanych przez inżynierów, którzy opuścili firmę dekadę temu, uruchamiających logikę biznesową, której nikt nie rozumie od lat. Większość pokrycia AI ma to do odwrotnie. Stary kod nie jest długiem technicznym. To jest zgromadzona inteligencja biznesowa: dekady decyzji, zakodowanych jako oprogramowanie, z ludźmi, którzy podjęli te decyzje, dawno temu.

Greenfield development dostaje sloty keynote. Stary kod dostaje pieniądze, niechętnie, i zwykle bez zrozumienia, jak je dobrze wydać.

Prawdziwy brak to nie deweloperzy, ale pamięć

To nie jest izolowany problem. Badanie z 2025 roku przeprowadzone przez firmę badawczą Savanta na ponad 500 decydentach IT na całym świecie szacuje, że średni globalny przedsiębiorstwo marnuje ponad $370 milionów dolarów rocznie poprzez niezdolność do wydajnego modernizowania systemów legacy, z których prawie $134 milionów jest związanych z wolnymi, zasobowo-intensywnymi projektami transformacji.

Niedawno pracowaliśmy z firmą dystrybucyjną baterii, która uruchamia ponad piętnaście aplikacji legacy, rodzaj rozproszenia, który gromadzi się przez dwadzieścia lat połączeń, integracji jednorazowych i inżynierów, którzy rozwiązują dzisiejszy problem bez wielkiego myślenia o jutrze.

To kuszące, aby nazwać to problemem talentu: zatrudnić więcej deweloperów, migrować szybciej. Ale nie możesz zatrudnić się z faktu, że osoba, która rozumiała, dlaczego moduł działał w taki sposób, opuściła firmę w 2014 roku. Większość przedsiębiorstw cierpi na brak pamięci, a nie na brak talentu. I dopóki niedawno, nie było realnego sposobu, aby to rozwiązać w skali. Albo płaciłeś garstce starszych inżynierów, aby trzymali wiedzę instytucjonalną w swoich głowach przez czas nieokreślony, albo ją straciłeś w dniu, gdy odeszli.

Co AI naprawdę zmienia

Nie wskazaliśmy narzędzia do generowania kodu na stary kod i nie powiedzieliśmy mu, aby przepisał wszystko; to mniej więcej tak, jak cichutko usuwasz logikę biznesową, której nie wiedziałeś, że istnieje. Zamiast tego użyliśmy agentów AI, aby wykonać nieglamurującą pracę najpierw: zmapować, jak piętnaście aplikacji jest naprawdę połączonych, wykryć decyzje zakodowane w logice, które nigdzie indziej nie zostały napisane, i trzymać tego kontekstu jako coś, co organizacja może zapytać, a nie coś, co żyje tylko w jednej głowie inżyniera. To odpowiada temu, co inni dostawcy AI dokumentują publicznie: wskazówki Anthropic dotyczące modernizacji systemów COBOL z Claude Code opisują tę samą sekwencję, automatyzując fazę eksploracji i analizy najpierw, zamiast skakania prosto do przepisywania.

Agenci nie byli oceniani na podstawie ilości wygenerowanego kodu. Byli oceniani na podstawie ilości wiedzy instytucjonalnej, którą mogli wykryć i zachować. Inżynierowie pracowali obok nich nad rzeczywistą migracją i generacją testów, sprawdzając interpretację agentów logiki biznesowej wobec tego, jak system zachowywał się w produkcji, a nie ufając mu na wiarę. Przydatny sygnał, na który zwróciliśmy uwagę: czy wyjaśnienie reguły przez agenta odpowiadało wzorcowi, który mogliśmy niezależnie zweryfikować w logach produkcji, czy było to prawdopodobne brzmiącą przypuszczeniem? Przerwa między tymi dwoma jest dokładnie tam, gdzie projekty modernizacji legacy zwykle idą nie tak.

Początkowa szacunkowa wartość projektu była osiem i pół miesiąca. Zamknęło się w czterech, co stanowi 53% redukcję. Ale trwalszy wynik nie był harmonogram. Wiedza instytucjonalna, która zwykle parowała, gdy inżynier opuszczał firmę, stała się czymś, co organizacja mogła naprawdę utrzymać.

Inżynierowie oprogramowania spędzili dekadę na pisaniu oprogramowania. Następna dekada może być spędzona na wykopywaniu go, z AI działającym mniej jako autor i bardziej jako archeolog, starannie odtwarzającym powody zakopanego w kodzie, który przetrwał ludzi, którzy go napisali.

szkicowy plan robienia tego bez łamania rzeczy

Projekty, które idą dobrze, wydają się podążać za tym samym sekwencją, niezależnie od tego, czy system jest silnikiem cenowym, czy rurociągiem roszczeń:

Odkryj: zmapuj, jak systemy są naprawdę połączone, a nie jak diagram architektury z 2016 roku mówi, że są połączone.

Zrozum: pozwól agentowi wykryć logikę biznesową i założenia za nią, w zwykłym języku, który ekspert domeny może sprawdzić.

Weryfikuj: sprawdź tę interpretację wobec rzeczywistego zachowania produkcji, a nie tylko wobec komentarzy samego kodu.

Przekształć: migracja lub odbudowa tylko wtedy, gdy pierwsze trzy etapy się utrzymują, z ludźmi posiadającymi podpis.

Przeskocz prosto do Przekształcenia, a nie modernizujesz. Grajesz z logiką, której jeszcze nie rozumiesz.

Dlaczego to ma znaczenie poza zespołami inżynierskimi

Pamięć instytucjonalna nie tylko cichutko znika, gdy starszy inżynier emerytuje. Staje się ostryą odpowiedzialnością w dokładnie tych momentach, gdy firma może sobie na to pozwolić najmniej: podczas przejęcia, gdy nowy właściciel musi zrozumieć, co tak naprawdę kupił; podczas migracji ERP, gdy stara logika musi być przetłumaczona na nowy system poprawnie po raz pierwszy; podczas audytu zgodności lub odpowiedzi na incydent, gdy ktoś musi wyjaśnić, dlaczego system zachowywał się w określony sposób, pod presją, regulatorowi, który nie zaakceptuje “osoba, która to zbudowała, odeszła w 2014 roku” jako odpowiedź.

Traktowane w ten sposób, modernizacja legacy przestaje być pozycją inżynierską i zaczyna wyglądać jak pytanie o wytrzymałość organizacyjną, co oznacza, że nie tylko CTO powinien się tym przejmować. To CIO, którzy ważą, co się stanie, gdy kluczowy personel techniczny się odwróci, zespoły M&A próbujące ocenić, co tak naprawdę kupują, i rady, które myślą o tym, ile wiedzy operacyjnej firmy istnieje tylko w kodzie, który nikt nie czyta.

ostrożność, która ma znaczenie

Żadne z tego nie działa bez nadzoru. Najbardziej ryzykowna wersja tego podejścia jest taka, w której interpretacja starej logiki biznesowej przez agenta jest ufana bez weryfikacji, ponieważ systemy legacy są dokładnie tym miejscem, w którym ufna, błędna założenie AI kosztuje najwięcej. Pełna autonomia na Twoim najnowszym mikrousługach jest rozsądnym zakładem. Pełna autonomia na silniku cenowym, który nikt nie dotykał od 2011 roku, nie jest. Wartość polega na tym, że AI sprawia, że jest możliwe, aby znów zostać inżynierami, którzy rozumieją biznes, w systemie, który nikt nie rozumie. Nie zastępuje ich.

Gdzie myślę, że to idzie dalej

Przez dwadzieścia lat przedsiębiorstwa traktowały oprogramowanie legacy jako coś, czego należy uniknąć: centrum kosztów, które należy finansować niechętnie i modernizować tak szybko, jak tylko budżet pozwala. Myślę, że AI ujawni, że wiele z tego kodu było naprawdę jednym z najcenniejszych repozytoriów wiedzy, jakie firma kiedykolwiek zbudowała. Po prostu potrzebowało czegoś, co mogłoby je odczytać. Badacze już dokumentują drugą stronę tego obiegu: przegląd literatury z 2026 roku na temat rozwoju wspomaganego przez LLM stwierdza, że dzisiejsze poszukiwanie AI-przyspieszonej szybkości samo w sobie tworzy “dług-integracyjny”, kod wysłany szybciej, niż można go zrozumieć. Modernizacja legacy jest po prostu tym rachunkiem, który w końcu się pojawia, generacja wcześniej.

Byłbym ciekawy, czy inni liderzy inżynierii i technologii widzą ten sam zwrot: czy zwrot z Twojej inwestycji AI pojawia się bardziej w tym, co budujesz, czy w tym, co w końcu możesz zrozumieć i zachować? I dla wszystkich, którzy próbowali uruchomić agenci AI przeciwko naprawdę staremu, nieudokumentowanemu systemowi, gdzie zrozumienie agenta się utrzymywało pod weryfikacją, a gdzie cichutko się rozpadło?