Když do takové aplikace AI agenti zasáhnou, buď se vše zbortí, nebo se každá další úprava prodraží. Jednoduchá rada je, že než začnete cokoli dělat, je důležité si vyčistit kód, vyzpovídat všechny, kteří se na vývoji podíleli, a následně to zdokumentovat. To je v praxi pro většinu firem nedosažitelný cíl. Naštěstí existuje i jiné řešení.

 

Je prakticky nemožné seznámit agenta se vším, co by o vývoji aplikace měl vědět. Pořád se něco mění a vždycky se najde kolega, který pošle zadání jen e-mailem, místo aby ho zapsal do správného nástroje. Otázka tedy nezní, jak ve vývojovém projektu udělat dokonalý pořádek, ale jak v tom, co k projektu reálně máte, naučit AI agenty se vyznat. Většina znalostí o tom, jak systém skutečně funguje a proč byl postavený zrovna takhle, často není nikde zdokumentovaná a existuje jen v hlavách kolegů. Dokumentace buď chybí, je neúplná, nebo zastaralá. Agent nemůže vědět, že dokumentace lže, pokud mu to někdo neřekne. Proto nejde primárně o to si uklidit v datech, ale najít způsob, jak agenta naučit se v této tiché poště orientovat a co dělat, když si neví rady.

 

Ve firmách se zároveň často objevují snahy připravit data tak, aby s nimi agenti mohli bez problémů pracovat. Jenže v momentě, kdy se agentický vývoj spustí v ostrém provozu, se data začnou měnit a zásadně přibývat. Agentický vývoj navíc často spustí lavinu nových požadavků a nápadů. Často se také objevují nečekané výjimky či dříve nezohledněné úkoly. Proto jde spíš o vytvoření systému, jak se v projektu a datech orientovat.

 

Zároveň platí, že čím více kontextu agentovi poskytnete, tím hůře se v něm většinou orientuje. Ve velkém množství dat se objeví nuance a protichůdné informace a agent pak neví, čemu věřit. Je to vlastně jiná podoba GIGO (garbage in, garbage out). Proto musíte agentovi kontext na jedné straně sice dát k dispozici, zároveň ho ale umět zjednodušit tak, aby věděl jen to, co potřebuje pro konkrétní úkol. Funguje to podobně, jako když zadáváte práci vývojáři – také mu neřeknete, ať si nastuduje celý firemní systém jen proto, aby v aplikaci změnil barvu tlačítka. Místo toho mu dáte přístup k projektu a návod, co kde najde, a také co dělat, když něco nenajde vůbec.

 

 

V praxi se nám osvědčil konkrétní postup: zmapovat zdroje informací o projektu a vytvořit jeden ucelený .md soubor. Ten by měl fungovat jako hlavní navigace, ze které člověk i AI agent snadno zjistí, kde co najít a jak postupovat, když si agent není jistý. My to řešíme tak, že pokud si agent není jistý, dokáže paralelně vést doplňující rozhovor v jiném chatu a posbírat dodatečné informace od kolegů. Vývojáři, produktoví manažeři nebo architekti mu poradí, agent následně rovnou upraví instrukce a doplní kontext do znalostní báze. Ta se tak díky zpětné vazbě neustále zlepšuje a udržuje aktuální, čímž se značně omezuje riziko, že si agent začne vymýšlet.

U vývoje softwaru v praxi agentům nestačí jen samotný kód z repozitářů a dokumentace. Osvědčilo se nám mít informace z Gitu, aby agent znal kontext už provedených změn, ale i vývojové roadmapy, aby chápal, co se plánuje do budoucna. Samozřejmě je vhodné mít přístup i k nástrojům pro monitoring a v neposlední řadě i k produkční databázi.

 

Způsob, jakým data připravit, závisí na jejich povaze. Pro hromadné záznamy dávají smysl strukturované datasety (tabulky) obohacené o metadata, která agentovi umožní efektivně filtrovat. U samostatných informací, jako jsou instrukce, jsou ideální jednoduché .md soubory. Oboje je velmi výhodné mít integrované s agenty v jednom systému, protože pak agenty dokážete lépe konfigurovat a dělají méně chyb než s nástroji třetích stran. Zejména proto jsme si k našemu agentnímu systému vyvinuli vlastní znalostní bázi a jednoduchý datový sklad s ETL.

Pokud je však pro práci kritická maximální aktuálnost, přímým integracím přes API či MCP servery s nástroji třetích stran, kde data vznikají, se nevyhnete. V takovém případě je ale nezbytné striktně izolovat kontext a zajistit, aby agent mohl provádět pouze povolené operace a neměl možnost neoprávněně zasahovat do systému.

My tento problém řešíme pomocí vlastní API gateway. Dokážeme tak agentovi zpřístupnit jen ty funkce, které pro svou práci skutečně potřebuje, a zbytek deterministicky zablokujeme. Dokážeme tak například bezpečně číst data z produkční databáze při analýze chyb a přitom neriskujeme, že agent produkční data změní, i když jde o standardizované API pro čtení i zápis. 

Co ve skutečnosti definuje neúspěšný vývoj v ostrém provozu? Často se vše svádí na technický dluh. Je pravda, že pokud musíte kvůli složité architektuře při jedné změně sáhnout na čtyřicet různých míst, implementace trvá dlouho a je riziková. Ale mnohem větší problém, na který agenti narážejí, není to, že je potřeba něco změnit na mnoha místech, ale to, že agent neví, že je to třeba.

Technický dluh je překážka, ale „kontextový dluh“, tedy neznalost všech vazeb v systému, je pro agenty fatální. Rychlost nasazení změny (time-to-production) tak nezávisí jen na čistotě kódu, ale především na tom, jak efektivně dokážeme agentovi předat mapu celého systému. Pokud agent ztrácí čas tápáním nebo opomene související části aplikace, protože o nich nemá povědomí, dělá chyby a každá iterace se prodražuje. Otázka tedy nezní jen jak s technickým dluhem pracovat, aby nás nebrzdil, ale jak minimalizovat čas, který agent stráví jeho analýzou, aby změna proběhla hladce.

 

Na co se tedy soustředit, abyste tento čas nasazení změny na produkci pomocí agentů  minimalizovali? Samotné psaní kódu je samozřejmá odpověď, ale dnes už z velké části vyřešený problém. Agenti dnes mohou nejvíce pomoci v procesech okolo samotné tvorby kódu, zejména před ní, protože právě tam vzniká zadání pro sofistikované programovací agenty. Jinými slovy, vytvoření kódu je jen malá část práce. Mnohem těžší je zjistit, co přesně se má naprogramovat.

 

Skutečný problém tedy leží v přípravě zadání pro kódovací agenty, konkrétně v komunikaci mezi byznysem a vývojem. Proto jsme v Iguaně AI transformaci začali tzv. technickým supportem – agentem, který byznysovým vlastníkům pomáhá pochopit a rozpracovat jejich požadavky na změny. Hned u toho jsme pozorovali zajímavý trend. Jakmile jsme byznys vlastníkům dovolili brainstormovat zadání rovnou s agentem, nemuseli na odpovědi čekat a díky tomu nám skokově vzrostl počet požadavků na změny, u některých klientů až na desetinásobek. Lidi najednou bavilo s agentem „psát“ a upřesňovat, co chtějí, ještě předtím, než se cokoliv začalo kódovat.

Následně jsme přidali agenta pro produktové manažery, aby zadání od klienta a technické podpory rozpracovali do podrobné technické specifikace. Až poté, co jsme měli tyto okolní procesy vyladěné, dali jsme se do automatizace samotného vývoje a kontroly kódu. Viděli jsme, že příprava je dostatečná na to, aby zhruba dvě třetiny změn byly odbaveny kompletně automaticky, a pouze schválené vývojovým týmem před nasazením do produkce.

 

S tím vším souvisí další výzva: jak si rozdělit práci mezi člověka a agenta, protože na úplnou automatizaci doporučuji zapomenout. Univerzální recept neexistuje, řídí se mírou kritičnosti. U bezpečnostně kritických změn by měl každý výstup agenta zkontrolovat člověk. U méně kritických si můžete dovolit kontrolovat více změn najednou nebo povrchově, třeba shrnutím, či paralelně v testovacím prostředí. Existují sice nástroje na kontrolu kvality a kódu, nicméně 100% na ně spoléhat také nedoporučuji.

 

Pokud bych to měl shrnout do jedné rady: nesnažte se mít dokonalá data. Naučte AI agenty v tom, co reálně máte, orientovat. A dívejte se na každého agenta stejně jako na nového kolegu. Ani toho byste první den nepustili do všech firemních systémů s tím, ať si to nastuduje sám a vše předělá k lepšímu. Dáte mu přístup k projektu, na kterém bude pracovat, předáte návod, jak se v něm orientovat, vymezíte mu pole působnosti a pečlivě ho kontrolujete, dokud si nezaslouží víc důvěry.