58 commitů, čtyři stacky, jeden den

Kontext

AIssistant je SaaS pro český trh: multi-kanálový AI asistent, který za firmy vyřizuje rezervace a zákaznickou komunikaci e-mailem a telefonicky. Technicky netriviální systém: multi-tenant architektura s Row Level Security na PostgreSQL, Stripe billing se třemi tarify a add-ony, telefonie přes Twilio, realtime voice pipeline (STT → LLM → TTS) s latencí pod 500 ms a tvrdé GDPR požadavky, tedy veškeré zpracování v EU.

Tři programovací jazyky, tři aplikace, jeden člověk. Klasická odpověď by byla „najmi tým“. Odpověď v tomto projektu byla postavit ho z AI agentů.

A nejde o „vývoj s AI asistencí“ na okraji: prakticky celý kód produktu (přes sto tisíc řádků napříč třemi stacky) napsali AI agenti. Lidská role je produktová a provozní: zadání, priority, rozhodnutí, schvalování a nasazení. Popsaný den není výjimečná ukázka, ale běžný pracovní režim, ve kterém produkt vznikl.

Tři konstrukční rozhodnutí

1 · Team-lead nesmí psát kód ani verifikovat. Jeho definice obsahuje explicitní zákazy: žádná implementace (nouzová výjimka ~5 řádků), žádné spouštění testů či čtení diffů mezi implementací a review. Pokušení „ušetřit kolečko“ vlastní kontrolou je v definici výslovně označeno za chybu. Oddělení implementace a verifikace je celý smysl role.

2 · Reviewer nesmí kód měnit. Smí pouze číst, analyzovat a reportovat, a to „jako by kód šel okamžitě do produkce a čekaly na něj nepřátelské vstupy, souběhy a částečné výpadky“. Nálezy vrací se severitou (🔴 blocker / 🟡 warning / 🔵 nit), přesným soubor:řádek, návrhem opravy a vlastníkem. Hotovo je teprve „review clean“, tedy nula otevřených nálezů.

3 · Reviewer má perzistentní paměť verzovanou v gitu. 43 tematických souborů, ~230 zaznamenaných vzorů: pasti, které v tomto projektu už jednou někoho spálily. Team-lead je před každým spawnem vkládá specialistům do zadání. Chyba nalezená v březnu se v červenci už nedostane ani do review.

Vedle rolí drží kvalitu skill balíčky (devět souborů kodifikovaných standardů s předností před jakýmkoli zadáním) a OpenAPI-first kontrakty. Spec je zdroj pravdy pro všechny tři stacky a reviewer kontroluje drift.

Proces: od auditu k „review clean“

1. Scope analýza. Team-lead určí specialisty z „technologických otisků“ úlohy. Při nejednoznačnosti spawne víc; každý má klauzuli sebe-eliminace.
2. Paralelní implementace. Specialisté různých stacků pracují souběžně; závislosti řeší zpráva „kontrakt hotov“.
3. Review přichází okamžitě po implementaci. Reviewer čte diff i blast radius: volající kód, migrace, generované klienty, testy.
4. Routing nálezů. Team-lead je rozdělí podle vlastníka a pošle zpět v plném znění.
5. Stateless re-review. Reviewer znovu čte dotčené soubory a soudí podle aktuálního kódu, ne podle poznámek. Smyčka běží do nuly nálezů.

I backlog toho dne vznikl stejným mechanismem: ráno v 10:39 adversariální audit tří stacků proti feature matici vyprodukoval 38 úloh s prioritami, závislostmi a odkazy na konkrétní řádky, včetně nálezů typu chybějícího vynucení placené funkce, které by jinak znamenalo tichý únik tržeb.

Den v číslech

Rozsah nebyl „hodně malých úprav“. Za den vznikly mimo jiné: minutové metering hovorů s tvrdými kvótami, operator fallback s ochranou proti toll fraud, Stripe plan-change flow s proration sagou, CSV exporty s OWASP ochranou, kill-switch parita pro hlasový kanál, produkční deployment konfigurace a PIN-gated hlasové vyhledávání. K tomu deset nových DB migrací a FE test suite, která vyrostla ze 701 na 783 testů, na konci dne 783/783 zelených.

Co review skutečně zachytilo

Konkrétní technické detaily nálezů v publikované verzi záměrně zobecňujeme. Všechny byly opraveny před sloučením větve, ale mapa vlastní útočné plochy do případové studie nepatří. Pět tříd z toho dne:

Žádný z těchto nálezů není stylistika. Jsou to třídy chyb, které v běžných týmech procházejí i seniorním review. Vyžadují držet v hlavě sémantiku databázových bezpečnostních politik, billing externích platforem i chování kancelářského softwaru zároveň.

Proč to funguje

1. Oddělení implementace a verifikace je strukturální, ne dobrovolné. Implementátor nemůže schválit sám sebe a orchestrátor nemůže review přeskočit. Role to technicky neumožňují.
2. Paměť revieweru se skládá. Každý nález se stává vstupem příštího zadání; křivka učení týmu je uložená v gitu.
3. Standardy jsou kodifikované, ne tradované. Skill pravidla mají přednost před zadáním i existujícím kódem.
4. Kontrakty místo koordinace. OpenAPI spec umožňuje třem stackům pracovat paralelně; drift chytá review, ne integrace za týden.
5. Stateless re-review. Reviewer nemůže „odmávnout“ opravu na základě popisu, musí ji znovu přečíst.

Poctivé limity

• Člověk zůstává produktovým vlastníkem i ops. Produktová rozhodnutí, Stripe katalog, Twilio konfigurace, prod secrety a deploy jsou explicitně lidské brány. „Review clean“ neznamená „nasazeno“.
• Metriky měří výstup a disciplínu, ne byznys hodnotu. 18 958 řádků za den vypovídá o kapacitě procesu; o správnosti spíš 39 review běhů a regresní testy z nálezů.
• Review má náklady. Ø 1,6 kola znamená reálné vícenáklady na tokeny i čas. Je to záměr, ne režie k optimalizaci.
• Počty commitů jsou spodní odhad. Historie repozitáře byla průběžně squashována; 179 commitů nevypovídá o skutečném počtu iterací. Session z 11. 7. je naopak zachycena commit po commitu, a proto je hlavním datovým vzorkem.
• Proces přiznává vlastní slepá místa. Reviewer si zapisuje i nálezy o vlastním prostředí a procesu, ne jen o kódu.

Čísla celého projektu (21. 2. – 11. 7. 2026)

Detail k vypíchnutí: backend má víc testovacího kódu (38 823 ř.) než produkčního (35 592 ř.). To není vlastnost AI kódování obecně. Je to přímý důsledek revieweru, který odmítá podepsat změnu bez pokrytí chybových cest, a paměti plné vzorů typu „superuser test tuhle chybu maskuje, chce to test s aplikační rolí“.

Závěr

Agentní tým není „rychlejší autocomplete“. Je to organizační vzor: role s oddělenými pravomocemi, adversariální verifikace jako neobejitelná brána, kodifikované standardy a paměť, která se skládá v čase. Jeden člověk s tímto vzorem uřídil za den objem práce odpovídající sprintu vícečlenného týmu, a to s auditní stopou kvality, jakou většina lidských týmů nevede.

Největší páka není v tom, kdo kód píše, ale v tom, jak je postavená smyčka, která ho odmítá pustit dál.