Rozhodl jsem se vyzkoušet, jak si AI agent dokáže poradit se starší aplikací, ke které jsou k dispozici jen zdrojové kódy.

Cílem bylo zkusit zpětně z kódu vytvořit analytickou dokumentaci, která u starších aplikací může často chybět nebo nemusí odpovídat skutečnému stavu.

Jako vzorek mi posloužila reálná přibližně 5 let stará PHP aplikace, na jejíž tvorbě jsem se podílel. Vzhledem k možnostem AI modelů mi bylo jasné, že je třeba k věci přistoupit postupně a nesnažit se do detailu zkoumat celou aplikaci naráz. Jako první část pokusu jsem zvolil databázové schéma aplikace.

Materiál

Databázové schéma aplikace je definované v kódu 145 PHP soubory s verzováním postupných úprav. Není to tedy žádný malý oříšek. Každý verzovací soubor obsahuje jeden SQL blok pro úpravy databáze - metoda up() - a druhý SQL blok pro případné vrácení provedených změn - metoda down() - pomocí frameworku Doctrine.

Zpracování těchto souborů jsem zkoušel přímo ve vývojovém prostředí PhpStorm a použil jsem vestavěného AI agenta Jetbrains Junie s výchozím modelem (nastavený na Gemini 3 Flash, Junie ale podle dokumentace interně používá na podúkoly modely podle svého uvážení).

Postup

1. Vytvoření promptu pro extrahování schématu z verzovacích PHP souborů
2. Spuštění promptu v AI agentovi a získání popisu schématu (Markdown)
3. Ověření přesnosti extrakce
4. • Transformace Markdown popisu na DDL pro vytvoření databáze
   • Vytvoření databáze ze získaného DDL
   • Vytvoření srovnávací databáze z původních 145 Doctrine souborů
   • Vyexportování DDL skriptů obou databází a jejich porovnání

Příprava promptu a spuštění

Prompt jsem připravoval za pomoci lehkého modelu GPT-4o-mini. Po dřívějších pokusech jsem model požádal o postup jak zpracovat adresář se 145 soubory bez toho, abych narazil na limit použití MCP toolů v rámci jedné LLM session (v AI chatu vývojového prostředí mimo agentský mód jsem narážel na limit po přečtení 15 souborů). 

Model navrhnul provést zpracování souborů po dávkách, to mi dávalo smysl a nechal jsem ho vygenerovat přesné a strukturované zadání pro AI agenta. Dostal jsem poměrně podrobný prompt o přibližně 60 řádcích, do kterého už jsem dál nezasahoval, s tím že uvidím jak si agent poradí.

Po spuštění agenta běžel celý proces asi 5 minut. Trochu mě překvapil postup “dávkování” - agent kreativně jedním shell příkazem slepil 15 PHP souborů do jednoho textového souboru, který teprve načetl a zpracoval. Pro zmíněných 145 verzovacích souborů toto udělal tím pádem desetkrát a jako mezikrok tedy model vytvořil soubory batch1.txt - batch10.txt. V promptu přitom nebylo nic co by ho k tomuhle konkrétnímu postupu navedlo. Ve zpětném pohledu to ale nehodnotím špatně, agent tím celkem efektivně delegoval část práce na shell a zásadně ušetřil počet operací čtení souboru.

Agent spotřeboval přibližně 1 Jetbrains AI kredit, tedy hodnotu cca 1$. Jetbrains AI je účtována podle tokenů a použitého modelu. Alternativou by mohlo být použít například agenta Github Copilot, který je účtovaný za požadavek na agenta a pro úlohy náročnější na délku zpracovaného textu a výstupu by mohl být levnější.

Výstup

Nakonec agent vytvořil Markdown soubor o 500 řádcích s informacemi o databázových tabulkách a jejich atributech, dokonce strukturovaně rozčleněný do tematických sekcí podle jím předpokládaných modulů. S dvěma view která byla v PHP skriptech definovaná se vypořádal jen stručně popisem toho, jaké tabulky zhruba spojují. Trochu mě to zarazilo, ale hlavní těžiště mého zájmu byly tabulky a jejich atributy, takže jsem se rozhodl brát při vyhodnocení v potaz jenom ty. Případné další informace o databázovém schématu by se daly získat dodatečnými nebo zpřesněnými prompty.

Abych si udělal lepší představu co vygenerovaný Markdown zhruba obsahuje, prohnal jsem jeho obsah vizualizačním nástrojem pro získání přehledového entity-relationship diagramu. Po krátkém zkoumání možností jsem k tomu použil eraser.io, který mě nechal vygenerovat diagram na zkoušku z textového popisu dokonce bez registrace. Podobných nástrojů se ale nabízí na trhu celá řada.

Nakonec jsem Markdown výstup prohnal ještě jedním kolem zpracování přes GPT-4o-mini, abych získal SQL skript pro vytvoření databáze. Bez toho by porovnání se skutečnou databází aplikace byla hodně obtížná a dlouhá manuální práce. U tohoto kroku nepředpokládám nějaké zaznamenatelné zkreslení informací, 500 řádků dobře strukturovaného Markdownu na taktéž dobře strukturované SQL by nemělo dělat ani nejmenšímu modelu žádné problémy. Zároveň to podle mě dobře simuluje reálné situace, kdy se obecný výstup často musí zpracovat do jiné podoby pro konkrétní použití.

Ověření

Abych mohl posoudit, jak kvalitní a spolehlivé jsou informace získané AI agentem, musel jsem zprovoznit vývojové prostředí původní PHP aplikace a spolu s ním lokální PostgreSQL databázi. V kódu bylo sice připravené Docker prostředí pro lokální vývoj, neměl jsem ale už k dispozici proprietární Docker image s nestandardním PHP rozšířením a specifickými nastaveními pro tuto aplikaci. Musel jsem tedy použít oficiální PHP Docker image a aplikaci lehce upravit do stavu, aby šla spustit alespoň inicializace databázových struktur. 

Už jen tenhle popis ukazuje na úskalí AI asistovaného reverse engineeringu - nakonec je stejně potřeba výstupy nějak zkontrolovat a to u starších aplikací nebývá jednoduché.

Naštěstí vývojové prostředí obsahovalo alespoň nástroj Adminer pro GUI správu databáze. Přes něj jsem jednoduše vytvořil na PostgreSQL vedle nainstalované aplikace druhé databázové schéma, které jsem inicializoval SQL skriptem od AI. Měl jsem tedy dvě databázová schémata na porovnání. Z Admineru jsem jednotlivá schémata vyexportoval jako SQL tabulek a jejich atributů. Tímhle způsobem jsem získal dva textové soubory se shodnou strukturou a stejným řazením tabulek, perfektní pro přímé porovnání diffem.

Výsledek

Jak to celé dopadlo?

AI agent správně identifikoval 55 databázových tabulek ze 75, které byly ve skutečné databázi. K dokonalosti to má tedy poměrně daleko. Jako pozitivum ale beru, že všechny názvy tabulek byly přesné, a žádnou tabulku si nevymyslel. Dostal jsem tedy 73% tabulek.

Při porovnání atributů jednotlivých tabulek bylo 100% přesně specifikováno 26 tabulek. Procentuálně vyjádřeno bylo tedy naprosto dokonalých 34% všech tabulek, 47% identifikovaných tabulek. 

Průměrná přesnost atributů v identifikovaných tabulkách byla obstojných 79%.

Závěr

AI modely a nástroje v současném stavu mohou poměrně jednoduše a rychle udělat slušnou porci práce pro získání základního přehledu o datovém modelu aplikace. Pro analytickou práci při reverse engineeringu starší aplikace může AI výstup sloužit jako základ, který je ale potřeba následně důkladně prověřit a také dopracovat.

Lepší kvalitě výstupů by nepochybně pomohl výkonnější model v AI agentovi s větším kontextovým oknem. To by na druhou stranu bylo vykoupeno o něco pomalejším zpracováním.

Další možnost optimalizace, která mě napadla, by bylo skutečné oddělení jednotlivých dávek souborů do samostatných agentských session. Po každé dávce 15 souborů by se vygeneroval “aktuální stav” databázového modelu do průběžného Markdown souboru, který by byl ručně předáván mezi jednotlivými dávkami spolu s informací o posledním zpracovaném souboru. Databázový model by se tak nemusel držet v paměti AI modelu po celou dobu zpracování všech souborů a zároveň by nedocházelo k průběžnému růstu kontextu. I zaplnění kontextového okna mohlo mít v tomto případě podstatný vliv na výsledek.