Cestou k temné továrně: z úrovně 2 na úroveň 3 za týden

1. díl z 5 v sérii „Towards the Dark Factory“ (Cestou k temné továrně)

24. září ve tři čtvrtě na šest večer commitnul Petr, který SaaSForge vede, do prázdného repozitáře designový handoff pro iPhone aplikaci. Naše produkty jsou Flutter a JVM. Ve Swiftu nikdy nenapsal ani řádek, který by šel do produkce. Sázka, kterou ten večer uzavřel sám se sebou, nezněla „umí AI psát Swift“ (umí), ale něco užšího a podle nás zajímavějšího: dá se osvojit jazyk, který neznáte, tím, že řídíte proces, místo abyste psali kód? Od prvního commitu nebude kód psát žádný člověk. Člověk bude psát pravidla, specifikace a rozhodnutí a číst, co se vrátí.

Tahle série je záznam prvních týdnů. První díl popisuje, jak proces vypadá a co vyprodukoval první týden. Druhý díl je validační vrstva. Třetí díl je o tom, jak si agenti na jednom Macu určují tempo sami. Čtvrtý díl je o tom, jak plní backlog. Pátý díl je o tom, kde ještě zůstává člověk, a sázku poctivě vyhodnotí.

Ta aplikace je Sestava, intervalový a silový časovač pro iPhone s otevřeným formátem plánu, který napíšete v tabulce.

Slovník: úrovně a zeď

Ten název je starší než software: továrna se zhasnutými světly (lights-out) běží potmě, protože uvnitř nikdo není, a obvyklým příkladem je japonský závod firmy FANUC, kde roboti stavějí roboty. V lednu 2026 ji Dan Shapiro, CEO Glowforge, postavil na vrchol svých The Five Levels, žebříku programování s AI podle vzoru úrovní automatizace řízení, od úrovně 0, kde bez vašeho souhlasu nedopadne na disk ani znak, po temnou softwarovou továrnu na úrovni 5; o dva týdny později AI tým firmy StrongDM zveřejnil, jak pracuje: kód nepíší ani nerevidují lidé a kontrolují ho scénáře často uložené mimo kódovou základnu, podobně jako odložená (holdout) data, a digitální dvojčata služeb, se kterými kód mluví. Článek Saumyi Tyagiho The Dark Factory Pattern (HackerNoon, únor 2026), podnícený textem StrongDM a článkem OpenAI Harness Engineering, z toho udělal plán zavádění po fázích a jeho slovník nám dal slova, která nám chyběla. Jeho úrovně autonomie, převzaté od samořídících aut: na úrovni 1 vám AI dokončuje věty; na úrovni 2 píše celé funkce nebo soubory a vy revidujete každou změnu; na úrovni 3 generuje kód ze specifikací, kvalitu hlídají odložené scénáře (holdout scenarios) a vy schvalujete merge (úroveň 3,5 nechá některé služby mergovat samy); na úrovni 4, v plné temné továrně, dovnitř jdou specifikace a ven vychází otestovaný, zamergovaný kód. Mezi vrstvou, která kód generuje, a vrstvou, která ho validuje, stojí zeď: generátor nikdy nevidí akceptační scénáře, validátor se nikdy nedozví, jak kód vznikl — stejné oddělení jako trénovací a testovací data ve strojovém učení. A backlog je napojený na generování specifikací, takže z ticketů vznikají specifikace, aniž by je někdo přepisoval.

Tyhle pojmy budeme používat v celé sérii a budeme říkat na rovinu, kde náš proces není tím z článku. Dva rozdíly hned na začátek. Tyagiho zeď tvoří odložené scénáře podle StrongDM: akceptační testy v prosté angličtině, které posuzuje samostatný LLM hodnotitel proti dočasnému nasazení. Naši zeď tvoří deterministické brány (100% pokrytí, mutační runner, přehrání plánů bajt po bajtu) plus nezávislý reviewer, a máme přesně jedno pravidlo s odloženými daty, které vysvětlí druhý díl. A náš backlog není napojený na generování specifikací štítkem na ticketu; plní ho retrospektivy a skill, který zakládá issues v pevném tvaru, o čemž je čtvrtý díl.

Kde jsme byli: úroveň 2

V červnu jsme psali o hackathonovém týdnu se 140 pull requesty. Přečteno Tyagiho slovníkem to byla úroveň 2 dělaná ve velkém: agenti psali celé soubory, agent procházel pull requesty a lidé rozhodovali o tom, co vynesl, a propustnost přicházela z toho, kolik nezávislých problémů jsme udrželi rozpracovaných najednou. Fungovalo to a bylo to vyčerpávající, protože review bylo tou sériovou částí.

Sestava začala na úrovni 3 od prvního commitu. Nikdo nečte diffy řádek po řádku. Jeden agent implementuje, jiný agent adversariálně reviduje, následuje kolo oprav, reviewer je znovu zkontroluje, proběhnou brány a vlastník schválí merge z pull requestu, jehož popis byl na konci přepsán z review a z výsledků posledních bran. Sám vlastník reviduje tvrzení, ne kód: říká popis, co běželo, na kterém commitu a s jakým výsledkem?

Soubor se smlouvou

Všechno začíná souborem CLAUDE.md, který Claude Code čte na začátku každé session. Ve své první verzi, commitnuté s kostrou balíčku první večer, měl 201 slov. K 29. září měl 1 435 slov a byl změněn v 38 commitech. Obsahuje tři druhy věcí.

Pravidla o kódu. Pár, všechna ověřitelná:

• Důkazy před hypotézami: říkej, co jsi ověřil (spustil, přečetl, dekódoval), a co jen tušíš.
• Jakýkoli bug: napiš selhávající test, který ho reprodukuje, sleduj, jak selže, pak oprav. Test si nech.
• Pokrytí je 100 % bez výjimek. Přeživší mutant je selhaný build. Žádné přeskočené testy.
• Typované chyby nesou polohu jako data; UI nikdy nematchuje text chyby.
• Žádné Date() v Sources/ mimo jeden typ tickeru; enginy dostávají now jako parametr.
• Všechny věty pro uživatele pocházejí z jednoho katalogu Copy; test selže na rozdílu mezi katalogem a kódem.

Pravidla o práci s agenty. Tahle sekce první den neexistovala. Za každý řádek v ní se zaplatilo incidentem (čtvrtý díl má deník): jeden git worktree na běh, stagovat explicitní cesty a nikdy -A ve sdíleném checkoutu, zadání a hlášení předávat jako soubory, nejvýš dva swiftové běhy najednou a jeden, když běží mutační brána, jeden nabootovaný simulátor najednou, worktree ukončit v den, kdy se jeho větev zamerguje.

Odkazy. Kde jsou specifikace, kde jsou plány, který skript je která brána, jak založit issue.

Soubor se smlouvou je próza a už dříve jsme tvrdili, že próza build neshodí. To platí dál; rozdíl je, že skoro každá věta v pravidlech jmenuje skript, test nebo štítek, který build shodí. Próza je rejstřík, brány jsou zákon.

Jednotka práce: specifikace a její protivník

Tyagiho úroveň 3 říká „generuje kód ze specifikací“. Zajímavá otázka je, odkud se specifikace berou a kdo je kontroluje, protože specifikace napsaná na jeden zátah schopným modelem se čte jako hotová a hotová není.

Naše jednotka práce je specifikace plus její adversariální review. Jedna z prvních specifikací, ta pro tréninkové formáty, vypadala soudržně a měla 38 mezer; tři kola review nezávislým agentem je našla dřív, než existoval řádek kódu. Třetí den z toho bylo pravidlo: každá specifikace dostane nezávislé adversariální review, než se z ní napíše plán. Čtvrtý den se totéž pravidlo rozšířilo na plány poté, co plán, který šel do pull requestu bez review, obsahoval tři kritické nálezy, z nichž dva se týkaly vlastníkových rozhodnutí, která text plánu potichu nevstřebal.

Plán se pak vykonává jako běh řízený subagenty: řídicí agent posílá na každý úkol jednoho implementátora, na každý úkol nezávislého reviewera, kolo oprav, když review vyžaduje změny, a opětovné review opravy. Hlášení implementátora musí ukázat nejdřív červenou, a to s počtem: „29 nových testů bylo na starém kódu červených“ je důkaz, který si reviewer může ověřit, a revieweři si ho ověřují; standardem je, že reviewer znovu spustí implementátorovy reprodukce a nikdy mu nevěří na slovo.

Ještě jedno pravidlo přišlo z plánu pro Apple Watch, psaného šestý den. Jeho návrh autority běhu se zkompiloval a neměl testy. Při prvním otestování selhalo 15 ze 131 testů a 14 z nich byly vady: běh skončil dvakrát, obnova se navždy zablokovala, záloha se nikdy nesmazala. Od té doby se kód v plánu počítá za ověřený, jen když jeho testy proběhly; „kompiluje se“ se hlásí jako „neověřeno“.

Mechanika: worktree, zadání, deníky

Každý běh dostane vlastní git worktree, pojmenovaný po běhu. Každý agent dostane jeden pracovní adresář, pojmenovaný po agentovi, smazaný, když skončí. Zadání jdou agentům jako soubory, hlášení se vracejí jako soubory a diffy se čtou z gitu, nikdy se nevkládají do konverzace. Důvod je prozaický: řídicí agent, který nese celý svůj běh v kontextu, je po zhruba 120 až 150 voláních nástrojů odříznut prostředím, a běhy jsou delší. Každý řídicí agent si proto vede deník, progress.md, s řádkem na každý krok a řádkem RESUME POINT před každým čekáním. Když je odříznut, nástupce si deník přečte a pokračuje; nikdy znovu neposílá úkol, o kterém deník říká, že je hotový. Třetí díl je o tom, co to umožňuje.

První den, hodinu po hodině

Log commitů z 24. září je nejlepší shrnutí toho, jak úroveň 3 vypadá zvenčí.

Třicet commitů mezi designovým dokumentem a swiftovým balíčkem jen nad Foundation, s enginem tréninku, dvěma dekodéry, branou 100% pokrytí a mutační branou, za šest hodin, v jazyce, který by člověk u klávesnice nedokázal napsat. Ani řádek z toho nenapsal. Commity dalšího rána zpřísnily formát a zaznamenaly dodělávky z posledního review.

První týden v číslech

Všechna čísla jsou k večeru 30. září (main repozitáře v 17:39 místního času), šest dní po prvním commitu, přečtená z repozitáře a jeho pull requestů.

• Commity na main za den: 30, 88, 105, 158, 52, 195, 98 (24. až 30. září); celkem 726. 575 z 582 commitů, které nejsou merge, nese trailer se spoluautorstvím agenta; objevuje se v nich pět modelů, většina od jednoho.
• Zamergované pull requesty: 82, mezi 9 a 20 za den.
• Založené issues: 120, z toho 88 otevřených a 32 zavřených; 25 z nich nese štítek, kterým reviewer odkládá nález, místo aby blokoval merge (čtvrtý díl).
• Swift: 409 souborů, z toho 203 testovacích; zhruba 18 400 řádků zdrojového kódu a zhruba 22 200 řádků testů ve dvou balíčcích a aplikaci.
• Testy, u pull requestu vlny typovaných chyb z 30. září: 621 v balíčku jádra, 557 v balíčku aplikační logiky, 115 unit testů v aplikačním targetu, 28 UI testů na simulátoru. Pokrytí 100 % řádků, funkcí a regionů v obou balíčcích; brána tiskne zlomek.
• Mutanti: 1 730 vygenerovaných na jádře a 1 706 zabitých; 1 622 na balíčku aplikační logiky a 1 615 zabitých; každý přeživší je na seznamu výjimek s jednořádkovým zdůvodněním a zastaralá položka bránu shodí.
• Dodáno: první build do TestFlightu odešel ráno 29. září, archivovaný Xcode Cloudem z main; druhý se postavil sám z dalšího merge. Vlastníkův průchod na zařízení s tím druhým buildem, ještě téhož dopoledne, přinesl do hodiny deset nálezů, založených jako jedno issue s číslovanými řádky.

Co za těch šest dní vzniklo: balíček jádra (první den), balíček aplikační logiky s úložišti, importem, koordinací běhu, historií a zařízeními (druhý den), webový editor formátu plánu v TypeScriptu (druhý a třetí den), vlna tréninkových formátů napříč všemi třemi (čtvrtý den), iPhone aplikační target s obrazovkami (čtvrtý a pátý den), widgety, živá aktivita a připomínky (šestý den), web v angličtině a češtině a začátky blogu. Mezi dalšími specifikacemi napsanými a zrevidovanými ten týden byly model detailu tréninku, Apple Watch, diktování a typovaný model chyb.

Čísla o tokenech a penězích publikovat nebudeme; nejsou smyslem téhle série a zastarala by rychleji než cokoli jiného v ní. Co publikovat budeme, je cena v incidentech, protože odtud přišla pravidla a je to ta poctivá polovina příběhu.

Co úroveň 3 není

Na úrovni 3 Tyagiho žebříku merge pořád schvaluje člověk. U nás také, a víc než to: člověk odpovídá na otázky o faktech produktu, čte češtinu a drží telefon v ruce. Zajímavá otázka pro zbytek série není, jestli agenti umějí napsat kód (tabulka výše to vyřizuje), ale jestli zeď mezi generováním a validací vydrží bez člověka, který čte diffy, a v čem vlastně spočívá zbývající práce člověka. Druhý díl je zeď.

Toto je 1. díl série Towards the Dark Factory. 2. díl: Zeď (vyjde 9. října). 3. díl: Tempo určuje agent (vyjde 16. října). 4. díl: Agent plní backlog (vyjde 23. října). 5. díl: Kde ještě zůstává člověk (vyjde 30. října).

Související: 140 pull requestů za týden · Lintujeme promptovou vrstvu

Titulní foto: Kamekichi Photos na Unsplash.