AI agenti ve starém kódu: jak modernizovat s kontrolou rizik
Představa je lákavá: vývojový tým předá AI starší aplikaci a dostane zpět přehlednější systém, který půjde snáze rozvíjet. U firemního softwaru však nestačí, aby nový kód vypadal dobře. Musí dál podporovat konkrétní práci lidí, navazující systémy i méně obvyklé situace.
Na tento problém upozorňuje Addy Osmani v článku Brownfield Agentic Engineering. Zdůrazňuje rozdělení práce podle rizika, zaznamenání znalostí mimo kód, ověření stávajícího chování, dokončení migrací a opatrné zavádění souběžné práce agentů. Následující postup převádí tyto principy do modelového zadání pro firemní aplikaci.
Starý systém potřebuje nejdřív konkrétní cíl
Legacy systém je existující aplikace, jejíž další rozvoj komplikují například starší technologie, provázané části, chybějící testy nebo neúplná dokumentace. Samotný věk nemusí být problém. Rozhodující je, zda tým dokáže změnu provést a ověřit s přijatelnými náklady.
Proto zadání „modernizujte náš systém pomocí AI“ nestačí. Lepší výchozí bod je konkrétní překážka: nový export trvá dlouho připravit, úprava jedné obrazovky zasahuje do několika modulů nebo aplikace závisí na knihovně, kterou už nelze rozumně aktualizovat.
U vývoje a rozvoje systémů na míru má smysl spojit technický zásah s měřitelným výsledkem. Například oddělit vytváření exportů tak, aby šlo přidat nový formát bez změn ve zpracování objednávek. AI pak dostává vymezený úkol, jehož výsledek lze posoudit.
Modelový příklad: export objednávek
Představme si interní aplikaci, která posílá objednávky do navazujícího systému. Její exportní modul míchá výběr dat, formátování souboru a aktualizaci stavu objednávky. Cílem je oddělit formátování do samostatné části. Jde o modelový příklad, nikoli o popis klientského projektu.
Nejdřív je potřeba určit, co změna smí ovlivnit. Nová implementace může mít jiné vnitřní uspořádání. Nesmí ale svévolně změnit pořadí sloupců, význam prázdných hodnot nebo okamžik, kdy se objednávka označí jako exportovaná.
Tím vzniká zadání, které lze zkontrolovat. „Čistší kód“ je obecné přání. „Stejný export a stejné změny stavů při odděleném formátování“ je ověřitelný výsledek.
Pravomoci agenta nastavujte podle dopadu změny
Rozdělení do zelené, žluté a červené zóny může sloužit jako praktická pomůcka pro rozhodování. Hranice určuje člověk, který zná systém a jeho provoz. Samotná existence testů nestačí k tomu, aby oblast automaticky získala nejnižší riziko.
| Zóna | Příklad v modelové aplikaci | Doporučený režim práce |
|---|---|---|
| Zelená | Oddělené formátování pomocného náhledu s ověřenými testy | Agent připraví malou změnu a projde stanovenými kontrolami. |
| Žlutá | Export s nejasnými historickými výjimkami | Tým nejdřív ověří chování a doplní testy, potom povolí vymezenou úpravu. |
| Červená | Oprávnění k exportu nebo výpočty ovlivňující fakturaci | Každý zásah vyžaduje přímou kontrolu odpovědného vývojáře. |
Uvažujte také o dosahu změny. Pomocná funkce může být dobře otestovaná, ale pokud ji používá export, fakturace i reporting, její úprava má širší důsledky než změna jedné obrazovky.
Praktické zadání agentovi proto obsahuje povolené soubory, rozhraní, která musí zachovat, a podmínky pro zastavení. Pokud například zjistí, že úkol vyžaduje změnu databázového schématu, předá zjištění týmu. Rozšíření rozsahu se pak posoudí samostatně.
Doplňte pravidla, která nelze vyčíst ze zdrojového kódu
U exportu může být neobvyklý formát data záměrný, protože ho očekává starší účetní program. Prázdná hodnota může znamenat něco jiného než nula. Určité objednávky se mohou zpracovávat až následující den kvůli domluvenému provoznímu postupu.
Takové informace doplňte k zadání spolu s tím, kdo je potvrdil. Užitečný záznam má například tuto podobu: „Prázdné datum dodání se v exportu zachovává. Navazující aplikace ho interpretuje jako termín dosud nepotvrzený. Potvrzeno vlastníkem procesu.“
Pokud důvod nikdo nezná, zaznamenejte otevřenou otázku. Domněnka se nesmí nenápadně změnit v obchodní pravidlo. Nejasnost lze ověřit s uživatelem systému nebo na vhodně připraveném vzorku dat.
Rozlišujte také mezi AI agentem, který pomáhá vývojářům měnit kód, a AI funkcí přímo v aplikaci. Jde o dvě různá rozhodnutí. Integrace AI do firemního systému může řešit například automatizaci práce s daty, ale modernizace exportního modulu sama o sobě takovou funkci nevyžaduje.
Než změníte implementaci, zachyťte dnešní chování
Characterization tests jsou testy, které zaznamenávají, jak se existující software chová pro vybrané vstupy. Pomáhají odhalit nechtěnou změnu při refaktoringu. Samy neprokazují, že původní chování je obchodně správné. Tento rozdíl vysvětluje i praktický průvodce characterization testy.
V modelovém exportu připraví tým sadu objednávek s běžným i hraničním průběhem: objednávku bez data dodání, s více položkami nebo s hodnotou obsahující oddělovač sloupců. Výstup původní verze uloží jako základ pro porovnání.
Kontrola se nemá omezit na vytvořený soubor. Důležité je také ověřit, co se změnilo v databázi a co se stalo při chybě. Pokud export selže, nesmí být objednávka omylem označená jako úspěšně předaná.
Očekávané výsledky musí vycházet z původní verze a potvrzených požadavků. Když agent nejdřív napíše novou implementaci a potom podle ní upraví očekávání testů, tým ztrácí nezávislé srovnání.
Pokud test odhalí původní chybu, oddělte její opravu od změny struktury. Tým nejdřív rozhodne, jaké chování požaduje, a teprve pak upraví test i implementaci. Zachování známé chyby nesmí být automatickým cílem modernizace.
Dokončená migrace má jasná provozní kritéria
Postupná migrace může dočasně používat starou a novou část současně. Takový postup popisuje například vzor Strangler Fig v dokumentaci Microsoftu. Podstatné je naplánovat přechod i ukončení původní části.
U našeho exportu může tým nejdřív porovnat výsledky obou implementací v testovacím prostředí. V produkci však musí být jasné, která varianta skutečně odesílá data. Dvojí odeslání stejné objednávky by mohlo vytvořit duplicitu v navazujícím systému.
Před nasazením proto stanovte kritéria dokončení: všechny dohodnuté typy objednávek používají nový export, starou funkci už nic nevolá, dokumentace odpovídá novému stavu a provozní kontrola nezjistila nevyřešené rozdíly.
Součástí plánu je postup obnovy. U změny kódu může stačit návrat k předchozí verzi. Pokud se mění data nebo už proběhlo odeslání do jiného systému, návrat aplikace nemusí vrátit jejich stav. Takovou situaci je potřeba řešit výslovně.
Proto modernizace navazuje na podporu a správu aplikace: potřebuje dohled po nasazení, dostupné záznamy o chybách a člověka, který rozhodne o dalším postupu.
Více agentů přidejte, až tým zvládá kontrolovat výsledky
Souběžná práce dává smysl u nezávislých úkolů. V modelové aplikaci může jeden agent připravovat úpravu exportu a jiný dokumentaci nesouvisejícího modulu. Pokud ale oba mění společné rozhraní, je nutná koordinace.
Začněte jedním vymezeným úkolem a zhodnoťte celý průběh. Kolik času zabralo zadání, ověření a opravy? Byl výsledek srozumitelný pro vývojáře, který ho nepřipravoval? Nezůstaly po změně nejasné výjimky?
Pro další práci používejte jednotný formát předání: účel změny, dotčené části, provedené kontroly, známé limity a postup nasazení. Kapacitu týmu neurčuje jen počet agentů, ale také schopnost výsledky posoudit a převzít.
Co si připravit před prvním úkolem
Pro první pilot vyberte malou část systému s konkrétním přínosem. Před zahájením by tým měl odpovědět na pět otázek:
- Jaký problém změna řeší a podle čeho poznáme přínos?
- Které chování musí zůstat zachované a kdo ho potvrdí?
- Co agent smí změnit a při jakém zjištění musí zastavit?
- Jak ověříme výsledek před nasazením i v provozu?
- Co znamená dokončení a jak budeme řešit neúspěšné nasazení?
Pokud odpovědi chybějí, prvním úkolem může být jejich zjištění. I to je užitečný výsledek: tým získá podklady pro rozhodnutí o rozsahu, ceně a způsobu modernizace.
Máte starší aplikaci a zvažujete, kde při jejím rozvoji využít AI? V 1. Web IT vám pomůžeme posoudit současný systém a navrhnout další postup. Napište nám, co vás při jeho rozvoji nejvíc brzdí.
