V Keboola Connection pořád běží část systému na Zend Frameworku 1, zbytek už je v Symfony. Tu starou část se snažíme odříznout, co nejvíc a co nejrychleji. Stačil krátký prompt a za zhruba 22 hodin se merglo 13 pull requestů. Tři další jsou otevřené. A může to jet dál, dokud nějaký Zend v Connection zbývá.
Továrna se zhasnutými světly
Dark factory, někdy taky lights-out factory, je v průmyslu označení pro výrobu, která může jet skoro bez lidí na hale. Světla můžou zůstat zhasnutá, protože u linky nemusí nikdo stát. Stroje berou materiál, vyrábějí, na konci padá hotový kus. Člověk tu linku nejdřív postavil, nastavil pravidla a pak chodí hlavně tehdy, když je potřeba údržba, kontrola kvality nebo zásah. Málokterá továrna takhle jede úplně nonstop a úplně bez lidí. Jako představa to ale sedí.
A přesně o tom je tenhle pokus. Ne o tom, jestli agent jednorázově odstraní Zend. O tom, jestli jde s kvalitním harness postavit linku, která může jet sama. Když to máte, stačí krátký prompt.
Stačilo napsat tohle
Tvůj cíl je zbavit Connection co nejvíc Zendu. Máš na to čas do pátku.
Pracuj ve worktrees, používej skilly z repa na odstranění Zendu a nezakládej moc PR najednou, ať je stíháme začleňovat.To je celé zadání. Žádný dlouhý plán, žádné postupné dávkování úkolů z mé strany. Cíl a termín: co nejvíc Zendu pryč do pátku. Zbytek jsou mantinely. Každý agent ve vlastním worktree, ať si nelezou do cesty. Používat skilly, které v repu už jsou. A nezahltit nás PRky, protože je pořád musíme stihnout začlenit.
V tom promptu přitom není, jak se task dotahuje k merge, že se má každý PR otestovat end-to-end testy, jak se merguje do masteru, co je ještě potřeba odříznout, ani který gate stačí approvem od robota a který chce člověka. To všechno už v tom setupu je. Proto stačí dvě věty. Bez toho, co je pod tím, by to byl jen odvážný vzkaz do chatu.
Mapa je důležitější než skill
Jako poslední věc tam máme skill migrate-highway. Sám o sobě není až tak důležitý. Důležitá je mapa, která je jeho součástí.
Říká, které soubory z moderní části aplikace ještě závisí na té staré. Co se musí odřezat, předělat, zreformátovat, převést konstanty a všechno možné. Mapu jsem jednou vygeneroval s pomocí AI. Teď ji přepisuje AI a na kontrolu je skript. Agent ji nemusí na začátku znovu objevovat. Má mapu, z ní si bere další kus a jde dál.
Odstranil jsem 56 závislostí z nové codebase na starou.
Od Linearu až po merge
Okolo té mapy máme pořád ty samé skilly jako v setupu. ship-task vezme task z Linearu a dotáhne ho až těsně před merge. Gaty jsou popsané ve skillech. Něco se smí mergovat jen na základě approvu od robota. Něco potřebuje lidské review.
Není to tedy jen „tady máš soubor, přepiš ho“. Agent si práci z Linearu vezme a dotáhne. Každé PR jde stejně: draft, E2E, label ai-review, přepnutí na ready a zařazení do merge queue. Na každý git worktree připadá jeden agent.
K tomu máme skilly na E2E testy, hlídání PR a review vláken, pre-commit kontroly a migraci endpointů.
Když gaty řeknou, že stačí robot, může to jít dál bez člověka. Když řeknou, že je potřeba lidské review, počká. Až to člověk schválí, mergne se to automaticky. Člověk z linky nezmizel. Pořád schvaluje to, co lidské review vyžaduje. Nemusí ale stát u každého kroku a ručně posouvat práci dál.
BTW, tenhle harness jsme nestavěli kvůli tomuhle jednomu pokusu. Jak takový setup u nás vypadá, jsem popisoval v článku Lepší modely má každý. Proč s nimi někdo letí a jiný ne?. Tady jsem ho jen pustil na jeden jasný cíl a nechal ho jet.
13 PR za 22 hodin
Hlavní session Claude Code je organizátor. Spouští subagenty, ti se starají o konkrétní úkoly, a sama jen kontroluje, jestli dodrželi všechny podmínky pro merge do masteru. A jedou, jedou, jedou, dokud se nesplní daný cíl.
Právě jsem si to otestoval. Za zhruba 22 hodin se merglo 13 PR, tři jsou otevřené, dohromady 16. Jedno z otevřených už je v merge queue, dvě čekají na approval, u jednoho z nich ještě doběhne E2E po rebase. Nic není zaseknuté.
Medián od otevření k mergi je zhruba dvě hodiny. Nejrychlejší PR bylo hotové za 57 minut. Ty, které šly ven přes noc, čekaly na review 10 až 13 hodin. Jedno PR trvalo 5,7 hodiny kvůli dlouhé E2E frontě a opravě bugu.
Mergnuté změny byly malé. Role, quoting, admin features, detail komponenty, table profile, oprava metadat, metadata kontrakt, detail UI aplikace, event application, rozklad stringového ID, mrtvé Zend view, seznam metadat tabulky, konstanty u file storage provideru.
Nejvíc brzdí dvě věci: E2E fronta a čekání na lidské approvals. Single-suite běhy se řadí ve frontě s ostatními a typicky se čeká 30 až 90 minut. Reviewer bot u některých PR vrátí needs_human. A když už review visí na člověku, agent ho podle pravidel znovu nežádá.
Dvakrát pustil E2E dřív, než byla postavená image PR, jednou se špatným filtrem. Opravil si to sám. Jeden omyl: vybral kandidáta podle zastaralého lokálního main a ten kus už byl hotový v mergnutém PR. Ztratil se jen čas agenta. Od té doby bere kandidáty z origin/master.
Těch 70 zbývajících akcí sice bez člověka neudělá. Ale Zend závislosti ubývají a linka jede i přes noc. Docela cool věc.
