Inżynieria odwrotna z wykorzystaniem AI – runda 2 (Odtwarzanie)

W pierwszej rundzie eksperymentu agent AI skrupulatnie przeanalizował szczegóły środowiska - co i jak działa, które komponenty i w jaki sposób są ze sobą połączone, gdzie jest przechowywany stan aplikacji. Celem pierwszej części eksperymentu było przygotowanie dokumentacji, pozwalajacej na odtworzenie środowiska uruchomieniowego.

Dzisiaj kontynuujemy ten eksperyment - przechodzimy do kolejnej rundy, w której podejmiemy próbę odtworzenia runtime, do czego wykorzystamy kolejnego agenta.

Schemat obu rund eksperymentu

[Runda 1] Istniejące środowisko → Agent 1 → Dokumentacja → [Runda 2] Agent 2 → Deployment

Dzisiejsza, kolejna część eksperymentu będzie testem przekazania projektu do realizacji. Agent 2 nie ma wglądu w środowisko pierwotne i nie korzysta z zasobów Internetu. Jego głównym zadaniem jest odtworzenie i uruchomienie nowej instancji Leantime i wyłącznie na podstawie dokumentacji, przygotowanej przez Agenta 1.

Dane wejściowe dla Agenta 2

Drugi agent AI przed przystąpieniem do zadania dostał raport z reverse engineeringu.

Nie otrzymał natomiast:

• oryginalnego docker-compose.yml,
• pliku .env,
• dumpa bazy danych,
• backupu woluminów,
• dostępu do pierwotnego środowiska.

Było to o tyle istotne, że agent nie mógł obrać drogi na skróty, tylko musiał opierać się na dokumentacji i w razie wątpliwości samodzielnie podejmować decyzje wykonawcze.

Efekty rundy 2

Według raportu z rekonstrukcji środowiska Leantime drugi agent odtworzył działający stack złożony z dwóch kontenerów:

• aplikacji leantime/leantime:latest
• bazy danych mysql:8.4.

Usługi zostały uruchomione w sieci wewnętrznej Dockera leantime-net, korzystały z pięciu trwałych woluminów i były dostępne z hosta pod adresem http://localhost:8080. Oba kontenery osiągnęły stan healthy.

Po stronie aplikacji agent doprowadził środowisko do używalnego stanu: baza dostała schemat, powstało konto administratora [email protected], a w systemie pojawił się domyślny projekt My Project.

Następnie agent przeszedł fazę testów - sprawdził logowanie, dashboard, listę projektów, zadania, Kanban, kalendarz, zarządzanie użytkownikami, połączenie między kontenerami i trwałość danych po restarcie. W jednym z testów utworzył zadanie, które przesunął na Kanbanie i potwierdził zmianę statusu w bazie. W innym teście zapisał plik na wolumine userfiles, zrestartował aplikację i potwierdził, że plik nadal istnieje.

Nie była to tylko instalacja kończąca się na docker compose up -d , ponieważ agent wykonał podstawową walidację operacyjną i funkcjonalną.

Ciekawostki

Ciekawe jest to, że Agent 2 nie tylko odtworzył środowisko, ale przy okazji zrecenzował dokumentację przygotowaną przez Agenta 1.

I tu robi się praktycznie. Dokumentacja była wystarczająca, aby dowieźć rekonstrukcję, jednak nie okazała się idealną instrukcją unattended deployment. Agent 2 wskazał konkretne luki:

• użycie tagu latest zamiast digestu obrazu,
• niejednoznaczność nazwy hosta bazy danych,
• brak punktów montowania dla woluminów,
• brak kompletnej procedury inicjalizacji aplikacji,
• zbyt ogólne scenariusze testowe.

Największy problem to wątpliwa deterministyczność. W trakcie rekonstrukcji latest wskazywał na Leantime 3.9.5 i konkretny digest obrazu. Za jakiś czas ten sam tag może wskazywać (i zapewne bedzie wskazywał) na inną, wyższą wersję aplikacji. Choć dokumentacja nadal będzie wyglądała poprawnie, to wynik instalacji może okazać się inny.

Podobnie z woluminami danych. Sama informacja, że środowisko ma pięć trwałych woluminów jest przydatna, ale dla dokładnego odtworzenia potrzebne są jeszcze konkretne punkty montowania. Bez nich agent musi sam robić inspekcję obrazu i dopasowywać bind mounty wedle uznania.

To samo dotyczy inicjalizacji runtime. Dokumentacja określała stan docelowy, ale nie uwzględniła pełnej procedury uzyskania tego stanu.

Wnioski

Dokumentacja z rundy 1 eksperymentu sprawdziła się w sensie praktycznym. Była wystarczająca, aby drugi agent zbudował nowe środowisko Leantime, uruchomił je i potwierdził kluczowe funkcjonalności.

Nie była to jednak gotowa specyfikacja do bezobsługowego wdrożenia - brakowało w niej kilku informacji, które w codziennej pracy szybko okazują się kluczowe: pinowania wersji, kompletu zmiennych, dokładnych mount pointów i procedury pierwszego startu.

Cennym wnioskiem jest także to, że AI potrafi działać nie tylko jako wykonawca, ale także jako analityk i projektant. Agent 1 opisał środowisko, a Agent 2 na tym opisie pracował i bez problemu wskazał na kluczowe luki w projekcie, tam gdzie opis okazał się za miękki.

W praktyce przypomina to przekazanie projektu między zespołami. To co zostaje niedopowiedziane, musi zostać dorozumiane.

Zakończenie

Runda 1 pokazała, że AI potrafi zrozumieć i opisać środowisko. Runda 2 pokazała coś ciekawszego: AI potrafi analizować dokumentację i wytykać jej słabe punkty, jak również wykonać niezbędne testy po zakończeniu deploymentu.