V jednom z předchozích článků jsem popisoval, jak používám OpenClaw na remote serveru. Pointa tehdy byla jednoduchá: AI vývoj začne být opravdu zajímavý ve chvíli, kdy agent nesedí jen v editoru vedle člověka, ale pracuje v připraveném prostředí nad reálným systémem.
To pořád platí. Jen se mi od té doby posunula představa, jak má takové prostředí vypadat.
Dřív to u mě bylo hlavně VPS, na kterém běžel OpenClaw. Dneska přecházím k vyhrazenému počítači pro bota. Nejen ke vzdálenému serveru, kam pošlu úkol, ale k pracovnímu místu, kde má agent vlastní účet, vlastní prostředí, vlastní přístupy a běžné nástroje podobně jako normální uživatel.
Změnila se i technická vrstva. OpenClaw mi v tomhle konkrétním režimu už nedává smysl držet jako hlavní nástroj. Na VPS dával smysl jako pracovní vrstva nad Codexem, ale pro lokální orchestraci je dnes přímější codex-app-server. Spustí klasickou Codex session se vším všudy: s pravidly repozitáře, nástroji, kontextem a běžným způsobem práce, který už mám připravený.
Ten bot se jmenuje Jan Kodér. A důležité je, že to není jen další chat. Je to digitální vývojář s vlastním pracovním místem.
Od editoru k úkolu
Když jsem s AI vývojem začínal, celé pracovní místo bylo IDE. Typicky Cursor. Seděl jsem v editoru, zadával modelu, co chci, koukal na kód a po krocích ho opravoval.
Ten režim pořád existuje a pořád dává smysl. Jen pro mě přestal být hlavní. Čím víc pracuji přes Codex, Claude Code a vlastní orchestrace, tím častěji kód vidím až při review v aplikaci, v diffu nebo v pull requestu. Nezačínám tím, že agentovi říkám každý další krok. Začínám úkolem.
O tom jsem psal už v článku Software se změnil. K nepoznání.. Největší změna není rychlejší psaní kódu, ale jiný delivery model. Řídím práci, ne jednotlivé řádky.
Izolace je základ
První praktický zlom byly git worktrees.
Dokud člověk pracuje na jedné lokální větvi v jednom repozitáři, paralelní agentní práce se rychle začne rozpadat. Jeden agent něco mění, druhý potřebuje jinou změnu, třetí chce spustit aplikaci v trochu jiném stavu a najednou se všechno přebíjí. Teoreticky můžeš mít víc chatů, ale pořád se potkávají v jednom pracovním prostoru.
Worktrees tenhle problém řeší obyčejně a účinně. Každý úkol může mít vlastní větev a vlastní pracovní adresář. Jenže v monorepu to samo o sobě nestačí. Git worktree vytvoří další checkout kódu, ale nevyřeší, na jakých portech poběží backendy a frontendy, odkud se vezmou lokální .env soubory, jak se nastaví databáze a jak zajistit, aby si dvě rozpracované změny nesahaly do stejného runtime stavu.
Proto pro mě worktree není jen adresář s jinou branchí. Je to samostatné lokální vývojové prostředí. Má vlastní portový blok, runtime proměnné, Encore namespace, Temporal namespace, lokální databázi a standardní způsob spuštění přes root příkazy v monorepu.
Tohle je rozdíl mezi “agent si píše kód bokem” a “agent může reálně ověřit změnu v běžící aplikaci”. Když pracuje na ticketu, potřebuje spustit backend, správný frontend, přihlášení, workflow runtime a data, která dávají smysl. Jinak sice možná upraví správné soubory, ale testuje prostředí, které v realitě neexistuje.
To ale ještě není orchestrace. Když mám pět izolovaných běhů a každý musím ručně hlídat, pořád jsem operátor chatů. Potřebuji vědět, odkud si agent bere práci, kde je vidět stav, jak poznám, že je hotovo, a kam se práce vrací, když potřebuje rozhodnutí.
Jinými slovy: nechci jen víc agentů. Chci systém, který umí práci řídit.
Symphony jako specifikace
V tomhle mi sedlo OpenAI Symphony. Ne proto, že bych chtěl vzít hotovou implementaci a nasadit ji jedna ku jedné. Zajímavější pro mě byla samotná myšlenka a specifikace.
Symphony popisuje model, ve kterém se projektová práce mění na izolované autonomní implementační běhy. Sleduje se board v nástroji typu Linear, agenti si berou úkoly, pracují v odděleném prostředí, vrací důkazy práce a člověk nemusí sedět u každého promptu.
OpenAI má Symphony veřejně na GitHubu a přímo tam je i specifikace. Dobrá specifikace je pro mě silnější než hotový nástroj. Můžu ji dát Codexu a říct: podle tohohle patternu mi postav orchestrátor pro moje repo a moje prostředí.
A přesně to jsem udělal.
Software se dnes dá v některých případech nejdřív popsat jako markdownová specifikace: co má dělat, jaké má mít stavy, jak má reagovat na události a jaké má mít hranice. Agent pak tu specifikaci implementuje pro konkrétní repozitář.
Princip není svázaný s jedním jazykem. Podle stejné specifikace si můžeš orchestrátor napsat v TypeScriptu, Elixiru, Javě nebo Pythonu. Já jsem použil TypeScript, protože sedí do našeho prostředí a do způsobu, jakým dnes stavíme DREEM. Důležité ale není “TypeScript”. Důležité je, že máš popsané, co má software dělat, a konkrétní implementace se přizpůsobí tvému stacku.
Linear jako řídicí vrstva
U mě je primární místo pro zadávání práce Linear. Tam dávám tickety, tam rozpadám úkoly, tam chci vidět stav. Nechci, aby skutečný stav práce existoval v pěti otevřených chatech někde bokem.
Nechal jsem si proto lokálně vytvořit orchestrátor inspirovaný Symphony pro naše repo. Není to obecná platforma pro každého. Je to konkrétní pracovní vrstva nad naším repozitářem, našimi skripty, našimi worktrees a tím, jak používám Codex.
V DREEM monorepu je to samostatná aplikace apps/symphony. Běží jako lokální orchestration daemon, sleduje Linear, připravuje workspace a spouští codex-app-server session.
V kořenovém WORKFLOW.md je vidět několik praktických rozhodnutí. Tracker je Linear. Práce se bere z ticketů označených codex nebo z ticketů, které jsou přiřazené přímo Janu Kodérovi. V konfiguraci je to popsané jako pickup_policy: label_or_assigned_to_me: label je rychlý způsob, jak poslat práci do fronty, přiřazení je přímý úkol pro konkrétního agenta.
Workflow zná aktivní stavy jako Todo, In Progress, Rework, Internal Review, Internal QA nebo Merging. Paralelně můžou běžet maximálně tři agenti a pro stav Merging jen jeden. Merge fáze je přesně místo, kde nechci řešit tři hotové změny najednou a rozplétat, která patří kam.
Codex část workflow nespouští vlastní AI runtime. Spouští normální codex-app-server:
codex --config shell_environment_policy.inherit=all app-serverPraktické je, že orchestrátor nevymýšlí vlastního coding agenta. Použije Codex session se stejným typem práce, pravidel a nástrojů, jaké bych použil ručně, jen ji spustí automaticky pro konkrétní Linear ticket.
Když agent skončí, stav se vrací zpátky do ticketu. Když potřebuje vstup ode mě, ticket se přepne do stavu, kde je jasně vidět, že čeká na člověka. Já doplním rozhodnutí nebo kontext, vrátím ho zpátky ke zpracování a práce pokračuje.
Co dělá DREEM setup
Druhá důležitá část je workspace. V DREEM jsem z lokálního vývoje udělal kontrakt. Nechci mít jeden způsob spuštění pro sebe, druhý pro kolegy, třetí pro Symphony a čtvrtý pro Codex. Když nějaký proces vytváří worktree nebo spouští lokální aplikaci, má používat stejné root příkazy jako člověk.
Root package.json je v tomhle smyslu veřejné API lokálního vývoje. pnpm dev spouští celý lokální stack. pnpm dev:dreem-backend spouští backend, pnpm dev:dreem-public-web, pnpm dev:dreem-app-web a pnpm dev:dreem-client-web spouští jednotlivé weby. pnpm dev:ports a pnpm dev:env ukážou, v jakém prostředí právě jsem. pnpm worktree:add, pnpm worktree:prepare a pnpm worktree:remove jsou jedna společná cesta pro vytvoření, přípravu a úklid worktree.
To je pro mě štábní kultura v praxi. Symphony není speciální lokální platforma. Codex také ne. Jsou to další uživatelé stejného vývojového kontraktu. Symphony vytvoří worktree přes stejnou cestu jako člověk, Codex pak spouští stejné dev příkazy jako člověk. Když se něco pokazí, nehledám chybu ve čtyřech různých sadách helperů.
Porty jsou rozdělené po blocích. Hlavní checkout má svůj blok, první worktree další, druhý zase další. Když vidím frontend na 5200, vím, že patří k backendu na 4200. Když vidím frontend na 5300, vím, že patří k backendu na 4300. Nemusím zjišťovat, který proces si zrovna našel volný port.
Tohle zní jako drobnost, ale není. Frontend dev servery často umí při obsazeném portu potichu přeskočit na další volný port. Pro malý projekt je to pohodlné. Pro worktree setup je to chyba. Pokud worktree dostal port 5200, má běžet na 5200, nebo spadnout. Tichý posun na jiný port rozbije backend URL, OAuth callbacky, lokální odkazy i očekávání člověka.
Portový blok se ukládá do lokálních git metadata daného worktree. Nejen že se z něj skládají porty, ale zároveň se tím rezervují i pro vypnuté worktrees. Worktree nemusí zrovna běžet, ale jeho blok pořád patří jemu. Jinak by další worktree mohl dostat stejné porty a kolize by se objevila až ve chvíli, kdy budu chtít rozpracovanou větev znovu spustit.
Názvy workspace, worktree adresářů a lokálních namespace odvozuji z Linear ticketu. Když se pracuje na ticketu DRE-56, runtime název může být třeba wt-dre-56. Porty se z ticketu neodvozují, ty řeší portový blok. Ticket ale dává prostředí čitelnou identitu: v seznamu worktrees, v namespacech, v cleanupu i v tom, co sleduje Symphony.
Přípravný skript je idempotentní. Jde spustit při vytvoření worktree i později nad existujícím checkoutem. Zkopíruje lokální ignorované .env a secret soubory, ale nespoléhá na to, že v nich bude napevno přepsaná každá URL. Porty, namespace a další odvozené hodnoty patří do metadata aktuálního worktree. Lokální runner je pak při spuštění procesu použije a složí správné runtime hodnoty.
To je důležité hlavně u frontendů. Frontend v jednom worktree musí mluvit s backendem stejného worktree. Pokud omylem mluví s backendem z hlavního checkoutu, testuju kombinaci kódu, která v realitě neexistuje.
Tady se hodí i Encore. Backend v Encore nám pomáhá držet aplikační prostředí tak, aby pro každý ticket mohlo vzniknout vlastní běžící prostředí: vlastní namespace, vlastní databáze, vlastní backend na vlastním portu a podle potřeby i vlastní frontend nebo klient.
Stejně důležitá jsou data. Nový worktree nechci startovat s prázdnou databází, pokud běžná práce vyžaduje realistická data. Setup proto připraví lokální databázi pro dané prostředí jako kopii výchozí lokální databáze. Od té chvíle se worktree oddělí. Migrace z konkrétní branche se aplikují jen na databázi tohoto prostředí a nerozbijí hlavní lokální checkout ani ostatní rozpracované větve.
Temporal řeším podobně, ale ne přes porty. Lokálně stačí jeden Temporal server. Jednotlivé worktrees se oddělí přes vlastní Temporal namespace odvozený od Encore namespace. Worker z daného worktree se připojí do namespace daného worktree, takže workflow histories a task queues neleží v jednom společném prostoru.
Další praktický detail je Google login. OAuth callback musí být přesný, ale worktrees běží na různých frontend portech. Nechci kvůli tomu registrovat desítky lokálních callback URL. Lepší model je lokální OAuth relay daemon: Google volá jeden stabilní lokální callback, v podepsaném state je uložený přesný cílový frontend callback aktuálního worktree a relay po ověření vrátí prohlížeč na správný port.
Tohle celé má jeden cíl: když worktree vytvoří člověk, Symphony nebo Codex, výsledek má být stejný. Stejné příkazy, stejné portové bloky, stejná metadata, stejný způsob spuštění, stejný cleanup. Pak lokální vývoj nestojí na opatrnosti a ruční domluvě, ale na systému.
Repo musí agenta unést
Tady je dobré říct jednu nepříjemnou věc: nejde vzít libovolný repozitář a čekat, že z toho přes noc vznikne dobře fungující agentní tým.
Repo musí být připravené. Musí mít instrukce, skripty, testy, způsob spouštění, jasné hranice, čitelnou strukturu a dostatečně dobrý kontext. Agent neopraví chaos sám od sebe tím, že do něj začne rychleji psát kód.
Mně pomohlo, že už delší dobu vyvíjím s Codexem přímo DREEM. Repo už bylo přizpůsobené tomu, aby se v něm agent dokázal orientovat. Mělo pracovní pravidla, existující workflow, přípravu pro worktrees a jasný způsob, jak ověřovat změny.
Bez toho by orchestrace sama o sobě moc nevyřešila. Když nemáš připravený systém, jen rychleji vyrábíš stav, který budeš muset ručně uklízet.
Proč má Jan vlastní počítač
Samostatný počítač a vlastní Google Workspace účet nejsou dekorace. Je to provozní hranice.
Když má agent vlastní účet, můžu přesněji nastavit, kam se dostane, co vidí, co může a co nemůže. Je oddělený od mých osobních dat, od mého účtu a od mého běžného pracovního prostoru. Má svoje složky, přístupy, prostředí a výstupy. Já se na jeho počítač můžu vzdáleně připojit a zkontrolovat, co se děje, ale není to můj notebook ani můj login.
Oproti omezenému sandboxu někde v cloudu je to jiný pracovní model. Když chci, aby agent pracoval na reálném software delivery workflow, často potřebuje víc než možnost upravit soubor. Potřebuje běžící aplikaci, lokální služby, přístup k issue trackeru, preview, testy, někdy i pracovní infrastrukturu typu Google Workspace.
Ne proto, že by měl mít nekonečná práva. Právě naopak. Má mít přesně vymezená práva v prostředí, které se podobá reálné práci.
Pointa není, že AI píše kód
Kdybych to měl shrnout, největší změna pro mě není v tom, že AI umí napsat další kus kódu. To už dneska umí. Velká změna je v tom, kde se ta práce řídí.
Začínal jsem v editoru. Pak jsem se posunul k agentům, kteří pracují na úrovni tasku. Pak přišly worktrees, aby mohli běžet paralelně. Pak orchestrace přes Linear, aby práce nežila jen v chatech. A teď samostatný počítač a účet, aby agent nebyl proces pod mojí osobní identitou, ale pracovní jednotka s vlastními hranicemi.
Skutečný posun v AI-native software delivery není “lepší autocomplete”, ale změna řídicí vrstvy. Člověk nepřestává být důležitý. Naopak. Ještě víc záleží na tom, jestli umí práci rozpadnout, nastavit mantinely, držet architekturu, rozhodovat trade-offy a kontrolovat výsledek.
Jen už nemusí všechno dělat vlastníma rukama v jednom editoru.
Manažer počítače pro mě není metafora. Je to čím dál konkrétnější pracovní model: zkušený člověk řídí digitální vývojáře uvnitř počítače. Jeden z nich se jmenuje Jan Kodér, bere si práci z Linear ticketů označených pro agenta nebo přiřazených přímo jemu, běží přes codex-app-server, má vlastní prostředí a vrací práci zpátky k review.
Mnohem zajímavější než další prompt v editoru.
