Umělá inteligence umí dnes napsat funkci, komponentu nebo celý endpoint za pár vteřin. Problém nenastává tam, kde to lidé čekají — u syntaxe nebo rychlosti. Nastává v okamžiku, kdy má AI zasáhnout do existujícího systému: desítky souborů, historie rozhodnutí, business pravidla, která nikde nejsou zapsaná, jen "v hlavě" vývojářů. Jak se tomuto problému dá systémově předejít, je téma celého tohoto seriálu — a nástroj, ke kterému se postupně dostaneme, se jmenuje AITM.
Než se k němu dostaneme, stojí za to položit si otázku, na kterou si každý tým s AI agenty dřív nebo později odpoví sám — buď dobře, nebo draze: jak vlastně poznáte, že výsledek, který vám agent vrátil jako hotový, je skutečně v pořádku, a ne že to jen tak vypadá? K odpovědi se dostaneme na konci tohoto dílu — nejdřív si ale ukážeme, proč to vůbec není samozřejmá otázka.
Jak to vypadá v praxi
Typický scénář: zadáte AI agentovi úpravu jedné funkce. Agent ji opraví, ale zapomene, že tahle funkce je volaná ze tří jiných míst s jinými očekáváními. Nebo "vylepší" strukturu kódu, protože mu to přišlo logické, a rozbije tím navazující logiku, kterou vůbec neviděl.
Tohle nejsou ojedinělé bugy, ale systémový problém: AI agent nemá kontext celého systému, jen to, co se vejde do promptu a co se snaží přečíst pomocí fulltextového vyhledávání. Rozhoduje se podle slov, ne podle business logiky. Pokud má k dispozici dokumentaci, často načítá celý její obsah — i tu část, která s daným promptem vůbec nesouvisí. A platí to i u nejsilnějších dostupných modelů (Opus, Fable, Astra a podobné): nejde o to, že by model nebyl dost chytrý, ale o to, že nemá kam si tuhle znalost systematicky uložit mezi jednotlivými zásahy.
S rostoucím počtem řádků zdrojového kódu, složitější business logikou a vyšší provázaností jednotlivých modulů a tříd se tohle vyhledávání zhoršuje. Do AI se pak dostávají data, která s opravou nemají nic společného — a výsledkem je kód, který je technicky napsaný správně, ale řídí se špatnou business logikou. Výsledná funkcionalita je rozbitá, nebo se opraví i kousek kódu, který nikdo opravit nechtěl.
Kde přesně to vázne
Základním kamenem úrazu je halucinace — a ta se velmi těžko odbourává. Druhým problémem je kvalita promptu, kterou už jako uživatelé částečně ovlivnit umíme. Nad oběma se ale tyčí jedno tvrdší omezení: limitace kontextu. I u největších dostupných modelů jde o řádově milion tokenů, a to u prostředí, která mají statisíce řádků kódu.
Z vlastní zkušenosti vím, že pomyslná hranice, kde už základní věci jako skill nebo nápověda v md souboru nestačí, je zhruba kolem 150 000 řádků kódu. Kolem 300 000 řádků se prostředí stává opravdu komplexním — denní stav se rozpadá a situace se rozbíjí sama od sebe. Řeč je o softwaru postaveném na OOP, se složitými logickými podmínkami a propojením jednotlivých částí přes message/event mechanismy a podobné techniky. U takového kódu není vždy zřejmá reference mezi voláním a jeho zpracováním, a AI tuhle část zvládá se značnými obtížemi — s velkou pravděpodobností neodhalí všechen kód spojený s danou metodou.
K tomu se přidává další vrstva: samotný AI agent si na základě promptu často vytváří vlastní subagenty, a jejich vznik je sám o sobě pod kontrolou AI — takže sem vstupuje další zdroj chybovosti. Pokud AI v zadání přiřadí vyšší váhu slovu, které jste do věty napsali jen pro gramatickou návaznost (ne jako instrukci), může na jeho základě vytvořit subagenta, který zpracovává něco, co jste vůbec nechtěli. A subagent svou chybovost může posílat dál dalším agentům — tím se jednotlivé halucinace v řetězci šíří a sčítají.
Zdálo by se, že tohle vyřeší kontrolní agent, který má ověřit, zda bylo vše provedeno podle zadání. Jenže co znamená "ověřit"? Pokud úkol vyhodnotí jiná AI stejným způsobem, jakým byl zpracován, dostanete jen potvrzení téhož úsudku, ne nezávislou kontrolu. Teprve když na kontrolu použijete jinou a kvalitnější LLM, šance na odhalení chyby skutečně stoupne — ale to je volba, kterou musí někdo udělat vědomě, ne automatický výsledek toho, že "kontrola proběhla".
Zbývá ještě jedna cesta: spustit aplikaci nebo existující test, chybu vyčíst z logu a opravit ji tak, aby test prošel. I tady ale zůstává otázka, co se tím skutečně opravilo — je to opravdu bug, nebo jde o chybu vzniklou změnou business logiky, kterou předchozí krok nechtěně provedl? Oprava samotná bývá jasná a chyba zmizí, jenže často se tím rozbije jiná část kódu. Hodně záleží na tom, jak je kód složitý a jaké má návaznosti.
U jednodušších věcí — třeba webového formuláře s editací, validací po vyplnění a uložením dat přes business logiku — to obvykle není náročné a pravděpodobnost úspěchu se blíží 99 %. U složitějších struktur se naopak reálně dostanete do stavu, kdy se začne rozpadat struktura kódu a bug střídá bug. Opakovaným spouštěním testů a E2E testů se to dá postupně opravit, ale u opravdu komplexního systému to může trvat řadu pokusů — a každý z nich něco stojí.
Odpověď, kterou jsme slíbili na začátku
Zpátky k úvodní otázce: jak poznáte, že výsledek je skutečně v pořádku, a ne že jen vypadá hotově? Čistě z promptu a následné kontroly to spolehlivě nepoznáte. Viděli jsme proč: omezený kontext, halucinace šířené mezi subagenty, kontrola, která v nejhorším případě jen potvrzuje stejnou chybu, a oprava podle logu, která neumí rozlišit skutečný bug od vedlejšího efektu.
Tohle jsou metody, které dnes programátoři běžně používají, a u jednodušších úprav obstojí. Další úroveň je orchestrace pomocí AI — připravíte si určitá data o systému a udržujete je aktuální, abyste AI předkládali lepší informace a tím zmenšili prostor pro to, aby dělala jiné věci, než jste požadovali. Přesně pro tenhle účel vznikl AITM — AI Task Manager: dřív, než se k zadání vůbec dostane agent, který píše kód, systém si dotáhne kontrakty (zdokumentované chování), DOM mapu a business logiku k dané oblasti, a teprve s touhle znalostí sestaví task. Nepoužívá se přitom přímo jeden agent, ale celá pipeline a další metody, kterými AITM dosahuje lepších výsledků.
Následující dny ukážou přesně, jak to v AITM vypadá na konkrétních promptech, agentech a krocích pipeline — a proč je to jiný způsob práce s AI, než na jaký jsou programátoři zvyklí z běžné konzole.