DREEM stavím s Danem. Dan řeší obchod, já produkt a vývoj. Průběžně reaguju na to, co se v byznysu děje, co potřebujeme a kde něco nefunguje tak, jak jsme si představovali. Podle toho měním produkt i software, na kterém firma běží.
Vývoj řeším jako jednotlivec přímo v Codexu. Běžně tam každý den pracuju na pěti až šesti problémech současně. Rozhoduju, co má vzniknout, dávám agentům kontext, kontroluju výsledky a dál je upravuju. Současně do DREEM zapojuju AI pro každodenní práci — třeba při zpracování telefonátů, přípravě zápisů nebo vytěžování dokumentů.
Základ je pro mě iterace: vytvořit první verzi, nasadit ji, ověřit ji v praxi a podle zkušenosti ji znovu upravit. Tenhle cyklus opakuju den za dnem na několika částech produktu současně. S Danem tak průběžně měníme samotnou službu i software, na kterém běží.
Dan řeší obchod, já z toho dělám produkt
DREEM je realitní služba. Její každodenní fungování stojí na komunikaci s lidmi, práci s nemovitostmi, dokumenty, termíny a návaznosti jednotlivých kroků. Vlastní software mi umožňuje tyhle věci navrhovat společně s tím, jak má fungovat firma.
Propojuje se mi tady fyzický svět, lidé a počítače. Nemovitost, prohlídka nebo telefonát s klientem mají svou návaznost v aplikaci: informace, další krok, domluvený termín. To, co vyvíjím, se promítá do práce s konkrétními lidmi a nemovitostmi. A zkušenost z téhle práce se mi vrací do vývoje.
Dan řeší obchodní stránku. Já potřebuju rozumět tomu, co z ní plyne pro produkt. Kde potřebujeme lepší přehled. Co se zbytečně dělá ručně. Jaká informace chybí ve chvíli, kdy ji někdo potřebuje. Nebo kde systém od lidí očekává něco, co v reálné práci nedává smysl.
Z takového pozorování teprve vzniká zadání. Musím rozhodnout, jestli potřebujeme jinou obrazovku, upravit proces, doplnit data nebo změnit odpovědnost za další krok. A taky jestli daný problém vůbec stojí za řešení právě teď.
Tohle je velká část mé práce. Držím souvislost mezi tím, co se děje v byznysu, a tím, co vyvíjím. Když se mění naše představa o službě, promítám ji do systému. Když při používání zjistíme, že jsme něco navrhli špatně, vracím se k tomu.
S Danem se tak průběžně učíme, jak má DREEM fungovat. Produkt vzniká spolu s firmou.
Stavíme na zelené louce
Máme v tom obrovskou výhodu: stavíme na zelené louce. Můžu postupovat krok za krokem, funkci po funkci, a spolu s produktem tvarovat i to, jak firma pracuje. Něco postavím, vyzkoušíme to a podle výsledku udělám další krok. Tenhle prostor nám umožňuje dobře iterovat.
U rozjeté firmy s komplexním systémem a desítkami, stovkami nebo tisíci zaměstnanců by to bylo nesrovnatelně náročnější. Měnil bych zaběhnuté postupy a vazby, na kterých každý den závisí spousta lidí. Každou změnu bych musel sladit s mnohem větším provozem. My můžeme službu a její software rozvíjet společně od začátku a tahle výhoda se do naší rychlosti výrazně promítá.
Dnes řeším vývoj přímo v Codexu
Dřív jsem pro řízení práce používal vlastní řešení postavené na konceptu Symphony od OpenAI. Symphony propojuje evidenci úkolů s vývojovými agenty. Přebírá připravená zadání například z Linearu, pro každé vytvoří oddělené pracovní prostředí a spustí v něm agenta. Hlídá souběžné běhy, jejich stav i opakování po chybě.
V DREEM jsem měl vlastní implementaci podle téhle specifikace, napojenou na Linear a Codex. Práci jsem popsal v úkolu a tahle řídicí vrstva se postarala o její spuštění. Já jsem určoval, co se má udělat, a kontroloval výsledek. Symphony kolem toho zajišťovalo organizaci práce a přehled o běžících úlohách. V té době mi to dávalo smysl.
Jenže modely se posunuly a spolu s nimi i harness, tedy prostředí, které řídí práci agentů a dává jim nástroje. V určité chvíli mi vlastní vrstva kolem nich přestala přinášet dost hodnoty. Symphony jsem opustil a dnes řeším vývoj přímo v Codexu.
Pro můj způsob práce už stačí samotný Codex. Bez dalšího čarování kolem. Model a harness přitom beru jako dvě samostatné volby. Ať jde o model od OpenAI, Anthropicu nebo open weight model, potřebuju k němu prostředí, které ho umí připojit a řídit jeho práci. Já tuhle práci dnes organizuju v Codexu.
Funguje mi to v našem konkrétním setupu, kde vývoj řeším jako jednotlivec. Kdyby nás bylo ve vývoji víc, pravděpodobně bychom potřebovali společné místo, kde snadno vidíme, kdo na čem pracuje a jak na sebe změny navazují. Teď jsem tím společným bodem já. Vlastně řídím naše vlastní AI oddělení a jsem jediný člověk, který má přehled o všem, co v něm vzniká, co řešíme a kde se co děje.
Každý problém má vlastní thread. V něm si agent podle potřeby spouští další subagenty a rozděluje mezi ně práci. Každý takový běh má celé vlastní pracovní prostředí, takže se rozpracované implementace navzájem neovlivňují. Můžu je posouvat a ověřovat samostatně.
Takhle běžně pracuju na pěti až šesti problémech zároveň. Každý den. Když jeden thread implementuje změnu nebo ji ověřuje, můžu v jiném upřesnit zadání, projít výsledek nebo rozhodnout, jak pokračovat. Jednotlivé běhy se posouvají souběžně a já mezi nimi přecházím podle toho, kde je potřeba moje rozhodnutí.
Z pohledu mojí každodenní práce je to, jako bych měl k dispozici pět kompletních vývojářských týmů. Každý řeší vlastní problém od zadání přes implementaci až po ověření. Díky paralelizaci a subagentům můžu jako jeden člověk posouvat několik částí produktu současně. Někdy je až děsivé, kolik toho dnes jeden člověk zvládne, když umí AI nástroje a tenhle způsob vývoje používat.
Tým agentů má vlastní počítač
Celý tenhle vývoj běží na vyhrazeném počítači u nás v kanceláři, který má tým agentů pro sebe. Má tam vlastní pracovní prostředí, nástroje a rozpracované úlohy. Na mém notebooku tenhle tým neběží. Notebook používám k tomu, abych se na jeho počítač připojil a práci řídil.
Pro vzdálený přístup používám Tailscale. Snadno a rychle mi propojí zařízení do soukromé šifrované sítě. Pracovní počítač tak zůstává v kanceláři a já se k němu můžu připojit i z jiné sítě. Nastavení je jednoduché a funguje mi to skvěle.
Technicky jde o privátní síť postavenou na WireGuardu. Zařízení se pokud možno propojí přímo mezi sebou a komunikace je šifrovaná od jednoho zařízení k druhému. Pro běžné připojení nemusím ručně přesměrovávat porty na routeru ani vystavovat vzdálený přístup k počítači veřejnému internetu.
Když sedím u počítače, připojím se vzdáleně a pracuju přímo v tomhle prostředí. Když jsem venku, otevřu Codex v mobilu. Vidím, co se v jednotlivých úlohách děje, můžu doplnit zadání, projít výsledek nebo rozhodnout, jak pokračovat. Ke stejné rozpracované práci se tak dostanu z počítače i telefonu.
To mi dává svobodu. Tým má svoje pracovní místo a já ho můžu řídit podle toho, kde zrovna jsem. Vzdálené přístupy a ovládání přes mobilní aplikaci má Codex pro můj způsob práce výborně udělané. Přehled i možnost zasáhnout mám pořád po ruce.
Část práce má svůj rozvrh
Vedle jednotlivých zadání používám v Codexu i scheduled tasks, tedy naplánované úlohy. Popíšu práci a nastavím, kdy se má opakovat. Hodí se mi to pro kontroly a přípravu podkladů, ke kterým se potřebuju pravidelně vracet. Úlohy nad lokálním projektem potřebují zapnutý pracovní počítač a spuštěnou aplikaci.
V noci mám naplánovaný audit produkčních chyb DREEM a kontrolu workflow v Temporalu. Ráno navazuje kontrola PostHogu a audit efektivity provozu. V sedm je na řadě denní souhrn změn pro lidi ve firmě. K tomu mám týdenní úklid pracovního Macu a Codexu a měsíční přípravu reportu pro investory.
Tím dávám části práce pravidelný rytmus. Kontroly a přehledy nemusím pokaždé znovu zadávat. Jejich výsledky můžu projít a rozhodnout, co se má opravit, změnit nebo dál rozvíjet. I takhle získávám podklady pro další iteraci.
Limit je moje hlava
Pět souběžných problémů znamená pět kontextů, které musím udržet v hlavě. U každého potřebuju vědět, proč ho řeším, co jsem zadal, co už vzniklo a jak poznám, že je výsledek správný. Když se vrátím do threadu, musím na jeho práci navázat a rozhodnout o dalším kroku.
Technicky bych takhle mohl pracovat klidně na deseti věcech najednou. Jenže tam už mi dochází vlastní mentální kapacita. Agenti by mohli pokračovat, ale já bych nestíhal s potřebnou pozorností držet všechna zadání, souvislosti a výsledky.
Vývoj pořád řeším já jako jednotlivec. Mám k dispozici souběžnou práci, která mi připomíná několik kompletních týmů, a sám ji musím řídit. Těch pět až šest problémů je pro mě v současnosti hranice toho, co takhle zvládnu. I v tomhle rozsahu je to obrovsky mentálně náročné.
Izolované prostředí vyřeší, aby si agenti nepřekáželi při implementaci. Produktová rozhodnutí a souvislosti mezi změnami ale zůstávají u mě. Každý výsledek musí zapadnout do jednoho DREEM a do toho, co s Danem potřebujeme pro byznys.
Do produkce několikrát denně
Pořád vnímám jako velkou výhodu, že mám hluboký technický background. Pomáhá mi pochopit, čeho se změna dotkne, kde může vzniknout problém a podle čeho poznám, že agent dodal správný výsledek. Tu zkušenost používám při zadávání práce i při rozhodování, jestli je výsledek připravený k nasazení.
PR dnes už neřeším. Kód posílám rovnou do produkce — pokud projde testy. :)
Nasazuju několikrát denně. Změny odesílám do větve production, odkud se automaticky nasazují. Jen za dva týdny od 2. do 15. září 2026 má hlavní linie téhle větve 309 commitů. V průměru je to přibližně 22 denně, včetně víkendů. Tenhle rytmus mi umožňuje rychle vracet zkušenost z používání do další verze.
Pořád přitom musím dobře zadat, co potřebuju. U práce po telefonátu popíšu, ke komu hovor patří, co z něj má vzniknout, kdo má výstup zkontrolovat a kde se mají objevit další úkoly. Změna se může dotknout backendu, interní aplikace i klientského portálu. Kontroluju, že do sebe tyhle části zapadají, a když výsledek neodpovídá zadání, pokračuju další iterací. Součástí práce jsou testy a ověření chování aplikace.
Co se stane po telefonátu
Na zpracování hovoru se dá dobře ukázat i druhá část mé práce s AI.
Po telefonátu zbývá zachytit, co se domluvilo. Někdo má dodat dokument, někdo se má ozvat, něco je potřeba ověřit. Informace musí zůstat u správného člověka a případu, aby se na ně dalo navázat i později.
V DREEM mám pro nahrané hovory zpracování, které vytvoří přepis, interní shrnutí a návrh klientského zápisu. Součástí návrhu mohou být další kroky. Pracovník si výstup projde, může ho upravit a schválí konkrétní verzi. Na schválený zápis navazují úkoly a zpřístupnění klientského výstupu.
Za tím je několik rozhodnutí, která musím udělat při návrhu produktu. Interní shrnutí slouží lidem ve firmě. Klientský zápis má být srozumitelný pro klienta a obsahovat to, co s ním potřebujeme sdílet. Další krok musí mít vazbu na konkrétní práci, aby nezůstal jen větou v odstavci.
AI tady pomáhá převést rozhovor do použitelné podoby. Software zajišťuje, kam výsledek patří a co na něj naváže. Člověk kontroluje obsah, za kterým má stát. Tohle rozdělení navrhuju záměrně, protože od každé části potřebuju něco jiného.
Pro klienta má být výsledkem přehled o tom, co se domluvilo a co bude následovat. Pro lidi uvnitř firmy pak možnost pokračovat v práci bez opakovaného dohledávání celého rozhovoru.
První verzi nasadím. Druhý den ji upravuju.
Udělám první verzi funkčnosti, nasadím ji a ověříme ji v praxi. Při skutečné práci zjistíme, jestli pomáhá, kde něco chybí nebo co jsem při návrhu odhadl špatně. Druhý den se k ní vrátím a upravím ji podle toho, co jsme zjistili. Třetí den znovu. A tak pořád.
Takhle postupně zpřesňuju, co má produkt dělat a jak má fungovat. Každá nasazená verze nám umožní něco dalšího ověřit. Zkušenost z používání se vrací přímo do dalšího zadání a další změny.
Jedna z nedávných úprav DREEM se týká klientského zápisu z hovoru a e-mailu. Zápis lze schválit a zpřístupnit i tehdy, když u klienta nemáme e-mailovou adresu. Jeho publikování a navazující úkoly už na e-mailu nejsou závislé. Pokud adresa existuje, může na schválení navázat také odeslání e-mailu.
Je to malá změna, ale dobře ukazuje typ rozhodnutí, který při stavbě systému řeším. Zápis má vlastní hodnotu: zachycuje domluvu a další práci. E-mail je jeden ze způsobů, jak na něj klienta upozornit. Když tyhle dvě věci oddělím, proces si poradí s další běžnou situací.
Tenhle cyklus běží na několika frontách současně. U jedné části produktu právě ověřujeme první verzi, u jiné už zapracovávám zkušenosti z předchozích dnů. V Codexu se mezi nimi přesouvám podle toho, kde mám nové poznatky a co potřebuje další rozhodnutí. Každá z těch pěti až šesti věcí má vlastní průběh a opakovaně se k ní vracím.
AI mi umožňuje tenhle způsob práce držet v takovém rozsahu. Ze zkušenosti v provozu udělám zadání, s agenty připravím další verzi a po ověření ji nasadím. S Danem podle výsledku dál posouváme službu a já její fungování znovu promítám do softwaru.
Lidi ve firmě potřebují vědět, co se změnilo
Při tomhle tempu potřebuju udržet lidi ve firmě v obraze. Každý den přibývá několik změn a některé výrazně mění způsob práce. Aby je lidé mohli využít, musí vědět, co je nového a co teď funguje jinak.
Jednou z naplánovaných úloh je právě denní souhrn změn pro obchod a ostatní lidi ve firmě. AI v něm popisuje, co se od včerejška změnilo, z pohledu uživatele: co nově zvládne, jak se změnil pracovní postup, co najde jinak v rozhraní, na webu nebo v iOS aplikaci. Technické detaily nechává stranou.
Tím se snažím držet co největší informovanost o tom, kam se systém posouvá. Denní souhrn propojuje vývoj s lidmi, kteří jeho výsledky používají. Pomáhá jim zorientovat se v další verzi, kterou spolu zase ověříme v praxi.
AI zapojuju i do přípravy práce a dokumentů
Podobně přistupuju k rannímu přehledu. V systému existují úkoly, termíny, schůzky a komunikace, na kterou je potřeba reagovat. AI z tohoto kontextu může připravit přehled práce a upozornit na to, čemu je potřeba věnovat pozornost.
Tady jsem jí vymezil roli čtení a přípravy podkladu. Pracuje s dostupnými informacemi a pomáhá se v nich zorientovat. Aby měl takový přehled hodnotu, musím nejdřív zajistit, že úkoly a komunikace mají správné vazby a že se k nim agent dostane v odpovídajícím kontextu.
Dalším příkladem je vytěžení listu vlastnictví z PDF. AI pomáhá převést údaje z dokumentu do struktury, se kterou může aplikace dál pracovat. Kolem toho mám pravidla pro přiřazení ke správné nemovitosti, zachování už vyplněných hodnot a předání nejasností ke kontrole. Návrh předmětu převodu vyžaduje potvrzení člověkem.
I tady se potkává produktová práce s vývojem. Musím určit, které údaje potřebujeme, co lze doplnit a co musí zůstat k posouzení. AI dostane konkrétní úlohu uvnitř procesu, jehož podobu a pravidla navrhuju.
Za pravidla systému odpovídám já
Čím víc práce přes AI řeším, tím víc záleží na těchto rozhodnutích. Musím určit, jaký výstup je použitelný, kdo ho smí vidět, co se může provést automaticky a kde má někdo výslovně rozhodnout.
U klientského zápisu potřebuju možnost opravy a schválení. U dokumentu potřebuju zachovat už ověřené údaje. U ranního přehledu potřebuju rozpoznat, jestli má agent podklady, ze kterých může vycházet. Každá z těch situací má vlastní pravidla.
O tom, jak držím dlouho žijící procesy, jsem psal v článku Proč v DREEM používáme Temporal. Na tenhle základ teď navazuju konkrétními AI funkcemi. Stav případu, oprávnění a návaznost práce zůstávají součástí aplikace. AI do těchto procesů dodává zpracované informace a návrhy.
S Danem zároveň musíme vyhodnocovat, jestli změny dávají obchodně smysl. Dobře fungující technické řešení je užitečné teprve tehdy, když pomůže službě, kterou chceme poskytovat. Tuhle vazbu potřebuju při vývoji držet pořád.
Takto stavím systém pro AI-first firmu
Když o DREEM přemýšlím jako o AI-first firmě, vidím právě tohle propojení. S Codexem vyvíjím software podle toho, co potřebuje byznys. Uvnitř stejného softwaru pak zapojuju AI do konkrétní práce firmy. Zkušenosti z používání mi dávají podklady pro další změny.
Klient to pozná na obyčejných věcech. Má k dispozici domluvený postup. Ví, co potřebuje dodat. Člověk, který s ním komunikuje, může navázat na předchozí práci. Právě k takovému výsledku se snažím produkt dostat.
Dan dál řeší obchod, já produkt a vývoj. Každý den posouváme DREEM o další krok a ověřujeme v praxi, co jsme postavili. Na několika frontách současně, v přímém spojení s lidmi a skutečným fungováním firmy.
Pořád mě překvapuje, s jakou rychlostí a flexibilitou dokážeme měnit to, jak firma funguje. Ta práce je mentálně náročná a zároveň mě příšerně baví. Vidět, jak se nápad promění ve funkčnost, kterou lidé používají a kterou můžu hned dál zlepšovat, mi dává obrovskou energii. Miluju to.
