Na prototyp mi stačí pár hodin a dobře napsané zadání. U aplikace, která má desítky obrazovek, napojení na externí data a běží každý den, to nestačí. AI agent začíná každou novou úlohu bez paměti. Neví, proč je datový model postavený tak, jak je, co jsme minulý týden zkoušeli a zahodili, ani co se nesmí změnit. Proto pracuji podle postupu, kterému říkám Full Agentic Spec-Driven Development.
Co tím myslím
Je to definovaný proces pro celý projekt, ne jen pro psaní kódu. Vedle kódu vznikají v repozitáři dokumenty, které popisují, co a proč stavíme: architektonická rozhodnutí, plán implementace jednotlivých funkcí, jejich dopady, rizika a návrh testů. Agent je při další práci čte jako první a teprve potom sahá do kódu.
Specifikace tu neslouží jako byrokracie pro lidi. Je to kontext pro agenta, který by jinak viděl jen soubory a zadání v chatu.
Co je v repozitáři vedle kódu
- Popis projektu a pravidla – k čemu aplikace slouží, kdo ji používá, na čem běží a co agent nesmí dělat.
- Architektura – hlavní části systému, datový model a napojení na externí služby.
- Záznamy rozhodnutí – v jaké situaci jsme byli, co jsme rozhodli a jaké to má důsledky. Hlavně u věcí, které by se jinak za měsíc otevíraly znovu.
- Plán a stav funkcí – co je hotové, co se právě dělá a co čeká.
- Návod na zprovoznění – jak projekt spustit, nastavit a nasadit.
- Testy – navržené dřív, než vznikne kód.
Jak vypadá práce na jedné funkci
- Zadání. Popíšu, co má funkce dělat a proč. Jazykem byznysu, bez technického řešení.
- Analýza a návrh. Agent projde kód a dokumentaci a navrhne řešení: co se změní, na co to bude mít dopad, jaká jsou rizika a jak to otestujeme. U větších změn se tady zastavím a návrh si přečtu. Kód se začne psát až po mém souhlasu.
- Rozhodnutí. Pokud funkce mění strukturu aplikace (datový model, integraci, způsob nasazení), vznikne záznam rozhodnutí.
- Testy a implementace. Nejdřív testy podle návrhu, pak kód.
- Ověření a aktualizace dokumentů. Výsledek porovnám se zadáním. Agent aktualizuje plán, stav a dokumentaci jako součást stejné úlohy, ne jako úklid někdy později.
Co mi to v praxi řeší
Souběžnou práci. Na jednom projektu mi často běží víc vláken najednou, například hlavní aplikace a samostatný katalogový modul. Bez sdílených dokumentů o sobě vlákna nevědí a navzájem si přepisují předpoklady. Společná architektura a záznamy rozhodnutí je drží pohromadě.
Návrat po pauze. Když se k projektu vrátím po dvou týdnech, nemusím agentovi znovu vysvětlovat, proč něco funguje tak, jak funguje. Stačí mu dokumenty.
Chyby se najdou dřív. Testy navržené předem zachytí problémy, které by se jinak ukázaly až v provozu. Hlavně u úprav, které na první pohled vypadají malé.
Bezpečnost. Pravidla projektu agentovi říkají, co dělat nesmí. Hesla, tokeny a klíče zadávám sám přímo v administraci jednotlivých služeb. Do chatu ani do repozitáře se nedostanou.
Kdy ten postup nepoužívám
Na rychlý prototyp nebo ukázku pro klienta ne. Tam je rychlost důležitější než dokumentace a kód se často zahodí. Proces zapínám ve chvíli, kdy je jasné, že aplikace bude žít dlouho a bude na ní pracovat víc lidí nebo víc agentů. Takhle vznikají například aplikace pro srovnání produktů s konkurencí nebo reporting na míru.
Dokumenty také stárnou. Pokud jejich aktualizace není součástí každé úlohy, za pár týdnů agentovi spíš škodí, protože popisují stav, který už neplatí.
Jak začít
Stačí dva soubory: popis projektu s pravidly a seznam rozhodnutí. Do prvního napište, k čemu aplikace je, na čem běží a co se nesmí. Do druhého zapisujte každé rozhodnutí, které byste jinak museli vysvětlovat znovu. Zbytek přidávejte, až ho budete potřebovat.
