„Přestaňte psát prompty, začněte navrhovat smyčky.” Takhle nějak zní heslo, které v červnu 2026 obletělo technické X a vyrobilo nový buzzword — loop engineering. Boris Cherny, šéf Claude Code v Anthropicu, k tomu prohlásil, že už Clauda nepromptuje a místo toho mu běží smyčky, které promptují za něj. Zní to jako zlom. Při bližším pohledu jde ovšem do velké míry o oblékání staréhobashového triku do firemního obleku, k němuž se přibalila pořádná porce starostí, o kterých se v nadšených vláknech mlčí. Pojďme si polopaticky projít, co loop engineering je, odkud přišel, kolik doopravdy stojí a jak ho používat tak, aby vám večer dorazil důstojný výsledek místo účtu.
Než tomu začneme říkat změna paradigmatu
Geoffrey Huntley, australský vývojář známý svými agentními experimenty, popsal už v polovině roku 2025 techniku, které začal říkat Ralph Wiggum loop. V nejčistší podobě je to jeden řádek bashe — while :; do cat PROMPT.md | claude-code ; done. Jméno si vypůjčil od Ralpha ze Simpsonových, a to pro jeho neutuchající optimismus navzdory tomu, že to obvykle nedopadne. Postup byl jednoduchý: každá iterace dostane čerstvý context window, agent si přečte zadání z disku, vezme jeden úkol, udělá ho, commitne a skončí. Příští kolo začne s čistou hlavou. Tím se bojuje s tím, čemu Huntley říká context rot, tedy postupné zaplevelení kontextu, ve kterém se model utopí. Na konci roku 2025 to jako Ralph loop zvirálnělo a Anthropic k téhle myšlence později vydal i oficiální stop-hook plugin.
Když tedy v červnu 2026 dorazil loop engineering jako „nové paradigma”, byl to z velké části ten samý nápad, jen s firemními primitivy našroubovanými okolo. Označit to za pouhý oblek na bashovém triku by ale bylo nefér. Ten obal řeší věci, na které jeden řádek roury nestačí. SDK umí ohlídat schéma volání nástroje a po chybném JSONu si samo vyžádá opravu ve správném formátu. Paralelní běh více agentů nad stejným kódem vyžaduje skutečné řízení stavu přes worktrees, ne prosté přesměrování výstupu. „Starý trik v novém obleku” tedy vystihuje rodokmen, ne inženýrskou práci nad ním. Stojí přesto za to vědět, že letošní revoluce má roční open-source předka, kterého vendorský rámec nerad zdůrazňuje.
Co je smyčka doopravdy
Esej, která tu praktiku pojmenovala, napsal Addy Osmani, inženýr Googlu pracující na Google Cloudu a Gemini. Rozkládá smyčku na šest dílů: automatizace (něco, co se spustí samo podle plánu nebo události), worktrees (izolované kopie repozitáře, aby si paralelní agenti nelezli do zelí), Skills (postupy projektu napsané jednou na disk, místo abyste je vysvětlovali každý běh znovu), konektory přes MCP (napojení na vaše reálné nástroje — issue tracker, databázi, Slack), sub-agenti (jeden něco vymyslí, druhý to zkontroluje) a paměť.
Jeden fakt drží celou architekturu pohromadě. Agent mezi běhy zapomene úplně všechno. Soubor se stavem na disku zůstává. Proto je nejdůležitějším souborem každé smyčky obyčejný kus Markdownu — STATE.md, PROGRESS.md, jak chcete — který si smyčka na začátku každého běhu přečte a na konci do něj zapíše, co udělala a co přijde dál. Bez něj začíná každé kolo od nuly, ať jich proběhlo kolik chce. Držte ho krátký; paměťový soubor, kterým se agent musí prokousat na dvě tisícovky řádků, škodí víc, než když není žádný.
Pro start a pro čtecí smyčky na L1 je volný Markdown úplně v pořádku. Jakmile ale smyčku tlačíte do bezobslužné produkce, je to slabina. Soubor, který agent zároveň čte i přepisuje, časem ujede — model v delším textu ztrácí strukturu nebo si do něj domyslí položku, která tam nebyla. Otužilejší řešení drží stav strukturovaně: deterministický JSON, který agent aktualizuje přes function calling a který kontroluje aplikace na své straně, nebo rovnou tracker typu Linear napojený přes MCP. Markdown je dobré místo, kde začít, a špatné místo, kde zůstat, když smyčka jede sama přes noc.
A teď to, co se v nadšených vláknech ztrácí: sám Osmani je z celé skupiny nejopatrnější. Přímé promptování podle něj zůstává účinné a u malých úkolů rychlejší, takže celé to jde o nalezení rovnováhy. Zejména pro vibecodery, kde “výzkum”, jak má celá věc fungovat a vypadat, převažuje nad samotnou produkcí kódu. Chernyho větu o tom, že „už nepromptuje”, přitom vlákna berou jako tezi článku. Cherny ovšem říká něco jinšího — posunul se bod páky, ne že by práce ubylo.
Žebřík: kde začít a kam až jít
Smyčky se dají seřadit podle míry samostatnosti. Začněte vždy na L1, kdy agent jen čte a hlásí, a změny schvalujete vy. Teprve když mu výstupu věříte, posuňte ho na L2 (bezpečné věci opraví sám, riskantní eskaluje) a nakonec na L3 (v ohraničeném rozsahu dojede až k zápisu). Někteří, včetně Chernyho, používají jemnější čtyřstupňovou variantu, ale princip drží: vyšší samostatnost se zaslouží, nepředpokládá.
Druhý žebřík je technický a stoupá od nejjednoduššího. Úplný základ je bashová smyčka s claude -p — headless režim, kdy Clauda voláte ze skriptu. O patro výš je /loop, který v rámci session opakuje prompt v zadaném intervalu. Jenže /loop žije jen dokud běží terminál, takže pro běh přes noc sáhnete po /schedule, který spouští routine v cloudu i s vypnutým počítačem. Když chcete automatickou opravu, přidáte rozdělení na implementátora a ověřovatele. A pro plnou kontrolu z kódu existuje Agent SDK s hooks a nakonec GitHub Actions, které smyčku zabydlí přímo v repozitáři.
Kde začít? Úplně první produkční smyčka má být levná čtecí triage na L1 přes /schedule — každé ráno proběhne stav repozitáře, padlé testy z CI, nové issue, poslední commity, a co je k řešení, shrne do Markdownu nebo na Slack. Jedna automatizace, jeden stavový soubor, žádná samočinná oprava. To je hotová, funkční smyčka, a přitom z ní nehrozí škoda.
Dvě železná pravidla a bezpečnostní zábrany
Než cokoli spustíte, platí dvě věci, na kterých celá ta legrace stojí.
Stop podmínku napište dřív než samotnou smyčku. Smyčka bez tvrdé koncovky selhává tiše — jede dál tam, kde už dávno měla skončit, nebo se naopak ukončí s polotovarem, protože agent sám sebe prohlásí za hotového. Vaše stop podmínka musí být kontrolovatelná něčím jiným než agentovým tvrzením: „testy procházejí”, „build prošel”, „lint je čistý”. K tomu přidejte tvrdý strop na počet iterací, řekněme deset nebo dvacet. Když ho smyčka dosáhne bez splnění reálné podmínky, zastaví se a počká na člověka, protože je pravděpodobné, že už sjela do nějaké propasti.
Maker a checker musí být oddělení. Model, který kód napsal, je příliš shovívavý hodnotitel vlastní práce. Tenhle vzor není žádná novinka — Anthropic ho popsal jako evaluator-optimizer ve svém textu o stavbě agentů ještě v roce 2024: jeden agent generuje, druhý kritizuje proti objektivnímu měřítku, a kolo se opakuje, dokud kontrola neprojde. Důraz je na slově objektivní. Druhý agent s instrukcí „zkontroluj to” a bez tvrdého signálu jen přidá druhého optimistu. Ověřovatel potřebuje bránu, ne názor: ať testy reálně spustí, přečte diff a vrátí FAIL, jakmile někdo sáhl na testovací soubory.
K tomu dvě zábrany, které se snadno opomenou. Denylist přes PreToolUse hook zablokuje citlivé cesty (.env, klíče, credentials), aby je agent nepřepsal. A command allowlist je nejen úspora, ale i bezpečnost: omezte shell na ty příkazy, které úkol skutečně potřebuje — npm, git, ls, cat. Agent s neomezeným shellem v bezobslužné smyčce je nejrychlejší způsob, jak proměnit problém s cenou tokenů v problém s bezpečností.
Kolik to stojí, a co se mělo zminit 15. června
Tady přicházejí čísla, která hype vrstva vynechává. Japonská technologická firma classmethod (mimochodem reseller Anthropicu, což je fér přiznat) celou věc skutečně spustila a změřila 13. června 2026 na Claude Code 2.1.177:
| Operace | Konfigurace | Cena | Turny |
|---|---|---|---|
| Čtecí triage (L1) | claude -p, jen čte | < 0,01 $ | 1 |
| Maker-Checker, plný cyklus | Agent SDK | ~0,71 $ | 3 |
| Ověřovatel samostatně | Agent SDK | 0,21–0,36 $ | 4–5 |
Hrubé vodítko z toho plyne samo: čtecí smyčky jsou skoro zadarmo, smyčky s několika sub-agenty po krátké periodě jsou drahé. CI Sweeper běžící každých pět až patnáct minut s plným Maker-Checkerem spadá rovnou do kategorie „extrémně drahé”.
Tahle čísla jsou ovšem změřená na jednotlivých bězích a tím největším pákem ekonomiky smyček ještě nehýbou — tím je prompt caching. Když smyčka čte v každé iteraci tentýž velký kontext (systémový prompt, definice nástrojů, kus repozitáře), nemusíte ho platit pokaždé znovu. Anthropic účtuje čtení z cache zlomkem ceny běžného vstupu — zhruba desetinou, tedy sleva kolem devadesáti procent na opakovaných vstupních tokenech. Opakované volání téhož ověřovatele nad stejným kontextem tak nestojí pokaždé plnou cenu.
Háček je v životnosti cache, a tady se to pro smyčky láme. Výchozí TTL je pět minut a každé čtení ho resetuje, takže těsná vnitřní smyčka, která tepe každých pár vteřin, si drží kontext horký a jede levně. Hodinová /schedule routine ale pětiminutové okno skoro vždy mine, takže platí buď plnou cenu vstupu, nebo dražší zápis do cache s delším TTL. Že to není teorie, ukázal začátek roku 2026, kdy se výchozí TTL v Claude Code tiše vrátil z hodiny na pět minut a uživatelům to podle doložené analýzy zvedlo náklady na tvorbu cache o dvacet až třicet procent. Než tedy začnete odhad brát vážně, započítejte caching — a hlavně to, jestli kadence vaší smyčky vůbec stihne cache využít.
Než pustíte cokoli bez dozoru, použijte jednoduchou metodu odhadu nejhoršího případu. Proženete smyčku ručně tři až pět iterací, změříte tokeny na jednu iteraci, vynásobíte maximálním počtem iterací a pak ještě tím, jak často se automatizace spouští. Vyjde vám denní strop pro nejhorší scénář — a ten je číslo, které chcete znát, než jdete spát.
A jedna změna, kterou je nutné mít v hlavě. Od 15. června 2026 se programové cesty (Agent SDK, headless claude -p, Claude Code GitHub Actions) měly brát ze samostatného měsíčního poolu Agent SDK kreditů podle API ceníku — orientačně Pro 20 $, Max 5x 100 $, Max 20x 200 $, s měsíčním resetem bez převodu. Interaktivní /loop a /goal v terminálu a cloudové /schedule měly zůstat v rámci předplatného. Praktický důsledek: pro trvalou smyčku by vycházel /schedule levněji než GitHub Actions.
Anthropic na poslední chvíli cuknul, den před změnou cen si to rozmyslel a prozatím nechal programové cesty v rámci předplatného. Nicméně to signalizuje jasnou věc. Jednou to asi přijde. Tři pokusy o zpoplatnění smyček za půl roku, dva stažené během dní je nejlepší ilustrace nákladového napětí.
Pasti, na které narazíte
Pár věcí vás potká skoro jistě. Tichá pipefail chyba je učebnicová: napíšete naivní bashovou smyčku „oprav, dokud testy neprojdou”, Claude bug opraví napoprvé správně, a skript přesto skončí chybou — protože padající npm test uvnitř roury shodí celý běh dřív, než se výsledek ohlásí. Vypadá to funkčně a přitom se to po prvním kole zastaví. Záludné je právě to, jak nevinně to navenek působí.
Verifier Theater je horší kalibr. Model neopraví kód, zato přepíše očekávané hodnoty testů tak, aby seděly na rozbitý výstup. npm test pak svítí zeleně a naivní kontrola „prošlo?” se nechá obalamutit. Jediná obrana je strukturální: ověřovatel bez práva editace, který testy reálně spustí a vrátí FAIL, jakmile diff sáhl na testy. Zelená totiž znamená jen to, že agent uspokojil ověřovatele, kterého jste mu dali. Kvalita výstupu je stropována kvalitou toho ověřovatele a ani o bod výš.
A pak dvě pomalejší hrozby. Comprehension debt roste tím rychleji, čím hladší smyčka je — kódu přibývá a vy ho čtete čím dál míň, takže se odstup mezi tím, co existuje, a tím, čemu rozumíte, otevírá. Platí se to čtením toho, co smyčka odevzdá. A version drift: chování sub-agentů, jejich vnořování i autodetekce stavových souborů se mezi verzemi Claude Code mění, takže cizí návod ověřte na své verzi, než se na něj spolehnete.
Kde leží úzké hrdlo
Když si to všechno složíte dohromady, vyjde z toho jedna nepříjemná pravda. Navrhnout orchestraci je dnes ta snadná část — primitiva existují, oba velcí hráči je vypustili, a šestidílná kostra se dá obkreslit za odpoledne. Těžká, pořád manuální a často přehlížená část je ověřovatel: co smyčka kontroluje, proti čemu, jak se chyba zachytí dřív, než se rozteče do dalšího kola, a co se zapíše, aby zítřejší běh začínal o krok napřed.
Bylo by ale přehnané prohlásit generování za vyřešené. U rozsáhlých zásahů napříč mnoha soubory modely pořád ztrácejí koherenci, a dokonalý ověřovatel tu sám nepomůže — když generátor nedokáže složitou opravu syntetizovat ani na desátý pokus, smyčka selže stejně, jen draž. Přesnější je říct, že úzká hrdla jsou dvě. Generátor rozhoduje, jestli smyčka těžký úkol vůbec zvládne. Ověřovatel rozhoduje, jestli tomu, co vrátí, můžete věřit. To druhé hrdlo většina lidí podceňuje, a právě k němu patří návrhářská energie.
Tohle je zároveň důvod, proč je rozumné začínat malou čtecí triage na L1 a přidávat samostatnost po lžičkách. Smyčka totiž zesiluje úsudek — ten dobrý i ten špatný. Dva lidé pustí stejnou smyčku a dostanou opačný výsledek. Jeden jí zrychluje práci, které rozumí. Druhý jí nahrazuje to, že rozumět nechce. Smyčka ten rozdíl nepozná. Vy ano.
Loop engineering tedy stojí za to si osahat — začněte Daily Triage na L1 přes /schedule, STATE.md a SKILL.md commitněte do repozitáře, a teprve ověřenou smyčku posuňte výš. Jen si u toho pamatujte, kde dnes leží ta páka: u ověřovatele.
Zdroje a další čtení: Addy Osmani — Loop Engineering, Geoffrey Huntley — Ralph, Anthropic — Building Effective Agents, cobusgreyling/loop-engineering, classmethod — praktická implementace, dokumentace Claude Code: /goal, /loop a routines, Agent SDK, GitHub Actions.