Rychlé pochopení historického projektu s využitím AI

Před několika týdny jsem přešel na nový projekt ke kolegovi, který podobné legacy aplikace v Javě udržoval. Jenže jak s absencí dokumentace co nejrychleji naskočit do rozjetého vlaku, aniž by byly první týdny ve stylu pokus–omyl?

Můj přechod naštěstí nastal v době největšího dosavadního rozmachu AI, a tak padlo jednoduché rozhodnutí – nechat aplikaci analyzovat copilotem, aby nám aplikaci popsal a vytvořil tak dokumentaci nejen pro nás, ale i pro sebe samotného.

Kde začít?

Na začátku jsem však netušil, odkud přesně začít. Začít sypat prompty do copilota, aby si s tím nějak poradil neznělo efektivně – pokud jazykovému modelu nespecifikujete, co přesně chcete, výsledky většinou nejsou příliš uspokojivé.

Poradil jsem se proto s jiným modelem, jaký je v tomto případě nejlepší přístup. Aby nebyl výsledek ovlivněn kontextem GitHub Copilota, zeptal jsem se na toto bezplatné verze MS Copilota ve webovém rozhraní. Výsledkem byl dokument v Markdownu se seznamem souborů, které budu potřebovat, a co by měly obsahovat.

Výhoda formátu Markdown je, že tento typ souboru zvládne číst stroj i člověk. O obsahu souboru tak máme nejen hrubou představu, ale můžeme si jednotlivé body sami přečíst a případně je korigovat.

Vygenerovaný soubor jsem tedy vzal, předhodil ho GitHub Copilotovi přímo v repozitáři a nechal ho kouzlit. Výsledek mě takříkajíc posadil na zadek.

Copilot například poznal, že v aplikaci se historicky vyskytovaly dva přístupy k vývoji – starý a nový – dokázal je rozlišit a popsat. Vygeneroval tak všechny potřebné soubory, např. agents.md, architecture.md a různé skilly. Dané soubory jsem pak dal MS Copilotovi k validaci, zda jsou soubory dobře napsané. Po potvrzení jsem měl dobrý odrazový můstek k ponoření se do hlubin projektu.

Vývoj s AI

Zkusil jsem se tedy rovnou pustit do prvních úkolů na projektu s využitím AI a vygenerovaných souborů. Zadání jsem opět dal jiné umělé inteligenci k přeformulování, než jsem na repozitář pustil AI agenta.

V tu chvíli nastalo další překvapení – zadaný úkol nejenže vykonal bez problémů, ale i vizuální kontrola se zdála v pořádku. Poslal jsem tedy vypracování na code review kolegovi a ten také neměl námitky.

Velkou měrou se na tom podílely právě mnou vygenerované podpůrné soubory v MD, ve kterých je popsán styl kódu, architektura apod. S nimi totiž copilot nepotřebuje hledat znovu a znovu tak velký kontext, jelikož v MD souborech má popsánu většinu věcí, co potřebuje.

Tím navíc šetří použité tokeny, kterých máme po nedávné změně cenové politiky všichni málo. Ověřil jsem si ale, že nejlepší způsob vývoje je kombinace člověka a AI – je nutné rozhodnout, na co se hodí použít copilota a na co nikoliv.

Budoucnost projektu

Z tohoto přístupu k novému projektu jsem si odnesl hned několik ponaučení. Určitě mi pomohlo poradit se s více LLM – toho zdarma jsem se ptal, jak co nejlépe úkolovat toho placeného, aniž bych musel pálit tokeny nepřesnými formulacemi.

V případě, že mě změna projektu potká někdy znovu, udělal bych to úplně stejně – nejdřív si nechal vygenerovat podpůrné soubory a nechat se poučit výstupy umělé inteligence, a až následně se díval do samotných zdrojových souborů projektu.

Samotné Markdown soubory je samozřejmě potřeba udržovat. Pokud se v aplikaci vyskytnou nějaké zásadní změny, které mění její strukturu nebo by mohly negativně ovlivnit chápání kódu copilotem (a jeho výkonnost), je potřeba tyto změny do nich propsat.

Nejjednodušší je i na toto použít umělou inteligenci, která dokáže změny vystihnout konkrétněji a stručněji. Dokonce jsem přímo do agents.md napsal, že pokud mu nějaká informace pomůže, ať si pomocné soubory upraví. Jelikož ale děláme primárně údržbu, za první měsíce na projektu nebylo nutné původní MD soubory upravovat, protože jsme žádné zásadní změny neprováděli.

Do budoucna se však pouze na údržbu omezovat nemusíme. Chybějící dokumentaci nám nahrazují právě vytvořené Markdown soubory. Bude-li to přání zákazníka, můžeme díky nim vyvíjet i nové funkcionality dané aplikace.