Kontext
AI Factory vznikla z docela praktického důvodu: nechtěl jsem strávit celé léto u počítače, ale zároveň jsem nechtěl zastavit vývoj AI Coach. Začal jsem proto stavět experimentální systém, který by dokázal část práce dělat za mě — vybírat úkoly, upravovat repozitář, otevírat pull requesty a vracet mi zpětnou vazbu.
Zároveň mě zajímalo, kde jsou skutečné hranice AI. Ne v izolovaném chatu, kde agent odpoví na jeden dotaz, ale v delším vývojovém procesu, kde musí držet kontext, respektovat pravidla projektu, pracovat s větvemi, projít ověřením a zanechat po sobě srozumitelnou stopu.
Problém
Codex mi uměl dobře pomoct s návrhem i implementací AI Coach, ale pořád fungoval hlavně jako nástroj, který bylo potřeba vést za ruku. Každý úkol, každá změna a každé rozhodnutí vyžadovaly, abych seděl u počítače, zadal další krok, zkontroloval výsledek a posunul práci dál. Prakticky to znamenalo vracet se k počítači každých pár minut, což úplně popíralo původní cíl.
Zároveň se ukázalo, že AI je silná v dobře zadaném jednotlivém úkolu, ale slabší v delším vývojovém procesu. Neuměla sama dobře pracovat na více věcech paralelně, držet dlouhodobou kontinuitu a hlídat, jestli se drobné chyby nezačínají násobit. Starší špatné rozhodnutí nebo nepřesnost v kódu se pro novou session snadno staly precedentem: když už to tak v projektu bylo, agent měl tendenci předpokládat, že je to správně.
Přístup
Začal jsem proto stavět nadstavbu nad běžným používáním AI agentů. Cílem nebylo vytvořit jednoho “chytřejšího” agenta, ale proces, ve kterém má agent jasně vymezený kus práce, pravidla projektu, vstupní kontext, ověření a způsob předání výsledku.
Základ tvořily tasky, větve, pull requesty a dokumentované běhy. Agent neměl jen odpovědět v chatu, ale udělat konkrétní změnu v repozitáři, projít ověřením a zanechat po sobě stopu: co dělal, proč to dělal, jak to dopadlo a co se z toho dá příště zlepšit.
Co systém dělal
AI Factory postupně skládala dohromady několik částí běžného vývojového procesu. Uměla pracovat s task boardem, vybrat vhodný úkol, založit větev a pracovní kopii, předat agentovi potřebný kontext, nechat ho provést změnu, spustit ověření a připravit pull request.
Důležitá byla i zpětná vazba. Každý běh neměl skončit jen výsledkem “hotovo” nebo “selhalo”, ale také záznamem toho, co se stalo. Z těchto záznamů pak šlo hledat opakující se problémy: kde agenti ztráceli kontext, kde špatně pochopili zadání, kde chyběla pravidla a kde bylo lepší nahradit AI rozhodování deterministickým skriptem.
Principy
Principy byly pravidla chování, podle kterých měli agenti pracovat napříč celou Factory. Neříkaly, jak implementovat konkrétní feature, ale jak přemýšlet nad prací: jak zacházet se zdroji, jak udržet záměr, kdy se ptát, kdy navrhnout změnu procesu a co musí po běhu zůstat viditelné.
Nezačal jsem je psát jako sadu pravidel pro AI od stolu. Vznikaly ve chvíli, kdy jsem analyzoval, kde agent chyboval, proč k tomu došlo a jak bych podobnou situaci řešil já sám.
Postupně se z toho stal trochu zvláštní reverse engineering vlastního způsobu práce. Snažil jsem se pojmenovat věci, které jako programátor často dělám automaticky: kdy ověřuji zdroj, kdy se zastavím a položím otázku, kdy hledám problém v procesu místo v jedné konkrétní chybě, kdy nevěřím hotovému výsledku jen proto, že “něco prošlo”, a kdy je potřeba nechat po práci srozumitelnou stopu.
Jeden z důležitých principů byl hlídat řetěz záměru. AI měla tendenci ztrácet význam po cestě: moje zadání se přepsalo do tasku, task do promptu, prompt do implementace — a každým krokem se mohl nenápadně změnit smysl. Proto bylo důležité pojmenovávat zdroje, dělat reasoning viditelný a nenechat neurčité formulace typu “tohle” nebo “tamto” rozhodovat o tom, co se bude stavět.
Další skupina principů řešila důkazy. Agent uměl napsat přesvědčivé vysvětlení, ale přesvědčivé neznamená pravdivé. Proto vzniklo pravidlo, že bez dohledatelného důkazu není závěr. Pokud tvrzení nešlo opřít o kód, dokumentaci, log, historii nebo konkrétní artefakt, nemělo se tvářit jako fakt.
Hodně důležitý byl i princip hledat existující řešení dřív, než začnu vymýšlet vlastní. Nešlo jen o externí knihovny nebo známé patterny, ale i o interní historii projektu: jestli už podobný problém někdo neřešil, proč se rozhodl právě takhle a jestli se z toho dá něco použít. AI měla tendenci rychle navrhnout vlastní řešení, ale dobrý vývojář podle mě nejdřív zkoumá, jaké řešení už existuje a jaké trade-offy si s sebou nese.
A některé principy byly o učení. Když se objevila chyba, nechtěl jsem jen opravit jeden konkrétní případ. Snažil jsem se pochopit třídu problému: proč k ní došlo, kde se může objevit znovu a jaké pravidlo nebo změna procesu by jí příště zabránila. Cílem nebylo hromadit seznam výjimek, ale destilovat opakující se vzory.
V tom pro mě byla AI Factory zajímavá i mimo samotnou automatizaci. Nutila mě přemýšlet nad tím, co vlastně dělá dobrého vývojáře dobrým vývojářem — a jak část toho převést do principů, které může následovat agent.
Task board
Práce ve Factory stála na verzovaném task boardu přímo v repozitáři. Tasky nebyly v externím nástroji, ale jako Markdown soubory rozdělené podle domény a stavu: Draft, Ready a Done zvlášť pro AI Coach a AI Factory.
Každý task měl prioritu, závislosti, cíl, scope, acceptance criteria, verifikaci, doporučené čtení a touch set — tedy oblast souborů, ve které se očekávaly změny. Díky tomu mohl agent pochopit nejen co má udělat, ale i proč task existuje, jak poznat hotovo a s čím se jeho práce může dostat do konfliktu.
Nepoužíval jsem klasický stav in progress. Živý zámek byla větev a worktree. Agent si task rezervoval tím, že založil dedikovanou branch, pracoval mimo hlavní checkout a výsledek vracel přes pull request. I blocked nebo superseded výsledek musel skončit jako viditelná změna přes PR, aby po agentovi nezůstala opuštěná větev a task, který na main pořád vypadá jako volný.
Skilly
Skilly jsem rozděloval hlavně proto, aby agent věděl, co v daném režimu může a nemůže dělat. Typický rozdíl byl mezi Project owner a Developer režimem: bez jasných hranic se snadno stalo, že se plánování, dokumentace, implementace a rozhodování slily dohromady.
Project owner měl pomáhat definovat, jak se má aplikace chovat, jaké rozhodnutí ještě chybí a jak změna zapadá do celého systému. K tomu potřeboval širší kontext: dokumentaci, epiky, související rozhodnutí, existující tasky nebo části implementace, které ovlivňovaly návrh.
Developer naopak neměl znovu objevovat celý produkt. Dostal konkrétní task, užší scope, acceptance criteria a soubory, kterých se změna pravděpodobně týká. Jeho práce byla hlavně implementovat, ověřit změnu a připravit pull request — ne během toho přepisovat produktové zadání nebo si sám domýšlet chybějící rozhodnutí.
Vedle toho existoval Task picker / Task coordination, který řešil výběr a rezervaci práce. Agent neměl náhodně vzít “něco z boardu”, ale zohlednit prioritu, závislosti, otevřené pull requesty, aktivní větve, worktree locky a konflikty v touch setu.
A Merge policy fungovala jako bezpečnostní hranice pro hotové pull requesty. Nešlo o otázku, jestli se změna agentovi líbí, ale jestli jde celý její efekt bezpečně vrátit jedním revertem. Pokud ne, nebo pokud změna sahala do citlivějších oblastí, měla počkat na moji kontrolu.
Orchestrator tick
Základní jednotkou práce byl orchestrator tick — jeden ohraničený průchod systémem. Neznamenalo to “pusť AI a uvidíme”, ale konkrétní sekvenci kroků kolem jednoho tasku.
Tick nejdřív zkontroloval, jestli může vůbec začít: jestli neběží jiný tick, jestli nejsou otevřené blokující pull requesty, jestli existuje vhodný task a jestli se jeho touch set nebije s jinou rozpracovanou prací. Pokud bylo bezpečné pokračovat, vybral task, založil branch a worktree, připravil agentovi kontext a spustil ho.
Agent pak pracoval na jednom konkrétním tasku. Po doběhu tick zachytil výstupy, logy a metadata běhu, spustil ověření, připravil nebo zpracoval pull request a poslal výsledek do Discordu. Teprve potom mohly následovat pozorovací kroky jako learner nebo hledání kandidátů na zlepšení procesu.
Důležité pro mě bylo, že orchestrátor neměl být další agent, který si všechno interpretuje po svém. Měl být spíš spolehlivé potrubí: výběr práce, locky, větve, worktree, logování, ověření a handoff. AI měla řešit samotnou změnu, ne pokaždé znovu vymýšlet mechaniku kolem ní.
Triage tick
Vedle orchestrator ticku existoval i triage tick. Ten neřešil implementaci připravených tasků, ale vstupy, které ještě nebyly dost jasné na to, aby se podle nich dalo bezpečně stavět.
Typicky šlo o bugy nebo návrhy poslané přes Discord. Nechtěl jsem, aby se syrový report rovnou změnil v implementační task, protože v něm často chyběl kontext, rozhodnutí nebo jasné očekávání. Triage tick proto vzal jeden takový vstup, vytvořil pro něj větev a worktree a nechal agenta zjistit, co se s ním má stát dál.
Výsledkem nemuselo být hned zadání pro vývoj. Někdy stačilo report odmítnout nebo označit jako duplicitní. Jindy bylo potřeba položit mi otázku s konkrétními možnostmi. A když bylo zadání dostatečně jasné, triage mohl doplnit dokumentaci nebo připravit implementační task, který už pak mohl převzít běžný orchestrator tick.
Tohle pro mě bylo důležité kvůli hranici mezi vstupem a prací. Bug report nebo nápad ještě není task. Task má mít cíl, scope, acceptance criteria, verifikaci a dostatek kontextu, aby ho agent nemusel během implementace domýšlet.
Learning vrstva
Po každém běhu se systém neměl jen posunout dál, ale také se z něj něco naučit. K tomu sloužila learning vrstva.
Learner se díval na zachycené výstupy běhu: co agent dělal, kde narazil, co bylo nejasné, kde chyběla pravidla nebo kde se opakoval známý typ problému. Výsledkem nemusela být vždy akce. Někdy bylo správné říct, že se nenašlo nic důležitého. Jindy vznikl finding nebo candidate — návrh na zlepšení procesu.
Candidate nebyl automaticky nový task. Šel přes samostatnou approval vrstvu, protože jsem nechtěl, aby si Factory sama nekontrolovaně měnila vlastní pravidla. Pokud návrh dával smysl, mohl se později proměnit v task, úpravu principu, změnu workflow nebo obyčejný skript.
Kromě per-run learneru existoval i strategy review. Ten se nedíval jen na jeden běh, ale na širší historii systému: opakující se problémy, backlog kandidátů, stav principů a proces jako celek. Byl to způsob, jak občas ustoupit od jednotlivých tasků a zeptat se, jestli se Factory zlepšuje správným směrem.
Discord jako ovládací plocha
Discord byl pro Factory lidské rozhraní. Nechtěl jsem kvůli každému kroku otevírat repozitář nebo sedět u počítače, takže jsem si postavil způsob, jak systém sledovat a částečně ovládat z telefonu.
Přes /run šlo spustit jeden orchestrator tick a přes /status zjistit stav běžící nebo poslední práce. Průběh běhů se posílal do #runs, krátké výsledky do #messages a věci, které opravdu vyžadovaly mou pozornost, do #alerts.
Nejdůležitější byl #inbox. Sloužil jako místo, kde se soustředily věci čekající na rozhodnutí: kandidáti na zlepšení, otázky z triage nebo výsledky, které potřebovaly moji reakci. Místo volného chatu se systémem jsem dostával konkrétní karty s možnostmi: přijmout, odmítnout, otevřít detail nebo odpovědět na otázku.
Discord ale nebyl jen pro mě. Další uživatelé přes něj mohli posílat bugy nebo návrhy na zlepšení. Ty se nejdřív uložily jako syrový vstup a teprve po schválení se dostaly do triage, kde z nich mohl vzniknout doplněný kontext, otázka nebo připravený task.
Discord tím nebyl zdroj pravdy, jen pohodlná ovládací vrstva nad soubory, task boardem, pull requesty a běhy v repozitáři. Záměrně to nebyl vzdálený shell. Bot nespouštěl libovolný text napsaný do Discordu; každá akce vedla na předem připravený skript s omezenými vstupy.
Výsledek
AI Factory mi umožnila posunout část vývoje AI Coach do režimu, kdy agenti dokázali pracovat samostatněji než v běžném chatu. Neznamenalo to, že bych mohl vývoj pustit bez kontroly. Spíš se změnil typ práce, kterou jsem dělal já: místo neustálého zadávání dalšího kroku jsem víc řešil pravidla, hranice, kontrolu výstupů a zlepšování samotného procesu.
Nejcennější pro mě nebylo jen to, že agenti zvládli otevírat pull requesty. Důležitější bylo vidět, kde autonomie funguje a kde se rozpadá. Některé části šly dobře automatizovat, jiné potřebovaly přesnější zadání, lepší kontext nebo tvrdší guardrails. A občas se ukázalo, že místo další AI instrukce je lepší napsat obyčejný deterministický skript.
Zároveň to pro mě nebyl jen experiment s AI, ale i způsob, jak lépe pochopit vlastní vývojový proces. Když jsem chtěl, aby agent pracoval samostatněji, musel jsem pojmenovat věci, které jinak dělám intuitivně: jak zadávám práci, jak ověřuju závěry, jak poznám hotovo, kdy chci rozhodnutí a kdy stačí automatizace.