Vývoj s umělou inteligencí přestává být jen soukromým rozhovorem programátora s nástrojem na generování kódu. Na DevDay 2026 se do popředí dostala jiná představa: trvalí AI agenti, kteří pracují se společným kontextem, zapojují celý tým a postupně přebírají opakující se vývojové úkoly. Součástí představeného směru bylo také oznámení otevření platformy OpenClaw Enterprise pro správu a zabezpečení agentů napříč organizací.
Za nejdůležitější posun považuji změnu samotného pracovního prostředí. Nejde pouze o rychlejší psaní funkcí. Jde o to, aby kolegové rozuměli zadání, mohli navázat na rozpracovanou práci a nemuseli veškerou komunikaci s agentem vést přes jednoho člověka.
Ukázky zahrnovaly společné úpravy hry, sdílené vývojové relace, přehledové panely, automatické opravy chyb i podnikové bezpečnostní hranice. Zároveň odkryly limity: nepřesné souhrny, pomalé testování, potřebu lidského úsudku a nepovedenou odpověď komunitního agenta. Právě tato kombinace ambicí a nedokonalostí podle mě nejlépe vystihuje současnou podobu agentního vývoje.
Obsah
- 💻 Od terminálu k prostředí pro celý tým
- 🤝 Člověk nemá být přeposílací službou pro AI
- 🦞 Společná hra ukázala jiný způsob předávání práce
- 🌐 Open source přináší volbu modelu i infrastruktury
- 🔎 Kód ukazuje změnu, konverzace vysvětluje důvod
- 🧩 Sdílený kontext může zabránit zbytečnému konfliktu
- 🏠 Týmový server jako společné pracovní místo
- 📊 Přehledy pomáhají, ale ne každý výstup je spolehlivý
- 🎙️ Porady mohou přecházet rovnou v novou práci
- 🏭 K softwarové továrně vede údržba samotných agentů
- 🔁 Smyčka průběžně hlídá, cíl směřuje k dokončení
- 🛡️ OpenClaw Enterprise přidává správu celé organizace
- 🔐 Čtyři bezpečnostní základy agentního provozu
- 🧑💼 Fred a Cooper ukázali dvě odlišné role
- 🚀 Otevřená infrastruktura, nikoli hotový konec vývoje
💻 Od terminálu k prostředí pro celý tým
První část setkání popsala proměnu práce během jediného roku. Peter začínal s vývojem převážně v terminálu, s rozdělenou obrazovkou a mnoha souběžnými relacemi. Agenty bylo potřeba často zastavovat a směrovat. Jak se modely zlepšovaly, těchto zásahů ubývalo a původní prostředí začalo být spíše omezením než výhodou.
Přechod na desktopové prostředí Codexu usnadnil spouštění většího počtu úloh, čtení konverzací a práci s vizuálními výstupy. Prohlížeč a náhledy výsledků přiblížily zadání skutečnému produktu. Místo pouhého sledování textového výstupu bylo možné rovnou posuzovat, co agent vytvořil.
Snazší souběžná práce však rychle narazila na výkon počítače. Docházelo místo na disku a stroje byly pod výraznou zátěží. Peter proto zapojil další počítače, vývojová prostředí Dev Boxes a vlastní nástroj Grabbox pro spouštění testů v cloudu. V nejvytíženějším období pracovalo na kódu a experimentech přibližně šest až deset strojů.
Podstatné pro mě je, že ani takové rozšíření infrastruktury nevyřešilo spolupráci. Výpočetní kapacita rostla, ale kolegové stále potřebovali Petera jako prostředníka. Tým používal agenty, přesto s nimi ještě nepracoval skutečně společně.
🤝 Člověk nemá být přeposílací službou pro AI
Pro tuto situaci zaznělo označení „meat proxy“, které Peter připsal Franku Elbymu. Popisuje člověka fungujícího jako rozhraní mezi ostatními lidmi a umělou inteligencí. Přijímá požadavky, předává je agentovi, získává odpovědi a posílá je zpět kolegům.
Takový způsob práce může být užitečný na začátku, ale vytváří úzké hrdlo. Ostatní nemají přímý přístup k rozhodování ani k průběhu úkolu. Pokud potřebují změnit zadání, zjistit důvod úpravy nebo pokračovat v experimentu, znovu žádají prostředníka.
Právě tady začaly experimenty s využíváním OpenClaw k vývoji samotného OpenClaw. Platforma byla představena jako open source prostředí pro trvalé agenty fungující napříč nástroji, zařízeními a týmy. Podporuje práci s vývojovými relacemi a zásuvnými moduly a umožňuje využít přihlášení prostřednictvím podporovaného předplatného.
Za hlavní otázku nepovažuji, kolik kódu agent napíše. Důležitější je, zda tým vidí, na čem pracuje, rozumí jeho rozhodnutím a dokáže do práce vstoupit. Sdílené prostředí se tak stává nástrojem koordinace, nikoli jen pohodlnějším oknem pro zadávání požadavků.
🦞 Společná hra ukázala jiný způsob předávání práce
Praktická ukázka začala jednoduchým požadavkem na hru podobnou Froggeru, ve které postava překonává silnici s auty. Agent našel existující variantu Lily Lane, kterou už připravil Kevin s týmem. Namísto vytváření dalšího izolovaného projektu bylo možné navázat na hotovou práci.
Následoval požadavek změnit žábu na humra. Výsledná hra pracovala s humry a žraloky. Současně vznikalo i zadání přehledového panelu věnovaného novinkám z DevDay 2026. Více úloh tak běželo vedle sebe a jejich výsledky byly dostupné ve společném prostoru.
Po otevření přístupu dalším účastníkům se ukázala základní vlastnost týmového serveru: lidé mohou vidět relace ostatních a mohou do nich sami zadávat pokyny. Není nutné čekat na hotový pull request, převzít jej do vlastního nástroje a teprve potom pokračovat.
Zároveň zaznělo důležité upozornění. Tento režim je určen týmům se stejnou úrovní přístupu a vzájemnou důvěrou. Do společného prostředí nepatří člověk, kterému nechcete umožnit zasahovat do rozpracovaných relací. Otevřenost zde není automaticky bezpečná. Je to záměrná pracovní dohoda mezi spolupracovníky.
Hravá ukázka podle mě vystihla vážnější změnu: jednotkou spolupráce už nemusí být jen dokončená změna kódu. Může jí být celá živá pracovní relace.
🌐 Open source přináší volbu modelu i infrastruktury
OpenClaw byl představen jako projekt vlastněný nezávislou neziskovou nadací OpenClaw Foundation, jehož poslání podporuje OpenAI. Peter současně popsal práci svého týmu v OpenAI na užitečných agentech, jejich provozu ve větším měřítku a podobě automatizovaného softwarového inženýra.
Otevřený přístup má několik praktických důsledků. Tým si může vybrat model, upravit kód platformy a provozovat ji na vlastní infrastruktuře. Sdílená práce s agenty tak není vázána jen na jednu konkrétní službu nebo jedno předem určené pracovní prostředí.
Na akci zaznělo také srovnání s Dots, integrací prostředí OpenAI pro firemní práci s agenty. OpenClaw zkoumá podobnou oblast společné práce lidí a agentů, ale klade důraz na otevřenost a možnost vlastních úprav. Případné propojení těchto přístupů bylo popsáno jako směr dalších úvah, nikoli jako hotová funkce.
Za zajímavou považuji i zamýšlenou spolupráci s předními komunitními přispěvateli. Ti by mohli získat přístup k agentům a výpočetním prostředkům, zatímco projekt by těžil z jejich nápadů. Nejde tedy pouze o zveřejnění zdrojového kódu, ale také o hledání nového způsobu, jak komunitě zpřístupnit samotnou vývojovou práci.
🔎 Kód ukazuje změnu, konverzace vysvětluje důvod
Jedna věta dnes může vést k vytvoření tisíců nebo desetitisíců řádků kódu. Rozhovor, ze kterého změna vznikla, však často zůstává na počítači jediného člověka. Recenzent potom rozumí tomu, co se změnilo, ale ne tomu, proč byla zvolena právě tato cesta.
Peter se nejprve pokusil přimět přispěvatele, aby k pull requestům přikládali očištěnou podobu konverzace s agentem. Souhlasilo jen málo lidí. Způsob, jakým člověk zadává požadavky, opravuje chyby nebo vyjadřuje frustraci, totiž působí překvapivě osobně. Ani Peter nechtěl své rozhovory sdílet vždy.
Když se relace staly viditelnými pro celý tým už během práce, počáteční rozpaky podle jeho zkušenosti rychle ustoupily. Kolegové začali přebírat užitečné postupy a zachytávat chyby dříve. Transparentnost se proměnila z dodatečné povinnosti v přirozenou vlastnost prostředí.
Vnímám zde důležitý rozdíl mezi archivací a spoluprací. Přiložená konverzace vysvětluje minulost. Přístup k živé relaci umožňuje ovlivnit přítomnost. Tým nemusí čekat, až se nedorozumění projeví v rozsáhlé změně, kterou bude nutné znovu předělávat.
To samozřejmě neznamená, že každá konverzace patří všem. Ukázaný model funguje v prostředí s předem sdílenými oprávněními a důvěrou.
🧩 Sdílený kontext může zabránit zbytečnému konfliktu
Význam konverzačního kontextu dobře ilustrovala úprava tabulek. Peter objevil pull request od Roboclaw, ve kterém někdo zmenšil tabulky, přestože je on sám předchozí den zvětšoval. Bez dalších informací to vypadalo jako bezdůvodné rušení jeho práce.
Otevření související relace ale ukázalo jiný příběh. Victor navázal na Peterovu předchozí práci, použil jeho relaci a dokonce jej upozornil. Z průběhu rozhodování bylo patrné, že změnu promyslel a původní řešení dále vylepšil.
Za přínos zde nepovažuji pouze ušetřený čas. Viditelnost záměru změnila interpretaci kolegova jednání. Z potenciálního sporu se stalo uznání dobré práce. Samotný rozdíl v kódu by tuto souvislost nevysvětlil.
Ve stejné relaci byla patrná i Victorova nespokojenost s délkou průběžné integrace, tedy CI. Peter uvedl, že experimentuje s Codexem při rozhodování, která podmnožina testů je pro konkrétní změnu skutečně užitečná.
Tuto část chápu jako otevřenou výzkumnou otázku, ne jako vyřešený problém. Rychlost generování změn roste, ale testovací postupy nemusí stejným tempem držet krok. Chytřejší výběr testů je slibný směr, stále však musí zachovat důvěru ve správnost výsledku.
🏠 Týmový server jako společné pracovní místo
OpenClaw server tým chápe méně jako jednotlivou aplikaci a více jako místo, kde se projekt odehrává. Vývoj totiž zahrnuje mnohem více než psaní kódu: komunitní zpětnou vazbu, přehled vydání, sledování testů, porady i provozní informace.
Dříve byly tyto nástroje rozptýlené mezi servery, repozitáři, databázemi a automatizacemi v GitHub Actions. Přehled o všech součástech nebyl samozřejmý a jejich úpravy nebyly pro kolegy příliš přístupné. Společný server je soustředil do postranního panelu s aplikacemi a zásuvnými moduly.
Příkladem byl panel sledující stav CI. Jeho vzhled lze upravit běžným zadáním agentovi, třeba změnou barvy. Důležitější než konkrétní kosmetická úprava je ovšem dostupnost celého procesu. Člověk nemusí nejprve zjišťovat, kde nástroj žije a jak se nasazuje.
Peter popsal mnoho podobných panelů jako kombinaci pracovní relace, vytvořeného výstupu a automatizace, která jej aktualizuje. Výstup obsahuje kód, ale mění se tak snadno, že pro něj použil hravé označení „jellyware“.
Já v tom vidím především software s velmi krátkou cestou od nápadu k úpravě. Týmové nástroje nemusí být statickou kulisou. Mohou se průběžně přizpůsobovat tomu, co projekt právě potřebuje.
📊 Přehledy pomáhají, ale ne každý výstup je spolehlivý
Mezi ukázanými nástroji byly přehledy počtu pull requestů, nahlášených problémů a sloučených změn. Další reporty zobrazovaly aktivitu kolegů, například commity a zapojení na Discordu. Společné prostředí tak poskytovalo nejen prostor pro práci, ale také obraz dění v projektu.
Odlehčenější aplikací byl Daily Claw, který z dokončených změn vytvářel novinový souhrn. Peter otevřeně přiznal, že některé výsledky byly dobré, zatímco jiné obsahovaly výrazné chyby. Automatické shrnutí proto nelze zaměňovat za ověřenou informaci.
Zvláštní pozornost si podle mě zaslouží „slop meter“, panel upozorňující na problém přibývajícího agentem vytvářeného kódu. Když je generování levné a rychlé, agent může přidávat další vrstvy řešení místo toho, aby existující strukturu zjednodušoval.
Smyslem nástroje bylo zvýšit povědomí o potřebě úklidu. Peter uvedl, že po jeho zavedení se situace vyvíjela správným směrem. Nezazněla však přesná definice metriky, takže jej chápu především jako týmovou pomůcku pro udržení pozornosti.
Více vytvořeného kódu samo o sobě neznamená lepší software. V agentním vývoji je potřeba zadávat nejen rozšíření funkcí, ale také odstranění nadbytečností a průběžné zpřehledňování projektu.
🎙️ Porady mohou přecházet rovnou v novou práci
Tým vytvořil také vlastní řešení pro porady. Agent se připojuje do Discordu a pořizuje souhrny jednání. Impulzem byla otázka, zda je potřeba platit za samostatnou aplikaci, když podobnou funkci dokáže tým sestavit pomocí zadání agentovi.
Samotné poznámky z porady ale nejsou hlavní novinkou. Peter popsal i možnost hlasové interakce přes GPT Live: účastníci se mohou agenta ptát na práci nebo mu během rozhovoru zadat nový úkol. Tato hlasová část nebyla v dané ukázce předvedena, takže ji odděluji od funkcí, které byly přímo demonstrovány.
Důležitý je princip společné identity. Agent přítomný na poradě má být stejnou trvalou entitou, která zná kontext týmového serveru. Nemusí tak fungovat pouze jako zapisovatel bez návaznosti na projekt.
Podobně sdílené relace ukázaly Victorův postup při vylepšování postranního panelu. Zkoušel řadu vizuálních variant, vytvářel nástroje pro jejich ladění a do procesu se připojil další kolega.
Za cenné považuji, že tým vidí nejen konečný návrh, ale i cestu k němu. Učí se, jak formulovat požadavky a jak posuzovat iterace. Vizuální prostředí zde nabízí podstatně více než společné sledování terminálu během videohovoru.
🏭 K softwarové továrně vede údržba samotných agentů
Širší vize směřuje k agentovi, který dlouhodobě udržuje a zlepšuje software. Část úkolů zůstává interaktivní: člověk s agentem přímo zkouší varianty a ladí výsledek. Vedle toho ale mohou běžet automatické procesy sledující zpětnou vazbu a připravující opravy.
Peter takové procesy označoval jako smyčky. Původně je provozoval na různých strojích, což přinášelo provozní potíže. Některá smyčka se zastavila, jiná potřebovala upravit a někdy nebylo jasné, na kterém počítači vůbec běží.
Přesun na společný týmový server proto není jen centralizací výpočtů. Ostatní mohou procesy poznat, převzít jejich správu a upravit je. Tým postupně udržuje nejen svůj produkt, ale také agenta a automatizace, které produkt vytvářejí.
V této představě stále zůstává výrazná lidská role. Peter ji spojil s vkusem: schopností poznat, co působí správně, co je příjemné a které řešení má skutečnou kvalitu. Takový úsudek se obtížně převádí do přesného zadání.
Já proto softwarovou továrnu nechápu jako odstranění člověka z vývoje. Spíše mění jeho pozici. Méně času může věnovat mechanickému provádění úprav a více času směru, kvalitě a kontrole procesů, které úpravy připravují.
🔁 Smyčka průběžně hlídá, cíl směřuje k dokončení
Jedna z popsaných smyček sleduje Discord, Twitter a GitHub. Pomocné nástroje příkazového řádku usnadňují agentovi získávání dat, která následně třídí do kategorií. U vybraných hlášení může pokračovat vyšetřováním a opravou.
Postup má několik navazujících kroků:
- Agent přečte hlášení a prozkoumá související problém.
- Spustí nové testovací prostředí a pokusí se chybu reprodukovat.
- Pokud reprodukce uspěje, připraví opravu.
- Ověří, zda oprava problém skutečně odstranila.
- Další agent změnu zkontroluje před případným automatickým začleněním.
Další smyčka se věnuje výkonu. Tým vydává novou verzi serveru denně a automatizace pořizuje snímky stavu, hledá regrese a identifikuje možnosti zlepšení. Smyčka tedy nemá jeden okamžik dokončení. Jejím účelem je pokračující dohled.
Naproti tomu cíl má definovaný konečný stav. Příkladem byla postupná migrace ze synchronního přístupu k SQLite na asynchronní databázový přístup. V době prezentace úloha běžela 18 dní a přinesla více než 100 pull requestů. Stále přitom pracovala v Peterově lokálním Codexu.
Pro mě je toto rozlišení zásadní: průběžnou údržbu a dlouhodobou migraci nelze řídit úplně stejně. Budoucí agent pro každý projekt má mít vlastní paměť, cíle, smyčky a automatizace, aby zvládal oba typy práce.
🛡️ OpenClaw Enterprise přidává správu celé organizace
S rozšiřováním agentů z jednotlivých týmů do organizace se mění i otázky, které je potřeba řešit. Nestačí vědět, zda agent dokončí úkol. Organizace potřebuje řídit jeho konfiguraci, přístupová práva, izolaci a možnost kontroly.
Kevin Lin, který vede OpenClaw Enterprise v OpenAI, představil OCE jako open source řídicí platformu pro nasazování agentů. Přidává podporu více oddělených prostředí, správu pravidel a pevné bezpečnostní hranice. Na DevDay bylo oznámeno její otevření veřejnosti.
Podle Kevina tvoří bezpečné běhové prostředí nutný základ pro širší využití trvalých agentů. Platforma proto odděluje agentní práci od důvěryhodné infrastruktury a umožňuje agentům přidělovat konkrétní oprávnění místo neomezeného přístupu.
Kevin uvedl, že tyto kontroly pomohly interně rozšířit provoz na více než 400 agentních nasazení. Agenti podle něj nepřetržitě opravují kód, provádějí experimenty, analyzují data a předávají bezpečnostní problémy k dalšímu řešení.
Toto číslo chápu jako údaj z prezentace, nikoli jako samostatně ověřenou provozní statistiku. Přesto dobře ukazuje, proč se pozornost přesouvá od jednotlivého asistenta k infrastruktuře. S větším počtem trvalých agentů už nelze spoléhat na ruční nastavení a osobní dohled jednoho vývojáře.
🔐 Čtyři bezpečnostní základy agentního provozu
Bezpečnostní model OCE byl popsán ve čtyřech hlavních vrstvách. Považuji za užitečné je oddělit, protože každá řeší jiný druh rizika.
Oddělení důvěryhodného a nedůvěryhodného prostředí
Deterministický řídicí kód běží odděleně od prostoru, kde pracuje agent. V představeném nasazení šlo dokonce o jiný cluster. Cílem je zabránit agentovi v úpravách vlastního běhového prostředí a pravidel, která jej omezují.
Omezení nástrojů pomocí izolace
Sandboxing určuje dostupnou síť, zapisovatelné soubory a repozitáře, do kterých agent smí odesílat změny. Agent může dostat užitečné schopnosti bez přístupu ke všemu. Praktická hodnota spočívá právě v konkrétních hranicích, nikoli jen v obecném pokynu, aby postupoval opatrně.
Kontrola akcí dalším modelem
Funkce automatické kontroly využívá jiný model k posouzení akcí a může potenciálně nebezpečný krok zastavit před provedením. Kevin ji popsal jako doplněk existujících kontrol. Nevnímám ji tedy jako náhradu izolace, ale jako další ochrannou vrstvu.
Samostatná identita každého agenta
Agenti používají vlastní servisní účty a nastavitelné konektory. Nemají pouze vystupovat jménem uživatele. Díky vlastní identitě lze jejich činnost samostatně auditovat, řídit a podle potřeby vypnout.
Pro další kontext k otevřenému vývojovému nástroji je dostupný veřejný repozitář Codexu. Samotná otevřenost kódu však nenahrazuje správné nastavení oprávnění a provozních hranic.
🧑💼 Fred a Cooper ukázali dvě odlišné role
Podniková ukázka začala vytvořením komunitního agenta Freda pomocí přednastaveného balíčku. Takové šablony mají zajistit, aby noví agenti vznikali rovnou s pravidly organizace, nikoli pokaždé podle improvizovaného nastavení.
Fred dostal prostředí Codexu, vlastní servisní účet a přístup ke kódu pouze pro čtení. Měl také přístup do Linearu, ale zápisy měly vyžadovat schválení týmu. Připojení ke Slacku využívalo připravenou aplikaci, token a nastavené kanály.
Cooper představoval jinou roli: trvalého softwarového spolupracovníka pro třídění problémů, opravy chyb a dokončování funkcí. Kevin mu zadal přidání teplotní mapy využití tokenů jednotlivými agenty do přehledového panelu a následně upřesnil požadavek na vlastní barevné palety.
Ověřená relace na Cooperově týmovém serveru umožňovala kolegům vidět zadání a dále jej směrovat. Podnikové nasazení tedy zachovávalo stejný princip společné práce jako menší týmové prostředí.
Fredova odpověď na otázku, co se daný den uvádí, ovšem nepřinesla očekávaný výsledek. Agent procházel Linear a Slack, ale ukázka narazila na problémy a neúplnou orientaci v kontextu. Považuji za důležité tento detail nepřeskočit: správně nastavený přístup k informacím ještě nezaručuje správnou odpověď.
🚀 Otevřená infrastruktura, nikoli hotový konec vývoje
Kevin přirovnal ambici OCE k roli Kubernetes při nasazování kontejnerů. Platforma má podle této vize nabídnout otevřený, dodavatelsky neutrální základ pro správu agentů. Nejde o tvrzení, že už takového postavení dosáhla, ale o směr, kterým chce projekt postupovat.
Pro pochopení přirovnání doporučuji přehled základních konceptů Kubernetes. Podstatná je myšlenka společné provozní vrstvy, na které mohou vznikat různá nasazení, nikoli totožnost obou technologií.
OCE podle oznámení vzniklo v OpenAI a už v rané fázi bylo předáno nadaci. Na dalším vývoji se podílejí také Red Hat a NVIDIA. Závěr současně připomněl rozšíření open source programu Codexu a iniciativu Patch the Planet, která spolupracuje například s Trail of Bits na bezpečnosti otevřeného softwaru.
Z celého představeného směru si odnáším tři priority: sdílet důvody změn, nejen výsledný kód; provozovat automatizace tak, aby je mohl spravovat tým; a oddělit užitečné schopnosti agentů od neomezených oprávnění.
Open source je zde chápán jako kritická infrastruktura. Lepší agentní nástroje mohou pomoci s její údržbou, ale kvalita závisí také na recenzích, bezpečnostních pravidlech a lidském úsudku. Nejslibnější budoucnost proto nevidím v osamělém agentovi, který všechno vyřeší. Vidím ji ve společném prostředí, kde lidé a agenti dokážou navazovat na práci ostatních a průběžně ji zlepšovat.
