Když se řekne „AI agenti píšou produkt”, většina lidí si představí buď demo, které se rozpadne při prvním reálném uživateli, nebo nekontrolovaný generátor kódu, po kterém nikdo neví, co vlastně běží v produkci. Tahle case study popisuje třetí cestu: reálný produkt, reálné nasazení, reální uživatelé — a governance vrstvu, díky které bylo celou dobu jasné, kdo co rozhodl, co je hotové a co to znamená.
Výchozí stav
Yggaro Lite je samostatný produkt Yggnet Labs: nástroj pro malé týmy postavený na jediném binárním souboru v Go, s replikačním modelem inspirovaným klasikou Lotus Notes. 10. července 2026 ho jako rozpracovaný projekt převzal do správy jeden z našich AI agentů — s mandátem dotáhnout ho do provozu.
Důležitá poctivost hned na začátku: nezačínalo se od nuly. Existoval základ kódu z předchozí práce jiného agenta. Převzetí ale znamenalo: cizí rozpracovaný kód, žádný provoz, žádná infrastruktura, žádní uživatelé.
Co se stalo — časová osa
| Datum | Milník |
|---|---|
| 10. 7. | převzetí rozpracovaného produktu, zmapování stavu, plán |
| 12. 7. | živý SaaS: yggarolite.cz, provozní VM, dashboard, Telegram bot pro provozní hlášení |
| 14. 7. | roadmapa v1 kompletní: výkazy práce, notifikační zvonek, šablony, procesy — nasazeno pro pilotního zákazníka, E2E testy 17/17 zelených |
| výhled 14. 8. | dokončení produktu pro veřejné spuštění (pracujeme na dřívějším termínu) |
Dva dny od převzetí k živému SaaS. Čtyři další dny k dokončené v1 se sedmnácti zelenými end-to-end testy. Bez nočních směn lidského týmu — člověk dělal přesně to, co mu metodika vyhrazuje: rozhodoval.
Kde v tom byla governance
GALDUR tady nefungoval jako brzda, ale jako důvod, proč se dalo jet takhle rychle bez ztráty kontroly:
- Intent-first: každý balík práce začínal záměrem s jasným akceptačním kritériem, ne task-listem. „Hotovo” nebylo pocit, ale splněná podmínka.
- Validation Gate: dokončené celky procházely bránou, kde rozhoduje člověk — kurátor viděl evidenci (commity, testy, živé nasazení), ne sliby.
- Trace: každý krok zanechal auditní stopu v work logu. Když se dnes zeptáte „proč je to postavené takhle”, odpověď se dá dohledat, ne rekonstruovat po paměti.
- Drift signály: když se práce odchýlila od záměru, vznikl záznam — a řešil se, dokud byl malý.
Rychlost nevznikla tím, že se governance obešla. Vznikla tím, že rozhodovací bod pro člověka byl úzký a dobře mířený: agent nepřerušoval vlastníka kvůli formalitám a vlastník nemusel kontrolovat řádky kódu, protože kontroloval podmínky a evidenci.
Co nefungovalo
- První odhad „v1 celá za 4 dny” byl špatně — poctivá formulace je „k živému SaaS za 2 dny, v1 za 4 dny poté”. Přesně kvůli takovým korekcím metodika vyžaduje, aby tvrzení byla podložená evidencí.
- Provozní poučení z prvních dnů SaaS (monitoring, správa tajemství, release disciplína) si vyžádalo vlastní iteraci — a přetavilo se do interního standardu pro další produkty.
Co si z toho odnést
Malý hybridní tým — jeden člověk s rozhodovací pravomocí a AI agenti s jasným mandátem — dokáže doručit produkt v řádu dnů. Podmínkou není „lepší prompt”, ale explicitní governance: záměry s testovatelnými podmínkami, lidské brány na správných místech a auditní stopa, která vytváří důvěru.
Tato case study je jednou z podmínek, které si GALDUR sám stanovil pro verzi v1.0 („alespoň 3 case studies”). Metodika je otevřená — dokumentace, šablony, komunita.
Komentáře
…