Druhé zásadní pravidlo při práci s AI agenty: rozdělení velkého požadavku na menší granularitu, s ověřením po každém kroku, dává lepší výsledky než jeden velký prompt.
Pokud se pokoušíte o novou feature a ta je hodně rozsáhlá, je lepší ji rozdělit na menší tasky, a to z několika důvodů.
Musím zmínit jednu z nejdůležitějších věcí — jak se chovají náklady na vývoj software v čase. Kniha Code Complete ukazuje graf, o kolik se prodraží oprava chyby podle toho, v jaké fázi vývoje na ni přijdete: v analýze jsou náklady téměř nulové, ale u zákazníka, až je software v produkci, jde o náklady o řád i více vyšší. S rychlostí, jakou dnes AI generuje kód, je potřeba o to opatrněji navrhovat architekturu předem — protože refaktoring je přesně to, co AI nezvládá nijak zvlášť dobře. Nejlepší je držet se standardů popsaných v knihách o čistém kódu a používat zavedené patterny pro strukturu i business logiku — knihy jsou pro AI model jeden z nejkvalitnějších zdrojů, ze kterých se při tréninku učil správné postupy, a proto jim i nejlépe rozumí. Pro AI je navíc důležité mít kód oddělený do jasných vrstev, i když jde o monolit — agent se pak v kódu orientuje mnohem snáz.
Vraťme se k tomu, jak správně postupovat a rozdělit tasky. Mějme úkol: vytvořit nový formulář pro spokojenost zákazníka. Jaké fáze budeme potřebovat?
- UI — formulář, jeho pole a události pro odeslání.
- Business logika — validace formuláře, přidání požadavku k zákaznickému účtu, priorita požadavku.
- Datová struktura — jak se data posílají na BE a zpět na FE.
- BE — opět validace a business logika, teď na straně backendu.
- Datová vrstva — převod z datové struktury do databázové.
- Uložení dat a odpovídající struktura, která jde zpět z BE na FE.
Pro AI je celkem jedno, odkud začínáte — důležité je jednotlivé kroky správně popsat. Pro vás jako uživatele je nejpraktičtější začít buď od databáze, nebo od frontendu.
Tím máme popsané všechny tasky. Otázka je, jaký je rozdíl mezi jedním velkým taskem a víc menšími.
Pokud máte jeden task, výhodou je sdílený kontext (cache) mezi kroky — agent nemusí nic znovu dohledávat. Jenže přes víc tahů (turnů) se tahle výhoda obrací: čím déle v jednom kontextu pokračujete, tím víc tokenů se v každém dalším tahu znovu posílá a přepočítává, takže cena za tah postupně roste s velikostí kontextu — u dlouhého, mnohatahového tasku to může být citelná částka.
Pokud naopak tasky rozdělíme, AI dělá vždy jen svou konkrétní část, kterou lze na konci samostatně otestovat — a tím chyby odhalíme dřív, než se začne pracovat na navazující části. Spotřebujeme méně tokenů celkem a díky možnosti ověřit každý krok samostatně odhalíme halucinace nebo odchylku od zadání mnohem dřív než po doběhnutí jednoho velkého tasku. Menší tasky navíc nevyžadují od modelu udržet pozornost na všech detailech najednou.
Proč na tom AI modelům tolik záleží? Mají omezenou schopnost držet si prioritu napříč velkým množstvím instrukcí najednou. Když do jednoho promptu napíšete "přidej novou funkci, refaktoruj starou logiku a oprav tři související bugy", model si poskládá vlastní pořadí priorit — a to se nemusí shodovat s vaším. Výsledek: část úkolu je hotová skvěle, část je odbytá, a nikdo to nepozná, dokud to nespadne v produkci.
Tohle je přesně důvod, proč AITM velké požadavky rozděluje na navazující tasky, místo aby je nechal doběhnout jako jeden souvislý běh.
Jak to vypadá v praxi: běžný AI chat vs. AITM
Běžný AI agent (chat/IDE copilot): zadáte jeden dlouhý prompt, agent se pustí do práce v jednom souvislém kontextu. Pokud se na 80 % cesty splete v detailu, nezjistíte to, dokud neprojdete celý diff — práce na dalších bodech mezitím pokračovala nad špatným základem.
AITM: stejný požadavek se v chatu/brainstormingu rozpadne na samostatné navazující tasky se závislostmi — task B se smí spustit až po tom, co task A doběhl celou pipeline a byl zmergován. Pokud task A selže v kroku Review nebo Test, task B se nerozjede nad rozbitým základem — čeká. Watchdog mezitím selhání tasku A sám vyhodnotí: pokud dokáže chybu analyzovat a navrhnout opravu, task automaticky restartuje s promptem, který popisuje přesně tu chybu a návrh řešení; pokud je chyba nejasná nebo neřešitelná bez rozhodnutí člověka, task se zastaví a čeká, až uživatel sám určí, jak má pokračovat. U posledního tasku v řetězu navíc po mergi proběhne krok Chain-audit — deterministická (ne AI) závěrečná kontrola, která znovu ověří kontrakty dotčené celým řetězem.
Rozdíl, který uživatel vidí: u běžného agenta dostane jeden velký, neprůhledný diff na konci. U AITM dostane víc menších, pojmenovaných, samostatně zkontrolovaných tasků s vlastní historií — a ví přesně, kde se co stalo, pokud něco nedopadne podle plánu.