Workflow a agentic loop

Mám si vypracoval postup, který se opakuje. Od chvíle, kdy si něco řeknu Claudovi, až do chvíle, kdy je věc hotová a ověřená. Není to chaos. Je to řada kroků, které vím, že fungují.

Začíná to výzkumem. Claudeovi řeknu, co chci. On se nejdřív podívá, jestli už něco podobného existuje. Pohledá si existující řešení, knihovny, přístupy. Pak si vytvoří plán — pořádný plán, ne jen intuici. Pak začne stavět. Pořád si ověřuje, jestli to funguje. Až je něco hotové, zkouším to sám.

Důležité je jedno: Claudeův mozek si po každé konverzaci nezachová nic. Tak funguje. Zato si on sám zapisuje poznatky, rozhodnutí a výsledky. V každé nové konverzaci si ten zápis přečte a pokračuje od tam, kde jsme skončili. To je to, čemu říkám agentic loop. Claude čte svoje poznámky a poupravuje si způsob práce.

Plánování

Než se začne něco stavět, přemýšlení přichází dřív. Řeknu Claudovi, aby si nejdřív vypracoval plán. Nechci, aby jednoduše začal psát. Chci vědět, jaké jsou kroky, co by se mohlo pokazit, jaké jsou varianty.

Plán říká: první se dělá tohle, pak támhle, pak se to testuje a ověřuje. Vidím všechna slabá místa dřív. Když pak Claudeův plán vidím, můžu mu říct: ne, tím krokem ne, zkus to jinak. Nebo: tohle je klíčový krok, víc se na ten soustředěte. Plan-first znamená, že příprava trvá déle, ale pak jde to rychleji a méně věcí se kazí.

Agenční týmy

Když je práce větší, nejsem sám s jedním Claudem. Řeknu si, aby si najal tým. Je to jako když máte projekt: jeden člověk nedělá všechno. Máte jednoho, co hlídá kód, jednoho, co testuje, jednoho, co píše dokumentaci.

Každý člen týmu dostane svůj kus práce. Jeden dělá strukturu, druhý obsah, třetí bezpečnost. Pracují vedle sebe. Jeden z nich pak zkontroluje práci druhého a řekne: tady vidím problém. To je užitečné. Když se dva agenti neshodnou, jeden z nich najde chybu. Týmy zrychluji práci. Detaily, které by jeden agent mohl přehlédnout, tým vidí.

Používám je hlavně na větší věci. Audit webového obsahu, testování bezpečnosti, vývoj několika modulů najednou. Malé věci nemusím na tým, ale když to jde někam, kde je víc možností nebo víc rizik, řeknu si: prosím, pět vás na to.

Kontext a paměť

Claude si pamatuje jednu věc velmi špatně: minulost. Konverzace skončí a všechno zapomene. Je to jako člověk s amnézií. Po každé konverzaci se paměť vymaže. To by bylo katastrofální, kdybych to neřešil.

Proto si vedle něj držím sešit. Pořádný sešit. Zapisuju do něj, co jsme dělali, co se povedlo, co se nezdařilo, jaká rozhodnutí padla. Jsou to jednoduché textové záznamy, bez něčeho zvláštního. Když pak s Claudem začínam novou konverzaci, on si ten sešit přečte a ví, kde jsme skončili. Není to halucinace ani omyl. Je to konkrétní zápis: dne X jsme dělali Y. Výsledek byl Z.

Mám dva takové sešity. Jeden je Notion — rychlý, dostupný všude. Zapisuju tam důležitá rozhodnutí a stav projektu. Druhý je Obsidian — hlubší. Tam žijí zápisky ze jednotlivých sezení, výzkumné poznatky, archiv toho, co funguje. Jsou to poznámky u mě na počítači, propojené a prohledávatelné. Když Claudeovi řeknu: kolik nás stojí ten hosting?, on si v Obsidianu sám najde odpověď. Nemusím ho o nic ptát.

Na začátku každé konverzace si Claudeův tým přečte všechno důležité. Všechny instrukce, všechny staré poznatky. Na Windows jsem si vytvořil speciální skript, kterému říkám session-bootstrap. Speciální rutina, která se spustí na začátku a řekne: tady je tvoje paměť. Tady je, kde jsme byli. Tady je tvůj tým. Tady je, co máš dělat. Od té doby, co to používám, je všechno jednodušší. Nic se neztratí.

Moje pravidla

Když se vám něco podaří, nebo když se vám něco pokazí, učíte se z toho. Já se naučil pár věcí těžkou cestou. Teď to zafixuju jako pravidla. Claudeovi je řeknu, a on je hlídá.

Pravidlo jedna: vždycky jedna změna najednou. Neudělejte tři věci v jednom commitu. Udělejte jednu, otestujte ji, pak druhou. Když se něco pokazí, hned víte, kde. Kdybyste dělal všechno najednou a pak se to sesypalo, házíte si kostkami. Neznáte příčinu.

Pravidlo dvě: nikdy netlač na tlačítko bez zálohování. Než změním něco důležitého, udělám si kopii. Trvá deset sekund. Kdyby se to pokazilo, mám se vrátit zpět. To je základní věc, ale opravdu to pomáhá. Udělal jsem si skript, co to automatizuje.

Pravidlo tři: nikdy netvrď, že věc funguje, když jsi ji nezkoušel. Neřekni si: je to bez problémů. Zkus to. Klikni na to. Spusť to. Podívej se, jestli dělá, co má. Dělám věci přes Claude Code — to je aplikace na počítači, textové okno, do kterého píšu Claudovi. Jeho kód běží na mojím počítači, a já vidím, co se děje. Takže vždy vidím, funguje to, nebo se to pokazilo.

Pravidlo čtyři: hledej kořen problému, ne příznak. Řekne mi někdo: něco laguje. Neřeknu si: prosím, zkusme to zrychlit tady a tady. Řeknu si: co to dělá lagovat? Je to CSS animace? Je to databáze? Je to síť? Najdu to nejdřív. Pak to opravuji. Bez toho bych jen slepě hádal a nikam bych nešel.

Pravidlo pět: ověř si konkrétně, ne pocitem. Neřeknu si: v prohlížeči to vypadá dobře. Otevřu si Chrome Developer Tools. Podívám se na čísla. Otestuju to na telefonu. Naměřím si FPS. Konkrétní číslo je vždycky lepší než dojem.

Tahle pravidla jsou detailně popsána v Na co si dát pozor. Jsou tam, protože mi opravdu pomáhají. Jdou je naučit Claudea taky.

Ověřování a debugging

Když je něco hotové, nepůjdu si tomu věřit hned. Zkusím to. Všechny části. Starty, konce, chybové hlášky. Jak se to chová, když se něco pokazí. Jak se to chová, když tam dám špatný vstup. Jak se to chová, když ho zneužiji.

Debugging je hledání toho, co se pokazilo. Mám na to svoje kroky. Nejdřív se podívám, kde to páchne. Pak udělám hypotézu: myslím, že je to tady. Pak ji otestuju. Často se mýlim, takže hypotézu zmením a zkusím znovu. To je lepší, než slepě hádát a jen léčit příznaky.

Claudeův tým to dělá taky. Když něco naprogramuje, hned to testuje. Nejen: je to bez syntaktické chyby. Ale: opravdu to dělá, co má? Opravdu se to hraje se zbytkem kódu? Když to testuje a najde chybu, mě o tom řekne. Pak to spolu opravujeme. Příklad: jednou jsem měl web, kterého jsem dělal přes agenty. Nějakou dobu se to měnilo a měnilo. Pak jsem si řekl: počkej, jak to opravdu vypadá? Otevřel jsem si Chrome DevTools a měřil jsem výkon. FPS se pohybovaly kolem 11. Proč? Podíval jsem se pod pokličku. Našel jsem animace, co se stále překreslují. Smazal jsem tu animaci, a výkon se vrátil na 26 FPS. Bez měření bych to neviděl.

Jak hledám novinky

Věci se v tomto oboru mění rychle. Měsíc se nic nezmění, pak náhle je tam pět nových věcí. Proto musím vědět, co se děje. Nechci mít tři měsíce starý model a myslet si, že je to novinka.

Mám si způsoby. První: čtu články a vědecké papery. Mám na to příkaz, kterému říkám deep-research. Řeknu: najdi mi články o tom, jak agenti řeší problém X. Claudeův tým si je najde, přečte je, udělá z toho souhrn. Ušetří mi to hodiny čtení.

Druhý: YouTube. Tady se stává hodně věcí. Jsou lidi, co si hrají s novými modely dřív, než se to dozvědělo ostatní. Najdu si jejich videa a často si jich nechám přepsat, aby je Claudeův tým mohl analyzovat. Používám na to NotebookLM — Google nástroj, který vezme video nebo článek a řekne, co je tam nejdůležitého.

Třetí: sleduju lidi. Faborský, Oborník a další tvůrci. Oni jsou vždycky o krok dál. Když vidím, co oni dělají, vidím, kam se to všechno posouvá. Nedělám to proto, aby mě to ovlivnilo. Dělám to, abych věděl, co se děje.

Čtvrtý: Claudeův tým si taky hlídá změny. Když Anthropic něco změní v modelu, já to vidím. Když se něco zásadního změní v práci s agenty, Claudeův tým mě na to upozorní. To je rychlejší, než čekat na článek o tom. Je to jako mít osobního výzkumného asistenta, co sedí vedle a vypráví vám, co se děje.

Tenhle postup není cílový stav. Vyvíjí se. Letos jsem to měnil víckrát. Ale základy — plán, tým, paměť, pravidla, ověřování — to zůstává. Není to technika, co bych si vypůjčil od někoho. Je to věc, kterou jsem si přizpůsobil na sebe a co mi sedí.