Programovací agent nemusí skončit u jedné opravené funkce nebo připraveného návrhu změny. Na DevDay 2026 představilo OpenAI nasazení Codexu, které po šest týdnů pomáhalo udržovat průběžnou integraci v chodu. Agent vyšetřoval nestabilní testy, připravoval opravy, komunikoval s kolegy a koordinoval další agenty. Celý běh přesáhl 1 000 hodin.
Za nejdůležitější na této zprávě nepovažuji samotnou délku provozu. Podstatnější je změna způsobu zadávání práce. Místo podrobného seznamu kroků dostává agent požadovaný výsledek, pravidla, prostředky k ověření a hranice, za kterými má přizvat člověka.
Ukázky přitom nezůstaly jen u údržby softwaru. Codex s Astrou pomáhal vytvořit interaktivní model Ferrari i virtuální průlet Nürburgringem. Od těchto kreativních projektů vede překvapivě přímá cesta k praktické otázce: jak svěřit agentovi dlouhodobou práci, aniž by člověk musel nepřetržitě stát vedle něj?
Obsah
- 🏎️ Od sedmi fotografií k interaktivnímu Ferrari
- 🛣️ Nürburgring ukázal význam vytrvalosti i obnovy práce
- 🎯 Méně předepsaných kroků, přesněji definovaný výsledek
- 🧪 Šest týdnů oprav nestabilních testů
- 👥 Zlom přineslo oddělení koordinace od vyšetřování
- 📊 Co agent za více než 1 000 hodin skutečně udělal
- 🔍 Obtížná chyba GPU vyžadovala i spolupráci s výzkumníky
- 🛡️ Zelené testy nestačí, pokud se ztratí jejich smysl
- 🧵 Jedno vlákno pro jeden výsledek, poznámky pro kontinuitu
- ☁️ Dlouhá práce potřebuje odpovídající prostředí
- 🔌 Pluginy dodávají kontext, který v repozitáři chybí
- 🌳 Podvlákna, pracovní stromy a režim ultra řeší různé problémy
- ⏱️ Plánované návraty promění čekání v pracovní postup
- 💰 Kolik stálo šest týdnů provozu
- 🚀 Jak vybrat první práci pro dlouhodobého agenta
🏎️ Od sedmi fotografií k interaktivnímu Ferrari
První příklad začal zájmem o Formuli 1 a snahou lépe porozumět tomu, z jakých součástí se závodní vůz skládá. Zadání bylo srozumitelné: vytvořit Ferrari ve 3D a web, na kterém bude možné model prozkoumávat.
Codex s Astrou běžel na vzdáleném počítači. Jako vizuální podklady dostal sedm fotografií a během několika dnů postupného dolaďování vznikl výsledný model. Nešlo tedy o okamžitý výstup z jediného požadavku, ale o spolupráci, při níž se podoba vozu postupně zpřesňovala.
Zajímavý byl rozsah výsledku. Vedle běžného zobrazení agent bez výslovného požadavku připravil také jednolitý model připomínající hlínu a drátěnou reprezentaci geometrie. Tyto varianty nabídly různé pohledy na stejný objekt.
Vidím v tom dobrý příklad rozdílu mezi zadáním postupu a zadáním účelu. Požadavek nespočíval pouze ve vytvoření obrázku auta. Cílem bylo umožnit jeho zkoumání. Různé režimy zobrazení do tohoto účelu přirozeně zapadaly.
Zároveň bych výsledek nepovažoval za důkaz technicky přesné rekonstrukce skutečného monopostu. Prezentace popsala tvorbu vizuálního modelu z fotografických podkladů, nikoli ověřenou konstrukční dokumentaci. Pro pochopení možností agentů je však důležitý už samotný souběh modelování, práce s podklady a přípravy webového rozhraní.
🛣️ Nürburgring ukázal význam vytrvalosti i obnovy práce
Druhý projekt posunul zadání dál. Codex dostal název Nürburgring a úkol vytvořit virtuální průlet. Sám vyhledával reference a zvolil delší variantu Nordschleife namísto kratšího okruhu Grand Prix.
Prezentovaný průlet zachycoval přibližně 21 kilometrů a všech 70 zatáček uváděných v ukázce. Rozsahem tak šlo zhruba o trojnásobek běžného okruhu Formule 1. Výsledná animace nebyla převzatým záznamem skutečné jízdy, ale nově vytvořeným výstupem.
Práce trvala o něco déle než dva dny. Velkou část času přitom nezabralo rozhodování modelu, nýbrž renderování v Blenderu. Codex využíval pomocné agenty k průzkumu trati, kontrole geometrie a plánování renderu.
Provoz narušovaly problémy s operační pamětí i přehříváním procesoru. Právě tady se podle mě ukázala důležitější schopnost než samotné vytvoření působivé scény: agent dokázal navázat na uložené snímky a pokračovat, místo aby po každém přerušení začínal znovu.
Dlouhodobá autonomie totiž neznamená, že se nic nepokazí. Znamená také schopnost rozpoznat stav rozpracované úlohy, zachovat už hotové výsledky a správně obnovit další kroky. U náročného renderování je tento rozdíl velmi konkrétní a snadno pochopitelný.
🎯 Méně předepsaných kroků, přesněji definovaný výsledek
OpenAI na těchto příkladech ilustrovalo posun proti předchozímu DevDay. Tehdy byl výrazným výsledkem agent pracující sedm hodin. Pro delší úlohy sloužily podrobné realizační plány označované jako exec plans.
Původní zadání obsahovala rozsáhlé pokyny, ukázky kódu, doporučené knihovny a postup implementace. Následovalo sestavení plánu a jeho společné upřesňování, než agent začal skutečně pracovat.
Nově představený přístup staví více na cíli a rozhodovacích kritériích. Člověk popíše požadovaný výsledek, priority, přijatelné kompromisy a způsob poznání, že je práce dostatečně kvalitní. Rozdělení konkrétních kroků pak ve větší míře přenechá agentovi.
Nepovažuji to za výzvu psát neurčitá zadání. Právě naopak. Když odpadne detailní řízení postupu, roste důležitost přesného vymezení výsledku. Požadavek na opravu testů musí být doplněn pravidly, podle kterých lze poznat skutečnou opravu a odlišit ji od pouhého odstranění nepohodlného testu.
Rozdíl bych shrnul jednoduše: člověk nemusí dopředu znát celou cestu, ale měl by umět popsat cíl, omezení a důkazy úspěchu. To je základ, na kterém mohou dlouhodobě běžící programovací agenti stavět.
🧪 Šest týdnů oprav nestabilních testů
Nejrozsáhlejší praktický příklad se týkal průběžné integrace, tedy CI. Ta automaticky spouští testy změn a pomáhá rozhodnout, zda lze kód začlenit a vydat. Problém nastává, když stejný test jednou selže a podruhé projde, přestože se relevantní kód nezměnil.
Takovým testům se říká nestabilní nebo nedeterministické. Jejich vyšetřování může zabrat hodiny i dny. Mezitím přicházejí další selhání a tým opakovaně zjišťuje, zda narazil na chybu produktu, problém infrastruktury, nebo nespolehlivý test. Širší souvislosti dobře vysvětluje také rozbor nedeterminismu v automatizovaných testech od Martina Fowlera.
Agent nasazený v OpenAI tuto opakující se práci převzal na šest týdnů. Ukončení podle prezentace nebylo důsledkem nefunkčnosti. Kolegové už začali spouštět vlastní agenty pro stejný typ úloh.
Výchozí zadání mělo pouze přibližně 200 slov. Obsahovalo pravidla práce s repozitářem, komunikace s kolegy a hospodárného využívání CI. Nepředepisovalo konkrétní opravy ani nevkládalo ukázky implementace. Agent si měl zjistit, jak testy a celou sadu spouštět.
Za podstatné považuji právě spojení úzkého účelu a široké provozní samostatnosti. Agent neměl obecně vylepšovat všechno. Měl průběžně řešit jasně vymezenou kategorii problémů s dostupnou zpětnou vazbou.
👥 Zlom přineslo oddělení koordinace od vyšetřování
Běh začal s modelem označeným 5.6 Sol. Zpočátku agent vyšetřoval selhání i připravoval opravy v jediném vlákně. To fungovalo, ale vytvářelo známé úzké hrdlo: obtížná chyba ho mohla na dlouhou dobu pohltit, zatímco další problémy přibývaly.
Přibližně po čtyřech dnech dostal pokyn více delegovat. Hlavní vlákno se následně soustředilo na spouštění testů, sběr informací, organizování pomocných agentů a komunikaci s lidmi.
Pomocní agenti převzali pomalejší práci na jednotlivých případech. Stahovali kód, reprodukovali konkrétní selhání, připravovali změny, odesílali je do CI a podle výsledků pokračovali v dalších úpravách.
Tady podle mě leží jeden z nejpřenositelnějších poznatků celé prezentace. Pokud stejná pracovní smyčka zároveň přijímá nové události a do hloubky vyšetřuje jeden problém, snadno přestane zvládat příchozí práci. Oddělení koordinace od řešení jednotlivých případů umožní pokračovat i během několikadenního ladění.
Role člověka se tím znovu mění. Nestačí přidělovat úkoly jednotlivým agentům. Důležité je určit, jak má hlavní agent práci rozdělovat, co má sledovat a kdy má upozornit na situaci vyžadující lidské rozhodnutí.
📊 Co agent za více než 1 000 hodin skutečně udělal
OpenAI uvedlo několik konkrétních výsledků šestitýdenního běhu. Beru je jako údaje z popsaného interního nasazení, nikoli jako garantovaný výkon pro libovolný tým nebo repozitář.
- Každý týden agent otevřel více než 100 návrhů změn, tedy pull requestů.
- Za celý běh vytvořil více než 1 000 commitů.
- Kolegům poslal přes 600 zpráv ve Slacku kvůli koordinaci oprav.
- Začlenil více než 213 vlastních oprav.
- Provedl necelého půl milionu volání nástrojů.
- Využil více než 5 800 relací pomocných agentů.
- Přes 67 000 volání souviselo s čekáním na další události nebo výsledky.
Rozdíl mezi počtem otevřených návrhů a začleněných oprav neznamená automaticky neúspěch. Agent v některých případech zjistil, že podobné řešení už připravil někdo jiný, a upřednostnil existující práci.
Právě to považuji za důležitý organizační detail. V týmovém prostředí není cílem maximalizovat počet vlastních změn, ale posouvat společnou práci. Vyhnout se duplicitě může být hodnotnější než za každou cenu dokončit vlastní návrh.
Také vysoký počet čekacích kroků připomíná realitu vývoje. Dlouhý běh není tisíc hodin nepřetržitého psaní kódu. Zahrnuje testování, čekání na infrastrukturu, vyhodnocování výsledků a navazování na reakce ostatních.
🔍 Obtížná chyba GPU vyžadovala i spolupráci s výzkumníky
Jako příklad náročného případu zazněla nedeterministická chyba ve výpočtech s plovoucí řádovou čárkou v jednom GPU testu. Nešlo o závadu, kterou by bylo snadné pokaždé zopakovat stejným postupem.
Agent porovnával záznamy z několika týdnů a našel souvislost s konkrétním výpočetním uzlem. Potom si zjistil, jak test na tomto uzlu opakovaně spouštět. Selhání dokázal reprodukovat, ale pouze občas.
Vyšetřování zabralo pomocnému agentovi několik dnů. Následně kontaktoval výzkumníky odpovědné za daný systém, popsal zjištěné chování a začal s nimi ověřovat možné příčiny.
Otázky se týkaly například softwarové optimalizace, která nemusela být patrná z repozitáře, nebo možné hardwarové závady GPU. Prezentace neupřesnila konečnou technickou příčinu, proto bych ji nedoplňoval domněnkou. Uvedla však, že se problém podařilo vyřešit.
Pro mě je na tomto případu zásadní rozpoznání hranice dostupných informací. Samostatnost neznamenala uzavřít se do nekonečného experimentování. Agent dokázal připravit konkrétní podklady a oslovit lidi, kteří měli potřebný kontext mimo kód a logy.
🛡️ Zelené testy nestačí, pokud se ztratí jejich smysl
Nejjednodušší způsob, jak odstranit červený výsledek testu, může být test smazat. Někdy je odstranění skutečně správné, ale samotný úspěšný průchod CI to nedokazuje.
V popsaném nasazení agent při nejistotě někdy vytvořil dalšího agenta, který přezkoumal navrženou změnu. Teprve poté předal výsledek člověku ke kontrole. Tím přidal další kontrolní krok před lidské posouzení, nikoli náhradu lidské odpovědnosti.
Rozlišuji proto dvě různé otázky: zda změna prošla testy a zda je změna věcně správná. U oprav testovací infrastruktury jsou obě důležité, protože nevhodná oprava může zdánlivě zlepšit metriku a současně zhoršit schopnost zachytit chyby.
Také závěrečná retrospektiva přinesla zajímavost. Agent označil za své nejproduktivnější období pět dnů, během kterých nedostal žádnou zprávu od svého zadavatele. Nevyvozuji z toho, že lidský dohled škodí. Spíš v tom vidím připomínku, že dohled nemusí znamenat neustálé přerušování.
Podle prezentace toto nasazení uvolnilo stovky hodin lidského času, které mohly směřovat ke škálování infrastruktury. Přínos tedy nespočíval pouze v opravených testech, ale i v menším množství opakovaného vyrušování.
🧵 Jedno vlákno pro jeden výsledek, poznámky pro kontinuitu
První doporučení pro dlouhodobé úlohy zní jednoduše: jednomu požadovanému výsledku přiřadit jedno hlavní vlákno. V něm zůstává zadání, plánování, průběžné kontroly i případné změny směru.
U CI může být výsledkem průběžné sledování selhání, jejich reprodukce a příprava návrhů oprav k lidskému posouzení. Testy pak poskytují prostředek, kterým agent kontroluje vlastní postup. Prezentace zmínila také příkaz /goal pro soustavné sledování zadaného cíle.
Doplňující pravidla patří do souboru AGENTS.md. Ten může zachycovat strukturu projektu, umístění testů, doporučené postupy i zakázané zásahy. Další souvislosti nabízí oficiální dokumentace Codexu.
Za zvlášť užitečné považuji doporučení vést pracovní záznam. Agent by si měl poznamenávat, co už provedl a co ještě potřebuje prozkoumat. Takové poznámky pomáhají obnovit práci po přerušení a zachovat stav rozpracovaného problému.
Dlouhý kontext doplňuje vestavěná kompakce, která průběžně zhušťuje historii. V prezentaci zazněly zkušenosti i s vlákny používanými po tři měsíce. Chápu to jako popis praktické kontinuity, nikoli důkaz, že libovolně dlouhá konverzace nemůže nikdy ztratit důležitý detail. Pracovní poznámky a jasné cíle proto dávají smysl i vedle automatické kompakce.
☁️ Dlouhá práce potřebuje odpovídající prostředí
Šestitýdenní provoz na notebooku není příliš pohodlný model. Dlouhodobě běžící agent potřebuje dostupné soubory, nástroje a výpočetní prostředky i ve chvíli, kdy člověk svůj počítač odpojí.
Prezentace popsala připojení vzdálených strojů přes SSH a přístup k práci z desktopového, mobilního i webového rozhraní. Vlákno pak pracuje nad prostředím obsahujícím repozitáře, projektové soubory a potřebné nástroje.
U Nürburgringu posloužil vývojový server s Blenderem, relevantními soubory a přístupem k vyhledávání na webu. Agent tedy nemusel vytvářet výsledek pouze z informací obsažených v zadání. Měl prostředky k dohledávání podkladů i realizaci renderu.
OpenAI zároveň představilo vylepšené prostředí Codex Cloud se spravovaným virtuálním strojem. Popsané možnosti zahrnovaly snímkování prostředí pro pozdější návrat, pravidelnou obnovu pracovní kopie kódu a závislostí i využití pluginů.
Rozhodování bych proto nezačínal pouze volbou modelu. Stejně důležitá je otázka, kde bude agent pracovat a co tam bude mít k dispozici. Pokud chybí testovací nástroje, potřebné soubory nebo přístup k výsledkům, samotná vytrvalost modelu tuto mezeru nevyřeší.
🔌 Pluginy dodávají kontext, který v repozitáři chybí
Selhávající test může mít vlastní záznam v systému úkolů. Někdo už ho možná vyšetřuje a další kolega mezitím připravil opravu. Část této informace bývá v GitHubu, část ve Slacku nebo v Linearu.
Agent bez tohoto kontextu může technicky pracovat správně, a přesto plýtvat časem. Znovu objeví známý problém, vytvoří duplicitní návrh nebo přehlédne rozhodnutí, které už tým učinil.
Pluginy mají Codexu zpřístupnit právě tyto souvislosti. V prezentaci zaznělo propojení s GitHubem, Linearem a dalšími pracovními nástroji, aby agent mohl hledat úkoly, diskuse a návrhy změn.
Za podstatné považuji, že tato propojení neslouží jen k odesílání oznámení. Jejich hodnota spočívá také ve čtení a pochopení stavu společné práce. To vysvětluje, proč agent v některých případech upřednostnil opravu jiného kolegy před vlastní.
Vhodně propojený agent tedy neřeší pouze otázku, co lze změnit v kódu. Zjišťuje také, zda má změna v daném okamžiku smysl, kdo se jí zabývá a co je potřeba koordinovat. U dlouhodobých úloh je tento organizační kontext stejně praktický jako přístup k testům.
🌳 Podvlákna, pracovní stromy a režim ultra řeší různé problémy
Ne každou velkou úlohu je vhodné řešit sériově. U projektu Ferrari mohlo modelování v Blenderu probíhat souběžně s tvorbou webu. Hlavní vlákno přitom drželo společný cíl a podvlákna dostala samostatné části práce.
Jednotlivá podvlákna lze samostatně otevřít, usměrnit nebo zastavit. V repozitáři Git mohou využívat vlastní pracovní stromy, tedy worktrees. Každý má oddělenou pracovní kopii, takže souběžné úpravy neprobíhají nad stejnými soubory v jednom adresáři. Princip podrobně popisuje dokumentace příkazu git worktree.
Toto oddělení podle mě pomáhá organizaci práce, ale neznamená automatické odstranění všech konfliktů při pozdějším slučování. Stále záleží na tom, jak spolu jednotlivé změny souvisejí.
Pro konzultaci bez zásahu do hlavního běhu slouží příkaz /side. Vytvoří vedlejší vlákno s převzatým kontextem, ve kterém lze klást otázky a nezměnit tím směr hlavní úlohy.
Jinou roli má režim ultra. Ten dává modelu více prostoru k uvažování nad obtížným problémem a může organizovat pomocné agenty kolem různých hypotéz či pokusů o opravu.
Praktické rozlišení je užitečné: nezávislé části práce rozdělit, jeden mimořádně těžký problém zkoumat do větší hloubky. Přidávání dalších vláken samo o sobě nemusí vyřešit situaci, ve které chybí porozumění příčině.
⏱️ Plánované návraty promění čekání v pracovní postup
Část dlouhodobé práce závisí na událostech mimo kontrolu agenta. Návrh změny čeká na posouzení, test ještě běží nebo se teprve objeví zpětná vazba. Agent nemusí takovou situaci řešit neustálým připomínáním kolegům.
Prezentovaný heartbeat je plánovaný návrat do stejného vlákna. Agent například každou půlhodinu zkontroluje, zda přišlo hodnocení návrhu změny, a případné připomínky zpracuje s dosavadním kontextem.
Od toho se liší pravidelně spouštěná nová úloha. Ta může každé ráno shrnout noční dění v projektu nebo jednou týdně připravit přehled vybraných projektů. Frekvence a zadání se nastaví jako plánovaná práce.
Toto rozlišení považuji za důležité pro návrh celého procesu. Pokračování existující opravy potřebuje zachovat historii a rozpracovaný stav. Opakovaný přehled naproti tomu může pokaždé vytvořit nový, samostatný výstup.
Dlouhodobý agent tak nemusí nepřetržitě intenzivně počítat. Může pracovat, uložit stav, počkat a ve vhodný okamžik znovu vyhodnotit situaci. Právě střídání aktivity a čekání vysvětluje část více než tisícihodinového běhu lépe než představa nepřetržitého generování kódu.
💰 Kolik stálo šest týdnů provozu
Podle cenového přepočtu uvedeného OpenAI vycházel popsaný běh přibližně na 32 dolarů za hodinu. S modelem GPT-6 Sol měla srovnatelná cena podle prezentace klesnout přibližně na 16 dolarů za hodinu. U 6.1 Sol zazněla další zlepšení efektivity využití tokenů a konkurenceschopnost vůči Astře.
Tyto částky bych nepoužíval jako univerzální ceník dlouhodobého agenta. Vztahovaly se ke konkrétnímu nasazení napříč systémy OpenAI, v němž pracovní smyčka opakovaně spouštěla rozsáhlé testování. Pro představu o řádu nákladů jsou užitečné, pro vlastní rozpočet však nestačí.
Výslovně zaznělo také to, že náklady nekončí u modelu. Patří k nim kontrola kódu, zdroje CI a další provozní položky. Levnější tokeny proto automaticky neznamenají stejně velké snížení celkových nákladů.
Při hodnocení návratnosti bych sledoval několik věcí současně:
- Kolik skutečně použitelných oprav agent dokončí.
- Kolik lidské kontroly jeho výstupy vyžadují.
- Jaké výpočetní prostředky spotřebuje testování.
- Kolik duplicitní práce se podaří předejít.
- Jakou práci může tým díky uvolněnému času dokončit místo opakovaného vyšetřování.
Důležitým limitem může být vedle peněz také počet současně běžících CI úloh. Rozpočet tak zahrnuje nejen tokeny, ale i kapacitu sdílené infrastruktury.
🚀 Jak vybrat první práci pro dlouhodobého agenta
Z prezentovaných zkušeností si odnáším poměrně konkrétní postup. Nezačínal bych největším projektem, který mě napadne, ale opakovanou činností, která bere čas a má ověřitelný výsledek.
- Vybrat opakující se problém. Vhodným kandidátem může být údržba CI, zpracování chybových záznamů nebo příprava návrhů změn z existujícího seznamu úkolů.
- Zajistit zpětnou vazbu. Agent potřebuje testy nebo jiný dostupný způsob, jak ověřit, zda se přiblížil správnému výsledku.
- Popsat cíl a kompromisy. Zadání má vysvětlit, co je důležité a co není přijatelnou zkratkou.
- Vymezit delegování. Nezávislé problémy lze rozdělit mezi pomocné agenty, zatímco koordinace zůstane v hlavním vlákně.
- Stanovit eskalaci. Musí být jasné, kdy má agent oslovit zadavatele, odpovědný tým nebo pohotovostní službu.
- Omezit spotřebu. Součástí pravidel má být rozpočet a případně počet paralelních testovacích úloh.
Za rozhodující podmínku považuji možnost uzavřít pracovní smyčku: zjistit problém, provést změnu, ověřit výsledek a podle něj pokračovat. Bez tohoto propojení může agent dlouho působit aktivně, aniž by bylo jasné, zda přináší hodnotu.
Hlavní zprávu DevDay 2026 proto nečtu jako příslib vývoje bez lidí. Vidím v ní posun k průběžně delegované práci, kterou drží pohromadě cíle, testy, pracovní záznamy, dostupné nástroje a pravidla lidského zásahu. Nejzajímavější otázkou už není pouze to, jak dlouho agent vydrží pracovat, ale kterou ověřitelnou odpovědnost mu má smysl svěřit.
