Subscribe Now
Trending News
Deep Dives

Yeggeho Wheelhouse: když se vývojář stane dispečerem

Yeggeho Wheelhouse: když se vývojář stane dispečerem

Steve Yegge tvrdí, že za jeden červenec nechal AI pro svou hru spolknout 69 miliard tokenů. V přepočtu na rozhraní API by prý šlo o 87 tisíc dolarů měsíčně; vlastní účet popisuje jako asi 2 800 dolarů díky sadě placených účtů. I kdybychom čísla brali jen jako autorovo svědectví, měřítko je jasné: nejde o člověka, který si občas nechá doplnit funkci v editoru.

V eseji The Shape of Things to Come Yegge popisuje Wheelhouse, interní orchestrátor pro vývoj online hry Wyvern. Z něj vyrostl pracovní systém s trvalou pamětí, frontami práce, specializovanými rolemi a dohledem nad produkcí. AI zde nepíše kód po jednom zadání. Má pracovat, zatímco autor spí.

Tohle není hotový vzor pro každý tým. Je to terénní zápis z místa, kde generování kódu přestalo být hlavním problémem. Pomalé jsou návrh práce, předání kontextu, ověření výsledku a rozhodnutí, co se vůbec má dostat k uživatelům.

Projekt není framework, ale návrat ke staré hře

Wyvern je dlouhověká multiplayerová hra, na níž Yegge začal pracovat v roce 1996 a v roce 2001 ji spustil. V roce 2026 ji označuje za bitrotten, přesto stále běžící produkt s platícími hráči. Popisuje také migraci z Jythona do Kotlinu, vlastní protokol a třicet let vrstveného kódu. Právě takový systém je pro agenty podstatně těžší než čistý nový projekt: nestačí vygenerovat komponentu, je nutné pochopit místní pravidla a nerozbít hráčům živou hru. Yeggeho esej

Wheelhouse vznikal v době psaní textu asi šest týdnů. Je uzavřený a určený výhradně pro Wyvern. Yegge se tím vědomě vzdává dřívější ambice prodávat obecný harness: tvrdí, že taková vrstva musí být propojená s konkrétní aplikací, jejími pravidly a provozem.

V tom je méně mystiky, než zní v autorově rétorice. Nástroj Beads, na němž Wheelhouse stojí, se sám popisuje jako paměťové rozšíření pro programovacího agenta. Ve Wyvernu slouží jako graf úkolů: uchovává závislosti, převzetí práce, její historii i nálezy vázané na konkrétní problém. Vedle něj leží zhruba stovka souborů Markdownu se strategií, dlouhodobými rozhodnutími a postupy.

Paměť tu není příloha promptu. Je to součást provozu.

Podobný princip popisuje i OpenAI ve studii o interním agentním vývoji: stručný AGENTS.md používá jako rozcestník a zdrojem pravdy jsou strukturované dokumenty v repozitáři. Autoři uvádějí, že jeden velký manuál rychle zastarával a zabíral agentovi kontext pro skutečný úkol. Shoda s Wheelhousem není důkaz, že Beads je nutná volba. Podporuje však obecnější tezi: při delší autonomní práci musí být projektová znalost dohledatelná, verzovaná a dávkovaná podle úkolu.

Co se Yeggemu rozbilo

Před Wheelhousem měl Yegge Gas Town, svůj předchozí systém pro řízení agentů. Podle jeho popisu vyžadoval příliš mnoho ruční péče a agenti v něm nevydrželi samostatně pracovat přes noc. Finální problém připisuje modelu Claude Opus 4.7: model se opakovaně vracel k vylepšování samotného Gas Townu místo toho, aby uzavíral práci. Je to cenný detail, protože ukazuje křehkost orchestrace vůči změně modelu. Pracovní postup, který vypadá stabilně, může rozkolísat i nová naučená zvyklost asistenta.

Další potíž přišla s propustností. Yegge píše o průměru 175 „skutečných“ commitů denně a o build gate trvající půl hodiny. Jeho merge queue proto narostla přes stovku změn. Běžné dávkování a půlení vadné dávky stále spotřebovávalo čas na další buildy, zatímco agenti přidávali další práci.

Tady autor nabízí nejvýbušnější závěr: starý CI/CD model má v agentním tempu zemřít. Jeho odpověď nazvaná Land Rush je hromadně sloučit změny do hlavní větve a nechat roj agentů rychle najít a opravit důvod, proč je větev červená.

Matematická intuice je správná: pokud přibývá změn rychleji, než je dokáže ověřit omezený počet buildů, fronta roste. Z toho ale neplyne, že každý tým má vyřadit pořadí, izolaci změn a možnost vrátit nasazení. Yegge sám mluví o specifickém systému, vysokém počtu agentů a hře, jejíž změny lze řídit jinak než třeba bankovní platby. Jeho „Thunderdome“ je experimentální strategie obnovy při přetížení, ne obecné pravidlo pro produkci.

AI nepomohla jedním modelem, ale dělbou práce

Nejzajímavější část Wheelhouse není počet oken ani počet tokenů. Je to rozdělení odpovědnosti.

Yegge má osmnáct „crew“ agentů, s nimiž vede delší rozhovory. Ti rozpracují návrh a převedou jej na implementační úkoly v Beads. Druhou vrstvu tvoří agenti „fleet“, kteří úkoly provádějí ve vlastních klonech repozitáře. V popsaném toku návrhový model Fable navrhuje, model Opus implementuje a Fable jeho práci znovu kontroluje. Nad nimi stojí role Marshal, která řídí flotilu, a Seneschal pro vzdálené ovládání a komunikaci.

To přenáší lidskou práci o patro výš. Yegge neurčuje každý řádek; rozhoduje, kam investovat pozornost, co má systém zkusit, které návrhy přijmout a kdy zvolnit. Uživatelé Wyvernu dokonce požádali o roadmapu, protože změny přicházely příliš rychle. Autor proto uvádí, že se více věnuje kvalitě než dalším funkcím.

Vedle vývoje vytvořil i trvalé produkční role: agenty pro QA, správu herních obrázků, patch notes, triáž a opravy. Spouštěče jsou obyčejné služby a plánovače; Yegge to shrnuje přímo: hlídání podmínek obstarává deterministický kód, model má zasahovat až tam, kde je potřeba úsudek. To je zřejmě přenositelnější poznatek než konkrétní názvy jeho agentů. Nenechávejte jazykový model čekat na prázdno a nedávejte mu úkol, který přesněji vyřeší pravidlo.

Review nezmizí, mění místo i podobu

Yegge předpovídá konec lidského code review. OpenAI už ukazuje příbuzný, avšak opatrnější model: v jejich agentním projektu se pull request iteruje přes vlastní kontrolu agenta a další specializované agentní review; člověk změnu může projít, ale nemusí. Autoři zároveň přiznávají, že při vyšší propustnosti narazili na kapacitu lidského QA. OpenAI

To podporuje posun, ne absolutní verdikt. Review se může přesouvat z ručního čtení každého diffu k návrhu, pravidlům, testovacím signálům, pozorovatelnosti a výjimkám s velkým dopadem. Člověk dál nese odpovědnost za účel změny a za hranici přijatelného rizika. Agent může opakovaně ověřit pravidlo, ale neumí sám rozhodnout, zda je změna dobrá pro produkt a jeho uživatele.

Výzkumný program DORA popisuje stejný tlak bez Yeggeho apokalypsy. Podle analýzy odpovědí 1 110 vývojářů Google AI zrychluje vznik kódu, ale ušetřený čas se často spotřebuje na audit a ověření. Vyšší adopce byla spojena současně s vyšší propustností i vyšší nestabilitou dodávky. DORA proto doporučuje vracet automatizovanou zpětnou vazbu autorovi co nejdřív, používat kontextové review agenty a držet malé, testovatelné dávky změn.

To je s Land Rushem v přímém rozporu. A správně: bez měření míry selhání, času obnovy a dopadu na zákazníky nemá smysl prohlašovat jednu strategii za budoucnost.

Budoucnost vývoje je výrobní tok, ne soutěž v počtu promptů

Z Wheelhouse se dají vyvodit čtyři střízlivé závěry. Zaprvé, zrychlení psaní kódu přesměruje úzké hrdlo k rozhodování a ověřování. Zadruhé, AI agenti potřebují malou vstupní mapu, dobře udržovanou znalostní základnu a práci rozdělenou podle závislostí. Zatřetí, spolehlivost vzniká ze zpětných vazeb: testů, metrik, logů a opravných smyček, které agenti umějí použít. A nakonec, každý tým musí kalibrovat autonomii podle následků chyby, ne podle nadšení z nové technologie.

Yeggeho projekt má omezení, která nejdou zamést pod koberec. Stojí na jednom mimořádně zkušeném vývojáři, na obrovském rozpočtu tokenů, na živém produktu s osobitými pravidly a na modelech, jejichž chování se může z měsíce na měsíc změnit. Jeho výsledky nejsou nezávisle ověřenou studií ani receptem pro regulovaný provoz.

Přesto je Wheelhouse dobrá předzvěst. Vývojář, který dnes mluví s agentem o jedné funkci, může zítra řídit síť pracovních toků. V té chvíli nebude nejcennější schopnost vypsat další prompt. Rozhodne, zda tým dokáže říct, co má být pravda, jak se to pozná a kdo smí změnit produkci, když odpověď není jednoznačná.

Zdroje

Related posts