Představme si programátora, který si pořídil několik AI pomocníků, aby konečně přestal dělat rutinu. Jeden čeká na přístup, druhý potřebuje rozhodnout mezi dvěma řešeními, třetí odevzdal změnu a čtvrtý právě narazil na rozbité testy. Každý pracuje ve vlastním okně a každý má důvod člověka vyrušit. Kód přibývá rychleji. Programátor ovšem místo programování přenáší zprávy mezi stroji, které mu měly práci ubrat.
Tracelight tento problém popsalo nezvykle otevřeně. V blogu z 21. října 2026 Aleksander Misztal vysvětluje, proč si tým postavil vlastní řídicí nástroj Factory a přestal organizovat vývoj jako soubor osobních rozhovorů s jednotlivými agenty. Firma uvádí, že od změny pracovního postupu ztrojnásobila počet slučovaných požadavků na změnu kódu. To je její vlastní provozní údaj, ne nezávisle změřený růst produktivity.
Na příběhu je podle mě zajímavější něco jiného než vítězné číslo. Tracelight narazilo na hranici, kterou lepší generátor kódu sám neodstraní: lidský den se neprodlouží pokaždé, když přidáme dalšího agenta. Jestliže automatizace zlevní výrobu návrhů, ale nechá člověka ručně třídit všechny jejich požadavky, vyrobili jsme si rychlejší frontu. Ne nutně lepší vývoj.
V seznamu nemá být to, na čem právě pracuje stroj
Factory soustřeďuje úkoly, změny kódu, jejich revize a stav automatických kontrol. Agent sem přináší žádost o schválení, rozhodnutí nebo přístup a požadavek dostane člověk, který o něm má rozhodnout. Zásadní pravidlo zní obyčejně: v mém seznamu má být jen to, kde je další krok na mně. Ne to, kde zrovna něco dělá můj agent.
Tohle rozlišení stojí za víc než další panel s animovanými pracovníky. Přehled všech běžících úloh může uklidňovat, ale také z člověka udělat hlídače cizího průběhu. Když systém sám ví, že čeká na dokončení testu, nemá důvod chtít, abych čekání sledoval i já. Moje pozornost má cenu až ve chvíli, kdy je potřeba volba, kterou za mě nemůže nebo nesmí udělat.
Jak jsme popsali v rychlé zprávě o Tracelight Factory, tým chce požadavky soustředit na jedno místo. Blog přitom rozlišuje současný stav od dalšího cíle: práce má moci začít třeba ve Slacku nebo desktopové aplikaci Claude, ale potřebné rozhodnutí se má vrátit do Factory. Nejde o oznámení hotového univerzálního systému pro všechny firmy.
Přenosný je tu hlavně pracovní princip. Člověk by neměl procházet několik chatů, aby zjistil, zda některý z nich náhodou potřebuje jeho souhlas. Požadavek má přijít s důvodem, podklady a jasným adresátem. Centralizovat jen upozornění nestačí: společný inbox plný neurčitých vět „podívej se na to“ by přesunul nepořádek, nikoli ho odstranil.
Když každý dostane svého agenta, tým ještě nevznikne
Tracelight píše, že už převážně komunikuje s koordinátory, pod nimiž pracují další agenti. Zároveň uvažuje o společném koordinátorovi pro celý tým. To druhé je směr dalšího vývoje, nikoli potvrzený konečný stav. Důvod je konkrétní: jeden agent může vlastnit určitou oblast kódu, zatímco jiný upravuje a udržuje něčí rozpracované změny. Jejich práce se začne překrývat.
Tady získává orchestrace více agentů praktický význam. Nestačí rozdělit zadání a sledovat, jak všichni vyrábějí výstupy. Někdo musí vědět, že dvě úlohy mění tutéž věc, že jedna čeká na druhou a že dvě zdánlivě rozumná rozhodnutí si navzájem odporují. Koordinátor proto nemá být jen pohodlnější hlas skupiny. Potřebuje společný přehled o závazcích.
Tým zkouší sdílený repozitář agent-space, kam si agenti ukládají poznatky. Autor ho označuje za slibný experiment, nikoli za vyřešenou paměť celého podniku. Související otázku jsme rozebírali u předávání rozpracované práce mezi relacemi Claude Code: poznámka musí odlišit, co se mělo stát, co se spustilo a co je skutečně potvrzené. Sdílet nepřesné shrnutí rychleji není pokrok.
Představme si dvě souběžné změny účtování. Každá zvlášť projde testy, protože každá vznikla proti jinému předpokladu o datech. Problém není v tom, že by agenti málo psali nebo že by chyběl další chat. Chybí dohoda o společném stavu. Proto bych při zavádění podobného systému řešil nejdřív vlastnictví změn a předávání výsledků, až potom počet souběžných pracovníků.
Méně razítek může dávat smysl. Méně odpovědnosti ne
Nejprovokativnější část blogu se týká kontroly kódu. Tracelight nechce, aby druhý inženýr mechanicky potvrzoval každou změnu. Člověka zapojuje u kritických částí, které vybírá kombinací pevných pravidel a úsudku agentů; za změnu zatím ručí inženýr, který ji zadal. Autor také popisuje přímé zápisy do hlavní větve, když to tým považuje za vhodné, například při opravě rozbitých automatických kontrol.
Argument proti plošným razítkům je rozumný. Oprava překlepu a změna databázové struktury nepotřebují stejnou hloubku pozornosti. Plošná povinnost může vytvořit dojem bezpečí, zatímco zkušený člověk ve skutečnosti jen odklikává frontu. Přesunout jeho čas k následkům případné chyby je lepší nápad než požadovat stejně obřadnou kontrolu všeho.
Jenže rozhodnutí, která změna je kritická, už samo patří k bezpečnostnímu problému. Pokud ji agent označí za nenápadnou, ale přehlédne dopad na oprávnění, žádný elegantní seznam úkolů tento omyl neopraví. Tracelight tvrdí, že zatím nepozoruje vyšší četnost incidentů ani návratů změn. V přečteném blogu ale neuvádí číselnou řadu, délku srovnávacího období ani metodiku, ze které by šlo odvodit prokázanou bezpečnost nového postupu.
Také tvrzení autora, že agenti hledají chyby lépe než lidé, berme jako názor týmu, ne jako obecný výsledek testování. Podobné napětí jsme řešili u pravidel ZAP pro odpovědnost za AI kód. Tam je důraz na porozumění předkladatele, tady na jiné rozdělení kontrolní pozornosti. Obojí stojí na tom, že někdo umí změnu obhájit a nese důsledky, když obhajoba neobstojí.
Trojnásobek změn ještě není trojnásobek užitku
Počet sloučených změn je snadno viditelné číslo. Neříká ale sám o sobě, kolik zákaznických problémů tým vyřešil, jak velké jednotlivé úpravy byly ani kolik následné údržby přinesou. Stejnou práci lze rozdělit do více menších požadavků; nové tempo zase může umožnit dělat věci, které se dřív odkládaly. Bez dalších údajů nevíme, jak se tyto vlivy na výsledku podílely.
Ani ekonomika není uzavřená. Misztal píše, že tým stále hledá vhodné řešení v rámci předplatných a že při cenách API by byl takový roj velmi drahý. Blog nepředkládá účet, ze kterého bychom mohli spočítat cenu hotové funkce. Firma navíc sama připouští obtížnou slučitelnost svého postupu s požadavky compliance. Není tedy poctivé z její zkušenosti udělat univerzální návod pro banku nebo zdravotnický systém.
Kdybych podobný postup zaváděl v malém týmu, chtěl bych vedle počtu změn sledovat tři věci: jak dlouho trvá vyřešit skutečný uživatelský problém, kolik lidského času spolknou rozhodnutí a opravy a co celé dokončení stojí. U rizikových zásahů bych navíc trval na předem určené odpovědnosti a cestě k nápravě. To je naše redakční doporučení, nikoli metodika, kterou Tracelight v blogu ověřilo.
Nejlepší myšlenka Factory není „přestaňme kontrolovat kód“. Je to požadavek přestat používat člověka jako ruční spojku mezi nástroji. Automatizace, která mu každou chvíli přihraje další organizační drobnost, si část vlastní práce pouze odložila do jeho hlavy. Dobrý systém po něm chce méně rozhodnutí, zato lépe připravených. Právě v tom bych hledal pokrok dřív než v dalším rekordním počtu sloučených změn.
