Když se dnes mluví o AI vývoji, spousta lidí si pořád představí programátora, který sedí u svého notebooku, otevře chat a nechá si po kouskách generovat kód. Ten model existuje, ale podle mě není ten nejzajímavější.
Nejzajímavější chvíle nastává ve momentě, kdy AI nesedí jen vedle člověka v editoru, ale pracuje v připraveném vzdáleném prostředí. Ne na mém osobním počítači, ale na serveru, kde má k dispozici celé vývojové zázemí a kde může na úkolech pracovat samostatně. Přesně tak dnes používáme OpenClaw.
Není to chatbot v jednom okně
Máme VPS, na kterém běží OpenClaw. Ten pracuje s Codexem a funguje jako skutečná pracovní vrstva pro vývojové úkoly.
Dnes jedeme zrovna na Codexu i z praktického důvodu. Pro tenhle způsob práce je tam subscription model pořád použitelný, zatímco u Claude Code byla možnost podobného použití pro third-party nástroje nedávno zrušená. Neznamená to, že by podobný systém nešel postavit i přímo nad Claude Code. Jen by to pro mě dnes znamenalo menší flexibilitu. Právě v tom je pro mě OpenClaw důležitý: dává mi větší volnost v tom, jak celé workflow poskládat, routovat a napojit na další nástroje.
Já s ním komunikuji přes chat. Zadám úkol, doplním kontext, upřesním očekávání a on pracuje. Důležité je, že ta práce není navázaná na můj osobní notebook. Nemusím mít všechno rozběhané lokálně, nemusím držet otevřené jedno konkrétní okno a nemusím být fyzicky přilepený ke svému stroji, aby se věci hýbaly dopředu. To je podle mě zásadní posun.
Najednou nejde jen o „AI mi poradila kus kódu“. Jde o to, že digitální specialista má vlastní pracovní místo uvnitř připraveného systému.
Proč je prostředí tak důležité
Samotné rozdělení na lokální a remote režim není ta hlavní pointa. Když má AI agent k dispozici plnohodnotné lokální prostředí, běžící službu, endpointy, MCP servery, testy a browser automatizaci, může odvést velmi podobně kompletní práci i tam.
Problém nastává ve chvíli, kdy agent běží v omezeném režimu bez přístupu ke skutečnému prostředí. Pak sice může navrhnout změnu, přepsat soubor nebo vygenerovat test, ale pořád zůstává napůl slepý vůči realitě systému.
U remote serveru je pro mě důležité něco trochu jiného: že tohle plnohodnotné prostředí neběží na mém osobním počítači a agent v něm může pracovat nezávisle, i když zrovna nesedím u svého stroje. OpenClaw tam má přístup ke kompletnímu vývojovému prostředí, k běžící službě i k nástrojům, které jsou potřeba pro ověřování reality.
To znamená, že může:
- pracovat přímo nad reálným repozitářem,
- spouštět aplikaci a sahat na skutečné workflow,
- volat endpointy a kontrolovat odpovědi,
- pomocí Playwrightu procházet web a ověřovat chování rozhraní,
- spouštět testy,
- a vracet se s výsledkem, který není jen teoretický.
Tohle je obrovský rozdíl oproti představě, že AI jen něco napsala a člověk pak musí všechno ručně dohledat a zkontrolovat.
Vývoj se dá rozpadnout na skutečné specialisty
Druhá důležitá věc je, že na jednom úkolu nemusí pracovat jen jeden obecný agent. Když přijde větší produktové zadání, nezačíná to tím, že bychom slepě řekli „udělej feature“. Nejdřív se rozpadne zadání s architektem. Vyjasní se scope, trade-offy, hranice řešení a vznikne konkrétní TODO list. Teprve potom se práce rozkládá dál.
Typicky to může vypadat takto:
- architekt rozpadne zadání a navrhne řešení,
- vznikne seznam menších konkrétních úkolů,
- backend specialista připraví doménu, endpointy a servisní logiku,
- jakmile backend stojí, naváže frontend web specialista,
- paralelně nebo následně naváže iOS specialista,
- na konci přijde QA, testy a finální ověření,
- a výsledkem je PR, které jde ke schválení člověku.
To ukazuje, že AI workflow nemusí být jeden dlouhý kontext, ve kterém se všechno míchá dohromady. Může to být návazný systém rolí, které si práci předávají podobně jako v normálním týmu. Rozdíl je v tom, že ty role běží rychleji, levněji a s menším množstvím organizačního tření.
Backend, web i iOS nejsou oddělené světy
Na klasickém projektu často vznikají handoffy, které celý proces zpomalují. Backend něco připraví, frontend čeká, mobil čeká, QA čeká. Pak se něco ukáže, vrací se to zpátky a celý cyklus se znovu rozjíždí.
V AI-native workflow se tenhle rytmus dá výrazně zkrátit, pokud mají specialisté k dispozici stejné prostředí a společný kontext nad produktem.
Backend specialista nepředává jen hypotetický návrh API. Předává funkční vrstvu, kterou lze skutečně zavolat a otestovat. Web specialista pak neimplementuje naslepo podle starého screenu, ale proti chování, které už existuje. iOS specialista nevychází jen z dokumentu, ale z reálného systému. Tím se zmenšuje počet slepých míst mezi vrstvami produktu.
Preview environment zkracuje cestu k pravdě
Jedna z nejsilnějších částí tohohle modelu je preview environment. Jakmile je feature v nějakém použitelném stavu, můžeme si ji rovnou vyzkoušet. Nemusíme debatovat jen nad screenshotem, diffem nebo slovním popisem. Díváme se na reálnou věc.
To má praktické důsledky:
- rychleji poznáme, jestli feature opravdu funguje,
- rychleji odhalíme nečekané chování,
- rychleji se ukáže, jestli backend, web a iOS drží pohromadě,
- a rychleji se rozhoduje, co je ještě potřeba upravit.
Právě tady se celý systém zrychluje nejvíc. Ne v tom, že někdo napíše první verzi kódu, ale v tom, že cesta od implementace k ověřené iteraci je výrazně kratší.
Když najdeme problém, nečekáme na další sprint
Pokud v preview nebo při testování najdeme problém, nevzniká z toho velké drama. Prostě AI řekneme, co je špatně, popíšeme bug, chybějící detail nebo špatný trade-off, a dostaneme další iteraci.
Tohle je podle mě další důležitý rozdíl oproti staršímu modelu práce. Zpětná vazba se vrací hned zpátky do systému místo toho, aby čekala na další schůzku, sprint planning nebo volné okno v kapacitě týmu. Čím lépe je postavené prostředí, tím levnější jsou další iterace.
Člověk zůstává ten, kdo drží odpovědnost
Je důležité dodat i druhou stranu. Tenhle model neznamená, že člověk zmizel z rovnice. Naopak. Člověk je pořád ten, kdo:
- drží produktový a technický kontext,
- rozhoduje o architektuře a prioritách,
- vyhodnocuje kvalitu výsledku,
- schvaluje PR,
- a nese odpovědnost za to, co se nakonec mergeuje a releasuje.
OpenClaw na VPS pro mě není zajímavý proto, že by nahrazoval zkušenost. Je zajímavý proto, že zkušenosti dává mnohem větší páku. Zkušený člověk tak najednou neřídí jen vlastní ruce na klávesnici, ale digitální tým specialistů, kteří mají přístup ke skutečnému prostředí a umí nad ním pracovat.
Proč mi to přijde důležité
Protože přesně tady je vidět, že software se opravdu vyrábí jinak než dřív.
Nejde jen o to, že AI umí psát kód. Jde o to, že může pracovat uvnitř připraveného systému:
- s repozitářem,
- s běžící službou,
- s endpointy,
- s browser automatizací,
- s testy,
- s preview prostředím,
- a s návazností dalších specialistů.
V tu chvíli z AI přestává být jen chytrý doplněk v editoru. Začíná připomínat skutečný delivery tým. A právě proto mi tenhle posun připadá důležitý: neukazuje jen, že AI umí napsat víc kódu, ale že zkušený člověk dnes může řídit software delivery v mnohem kratších smyčkách a s mnohem větší pákou než dřív.
