Inżynieria odwrotna z wykorzystaniem AI

W poprzednich dwóch wpisach zrobiłem mały krok, przechodząc gładko od teorii do praktyki.

Najpierw zadałem sobie pytanie, czy Bash to lingua franca DevOps - wyszło mi, że tak. W codziennej pracy operacyjnej Bash okazuje się wspólnym językiem, który łączy inżynierię, systemy i procesy.

Następnie przyszedł czas na konkrety: Leantime w 120 sekund. Jeden blok poleceń uruchamiający instalację, szybki wizard-setup i po krókiej chwili działająca aplikacja w przeglądarce.

Ten wpis jest kontynuacją tej samej historii. Uruchomienie aplikacji to jedno, lecz zrozumienie, co właściwie zostało uruchomione i w jaki sposób, to zupełnie inna sprawa.

Szybkie trudnego początki

Próg wejścia dla współczesnego DevOpsa nie jest wysoki, przynajmniej do chwili pierwszego uruchomienia.

Wystarczy znaleźć przykładowy docker-compose.yml, ustawić kilka zmiennych środowiskowych, wykonać docker compose up -d i poczekać, aż całość się uruchomi. Przy małych i lekkich aplikacjach efekt potrafi być niemal natychmiastowy.

To jest wygodne - po kilku minutach mamy działający system. Jest panel logowania, są kontenery w stanie healthy, woluminy i baza danych. Można poklikać po aplikacji, aby odłożyć projekt na bok uznając temat za zamknięty.

Z operacyjnego punktu widzenia to dopiero początek. Po pierwszym zachwycie pojawiają się pytania:

• jakie wersje komponentów zostały uruchomione,
• gdzie jest trzymany stan,
• które porty są wystawione na hosta,
• co się wydarzy po restarcie,
• jakie role użytkowników istnieją w aplikacji,
• jak wygląda backup i jego odtworzenie w razie awarii,
• które elementy są konfiguracją, a które efektem ubocznym pierwszego startu.

Na te pytania sam fakt działania aplikacji nam nie odpowie.

Dokumentacja czasami nie nadąża

W idealnym świecie wdrożenie i dokumentacja powstają razem, jedno jest odpowiednikiem drugiego.

Najpierw projektujemy środowisko, opisujemy architekturę, ustalamy kryteria odbioru, planujemy role użytkowników i scenariusze testowe. Dopiero później wdrażamy rozwiązanie i uruchamiamy system.

W realnym świecie niejednokrotnie wygląda to inaczej. Najpierw trzeba coś szybko sprawdzić. Potem się okazuje, że narzędzie jest fajne i nawet przydatne. Następnie dochodzą kolejne weryfikacje, małe poprawki, zmiany w konfiguracji, aktualizacje … można tak długo wymieniać.

Po kilku tygodniach system działa, a doświadczenie osób pracujących przy projekcie idzie stromo w górę. Byłoby miło, gdyby dokumentacja nadążała za praktyką.

Wiedza jest zakopana w różnych zakątkach systemu - część w docker-compose.yml, część w .env, część w historii terminala. Dużo szczegółów jest w głowie osoby, która to wszystko uruchamiała. Część nie istnieje już w formie trwałej, ponieważ wynika z aktualnego stanu środowiska.

I właśnie ten stan jest ciekawy.

Przyczyny eksperymentu z inżynierią odwrotną

Leantime z poprzedniego wpisu nie był środowiskiem produkcyjnym. To ważne zastrzeżenie.

Nie chodziło mi o audyt krytycznego systemu ani o odzyskiwanie wiedzy po wielomiesięcznym projekcie. Chodziło o prosty eksperyment: potraktować świeżo uruchomioną aplikację jak czarną skrzynkę i sprawdzić, ile uda się z niej odczytać.

Założenie było celowo praktyczne:

• Brak spisanego projektu lub choćby planu wdrożenia.

• Zwinne uruchomienie działającej aplikacji.

• Delegowanie zadania do agenta AI: sprawdź, co tu działa, jak jest połączone, gdzie jest stan, sprawdź użyte komponenty, jakie funkcje udostępnia aplikacja i co trzeba wiedzieć, żeby ten system sensownie odtworzyć.

To jest inżynieria odwrotna w bardzo przyziemnym wydaniu, bez napinki - raczej leniwe obserwowanie pracy agenta, przechodzącego przez kolejne etapy zadania.

Przebieg eksperymentu

Punktem startowym było działające środowisko Leantime uruchomione przez Docker Compose.

Agent AI nie analizował marketingowych opisów i manuali, tylko miał punktowo dotknąć realnego stanu systemu. Interesowały go ślady, które zostawia środowisko runtime:

• deklaracja Compose,
• efektywna konfiguracja po podstawieniu zmiennych,
• kontenery i obrazy,
• sieci Dockera,
• woluminy,
• logi,
• procesy wewnątrz kontenerów,
• schemat i zawartość bazy MySQL,
• endpointy HTTP,
• panel logowania i zachowanie aplikacji po uwierzytelnieniu.

Po dość szczegółowym discovery Agent wygenerował raport, nie będący instrukcją instalacji - to raczej próba odtworzenia opisu środowiska.

Sama definicja Compose mówi, jakie usługi powinny istnieć. Runtime pokazuje, co rzeczywiście działa. Woluminy mówią, gdzie znajduje się stan. Baza danych zdradza model informacji. UI i odpowiedzi HTTP pokazują, które funkcje są dostępne dla użytkownika. Logi dopowiadają, co aplikacja robi podczas startu i pracy.

Każde źródło mówi tylko część prawdy, dopiero zestawienie ich razem daje sensowny obraz całości.

Efekty eksperymentu

Agent zwrócił dość obszerny raport z inżynierii odwrotnej środowiska Leantime. Raport ten mógłby dostać drugi inżynier albo kolejny Agent AI, żeby zrozumieć jak działa aplikacja i jej środowisko.

Agent odczytał dwie różne warstwy - operacyjną i funkcjoanlną. Z jednej strony jest MySQL, nginx, PHP-FPM, woluminy i port 8080, a z drugiej projekty, zadania, role użytkowników, dashboard, uprawnienia i przypadku użycia.

Normalnie te dwa światy, zazwyczaj opisywane osobno, zostały przez AI połączone w jednym dokumencie.

Raport jako operacyjny artefakt

Raport porządkuje wiedzę o tym, co naprawdę działa w środowisku runtime. Agent nie miał dostępu do dokumentacji, nie przeszukiwał zasobów Internetu, tylko szukał faktów.

Raport może stać się także kontraktem rekonstrukcji. Jeśli ktoś ma odtworzyć środowisko, samo “uruchom Compose” może nie wystarczyć. Ten ktoś potrzebuje wiedzieć, jakie wersje użyto, jakie dane i role powinny zostać odtworzone, co sprawdzić po starcie i jakie testy przeprowadzić.

AI jako analityk, a nie tylko jako generator kodu

Najczęstsze użycie AI w IT nadal kręci się wokół generowania kodu. Nie wiem, czy to stereoptyp, czy faktycznie tak jest. Napisz funkcję, popraw błąd, stwórz komponent - to wszystko bywa użyteczne, ale nie wyczerpuje tematu.

W tym eksperymencie ciekawsze było coś innego - agent AI działał bardziej jak analityk techniczny i architekt, niż jak programista. Nie musiał implementować aplikacji od zera, ale miał zrozumieć działajacy system.

To wymaga innego trybu pracy. Trzeba zebrać fakty, porównać źródła, zauważyć sprzeczności, oddzielić stan runtime od deklaracji, pominąć sekrety, odróżnić dane demonstracyjne od biznesowych, zaproponować plan rekonstrukcji.

Choć brzmi to mniej efektownie niż “AI napisał aplikację”, to w praktyce jest bardzo wartościowe. W wielu firmach problemem nie jest brak kodu jako takiego, ale brak aktualnej wiedzy o tym, co już działa.

Systemy żyją dłużej niż ich pierwsza dokumentacja. Zmieniają się zależności, środowiska, integracje, czy też przyzwyczajenia użytkowników. Po czasie największym wyzwaniem możę być nie dopisanie kolejnej funkcjonalności, lecz ustalenie, co wolno bezpiecznie zmodyfikować.

Tu agenci AI mogą być naprawdę pomocni. Nie jako modny booster, bardziej jako skrupulatni analitycy, którzy przechodzą przez kolejne warstwy systemu i dokumentują jego architekturę.

Gdzie trzeba uważać

Taki proces ma też swoje ograniczenia. Agent AI może zebrać i uporządkować wiedzę, jednak raport z inżynierii odwrotnej jest tylko hipotezą opartą na dostępnych dowodach. Im więcej źródeł, tym lepiej, jednak mimo tego nadal warto weryfikować wyniki pracy AI.

Szczególnie ostrożnie trzeba traktować:

• sekrety, dane wrażliwe, prywatne pliki .env,
• dostęp do danych,
• domysły dotyczące intencji autorów systemu - kto wie, jakie smaczki kryją się w kodzie legacy?

Druga kwestia to skala zjawiska :) Małe środowisko Leantime dało się przeanalizować relatywnie szybko. Duży system z wieloma usługami, kolejkami, zewnętrznymi API i historią migracji będzie bez porównania trudniejszy. Wtedy trzeba rozłożyć pracę na etapy i pilnować limitów wykorzystania AI.

Przystępna wersja raportu

Pełny raport z eksperymentu udostępniam pod asresem: Raport z inżynierii odwrotnej środowiska Leantime

Szczególnie interesujące fragmenty to discovery środowiska, architektura logiczna, plan rekonstrukcji, projekt funkcjonalny i scenariusze testowe. To tam najlepiej widać różnicę między lakonicznym stwierdzeniem, że “aplikacja kontenerowa działa” a rozumieniem systemu na tyle, żeby go odtworzyć.

Podsumowanie

Wdrożenie Leantime w Dockerze było łatwe i szybkie. Wystarczył Bash, kilka poleceń i chwila cierpliwości.

Ten eksperyment pokazał mi, że inżynieria odwrotna istniejących środowisk może być jednym z bardziej praktycznych zastosowań agentów AI. Nie dlatego, że AI pisze kod, tylko dlatego, że potrafi wykonać żmudną pracę analityczną: zebrać i porównać ślady, ułożyć je w strukturę, zaproponować logiczny kontrakt rekonstrukcji.

To jest mniej spektakularne niż generowanie aplikacji od zera. Ale w codziennej pracy DevOps często właśnie tego brakuje: aktualnej, konkretnej i sprawdzalnej wiedzy o systemie, który już działa.