Konec s promptováním, ahoj smyčkám: jak jsem přestal být řidičem AI agentů

Před měsícem Peter Steinberger napsal tweet, který nasbíral osm milionů zobrazení: „Neměli byste už promptovat AI agenty. Měli byste navrhovat smyčky, které promptují vaše agenty." Přibližně ve stejnou dobu řekl Boris Cherny — tvůrce Claude Code — něco podobného v podcastu Acquired Unplugged: „Já už Claude nepromptuju. Mám běžící smyčky. To jsou ty, které promptují Claude."

A pak se stalo to, co se na internetu děje vždycky: všichni se hádali, nikdo neviděl žádnou smyčku, a diskuze se proměnila v chaos abstrakcí.

Já jsem několik posledních měsíců skutečně provozoval reálné smyčky. Ne proto, že bych byl ahead of the curve — jednoduše jsem měl dost té manuální práce s triáží a tak jsem ji zautomatizoval. Co jsem zjistil, mě překvapilo: smyčkové myšlení není žádná pokročilá technika pro AI power usery. Je to přirozená evoluce, ke které dojde ve chvíli, kdy přestanete zacházet s AI agenty jako s chytrými copy-pastery a začnete je vnímat jako systémy, které dokážou monitorovat, rozhodovat a jednat vaším jménem.

Tři druhy „smyčky", na které nikdo nemá jednotný názor

Tady je důvod, proč je celá ta konverzace taková zmatená: když lidé říkají „smyčka", můžou myslet jednu ze tří věcí a rozdíly mezi nimi jsou podstatné.

Zaprvé, existuje autonomní task loop — v podstatě „pokračuj, dokud to není hotové". Představte si Geoffrey Huntleyho Ralph script (while :; do cat PROMPT.md | claude-code; done), nebo příkaz /goal, který dnes Claude Code a Codex nabízí nativně. Tohle je ten „nastav a zapomeň" režim.

Zadruhé, existuje scheduled nebo event-driven loop — práce, která běží, zatímco vy nejste u stolu. Steinbergerův vlastní HEARTEBEAT.md v OpenClaw je klasický příklad: checklist, ke kterému se agent vrací každých 30 minut. Potomci tohoto patternu zahrnují Codex automatizace a scheduled rutiny v Claude Code.

Zatřetí, existuje orchestration fan-out — dynamické workflow s více agenty běžícími souběžně. Claude Code operace ve stylu map/reduce spadají sem. To je blíž actor modelu než čemukoliv, co připomíná jednoduchou smyčku.

Moje interpretace? Steinberger a Cherny popisují druhý typ, napojený na první. Smyčky, které provozuju já, jsou scheduled a event-driven na povrchu, a několik z nich executuje experimentální inner loops, když se spustí. Tahle kombinace je místo, kde se skrývá skutečný leverage.

PR Babysitter: Moje vstupenka do světa loop designu

Už jsem měl AI code review na každém pull requestu. Nejprve reviewnul Claude, pak Codex built-in review, a pak custom GitHub Action, kde jsem kontroloval přesně, co model vidí — stahoval jsem celý kontext konverzace spolu s patch diffem.

Moje skutečný workflow byl absurdní: submitnu PR, počkám na review, a pak copy-pastnu review comments do agenta. Někdy jsem tam vkládal i screenshots. Manuální, repetitivní, a kills my soul.

Jednoho dne jsem agenta zeptal: „Nemůžeš prostě použít gh klienta a sám zkontrolovat status review?" Mohl. Takže logicky: „Nemůžeš prostě pořád kontrolovat a říct mi, až to bude hotové?"

Ten jeden požadavek proměnil celý můj workflow. Agent teď sleduje změny statusu review, stahuje nový kontext, analyzuje feedback a dělá skutečnou práci — addressuje ho. Smyčka končí, když dospěje k triage rozhodnutí: přijmout feedback, pushbacknout na něj, nebo eskalovat ke mně.

Pattern se krásně zobecňuje: sleduj změny stavu v externích systémech, probouzej se, když nastanou, stáhni čerstvý kontext, analyzuj, jednej a triageuj. Jakmile ten tvar jednou uvidíte, začnete ho nacházet všude. Codex team shipuje vlastní babysit-pr skill a dokumentace Claude Code dnes jmenuje PR babysitting jako headline use case pro jejich příkaz /loop.

Inner loops: Nechat agenta spouštět vlastní experimenty

Existuje ještě jeden smyčkový pattern, který mi déle trvalo ocenit: experiment loop. Andrej Karpathyho koncept autoresearch mě k tomu přiměl — spouštět mnoho iterací, měřit výsledky, nechat to, co funguje. Namířil jsem to na pomalou Python path a spustil 49 experimentů za hodinu, přičemž p95 latence klesla z 339ms na 34ms za přibližně 24 dolarů.

Stejný pattern se dá aplikovat na tvrdší problémy: debugging agentího chování v produkci. Když se něco pokazí — divný trace v Braintrust, user feedback ve Slacku, nebo něco, co jsem potkal sám — rozjedu worktree, vložím trace a invoknu test loop.

Tady je to, co dělá tenhle loop jiný: nutí to k disciplíně, proti které se modelova naivní intuice brání. Když ho necháte být, model hardcoduje „nikdy nedělej X, Y, Z" do system promptu a overfittuje na ten jeden trace, který jste mu ukázali. Skill references distillují research na to, proč ten přístup selhává, a smyčkový kontrakt vyžaduje hypotézu a test matrix.

Potřebuju tři případy: původní selhávající případ, sousední pozitivní případ, který by měl jít stejnou cestou, a counterexample, který by měl jít cestou jinou. Tři nebo čtyři probes běží souběžně proti local dev, reconstituing exact user context z trace. Každý run se scoruje na tool calls, latenci, input-token delta a správnost. Model nemůže cheatovat memorováním — musí skutečně porozumět.

Co se skutečně změní, když začnete stavět smyčky

Největší posun není technický — je konceptuální. Když promptujete agenta, pořád jste ten, kdo řídí. Jste throttle, navigator, quality checker. Smyčky to invertují. Stáváte se architektem systémů, které řídí samy sebe.

To neznamená, že full autonomie je cíl. Pořád jsem u triage gate na všem důležitém. Smyčky obstarávají tu úmornou práci, monitoring, repetici. Já obstarávám judgment calls, které skutečně záleží.

Druhá změna je, že smyčky vás nutí být explicitní ohledně success criteria. Dobrá smyčka má jasné exit conditions, jasné decision points, jasné escalation paths. Nemůžete postavit smyčku bez definice toho, jak vypadá „hotovo". Ta disciplína se přelévá do všeho ostatního.

Třetí: smyčky jsou composable. PR babysitter funguje vedle experiment loopu. Scheduled checks spouští on-call responses. Začnete budovat knihovnu chování, která spolupracují, místo hromady one-off promptů.

Praktický startovní bod

Pokud chcete experimentovat se smyčkami, začněte s něčím, co už máte špatně automatizované. Pravděpodobně máte GitHub Action, která něco dělá na schedule, nebo Claude Code session, kterou manuálně re-runujete, nebo review proces, který zahrnuje copy-pasting výstupů mezi nástroji.

Vyberte ten nejpříšernější. Zeptejte se sami sebe: jakou změnu stavu vlastně čekám? Jaký kontext agent potřebuje, až ta změna nastane? Jaké rozhodnutí musí udělat?

Pak postavte smyčku. Nemusí být elegantní. Musí fungovat a musí vám vrátit kontrolu nad vlastním časem.

Kompletní konfiguráky, skills a CI workflow za smyčkami, které provozuju, jsou ve veřejném snapshot repozitáři: camwest/agent-skills. Není to polished produkt — je to working system, který se vyvíjí spolu s tím, jak se učím. To je pointa. Smyčky nejsou destination; jsou to practice.

Discourse kolem AI agentů se topí v abstrakcích. Tady je ta konkrétní verze: přestaňte promptovat, začněte stavět smyčky, a sledujte, co se stane, když necháte mašinu obstarávat monitoring zatímco vy obstaráváte meaning.