# Loop engineering: the 14-step roadmap from prompter to loop designer. Lev Deviatkin (2026-07-06) > **Cikk:** *Loop engineering: the 14-step roadmap from prompter to loop designer* • **Szerző:** Lev Deviatkin (LinkedIn: linkedin.com/in/lev-deviatkin) • **Forrás:** • **Publikálva:** 2026-07-06 • **Platform:** Agent Cookbook (Beginner szint) • **Hossz:** 3746 szó > **Forrásanyagok:** Anthropic engineering docs, Addy Osmani long-form on loop engineering, AlphaSignal analysis, Geoffrey Huntley („Ralph Wiggum loop”) --- ## A lényeg Az Agent Cookbook 2026-07-06-i cikke (Lev Deviatkin) a promptolásról a **loop design-ra** való átállás 14 lépéses roadmapjét mutatja be. A kiindulópont: **9/10 builder sosem írt loopot**, a legtöbb fejlesztő még mindig kézzel promptolja a coding agent-eket, miközben az **áttétel-pont** átmozdult a promptolásról a loop design-ra. A cikk három tier-ben szervezi a 14 lépést: (1) **The Why & The Test** (1-4. lépés, miért érdemes loopot építeni, és a 4-condition test), (2) **The 5 Building Blocks** (5-9. lépés, automations, worktrees, skills, connectors, sub-agents), (3) **Build It Right or Don't Build It** (10-14. lépés, state file, minimum viable loop, Ralph Wiggum loop, comprehension debt, security tax). A cikk hangsúlya: **a legtöbb fejlesztőnek még NEM kell loopot építenie**, a 4-condition test egyike sem teljesül, ha a feladat nem ismétlődik, nincs automatizált verifikáció, vagy a token budget nem bírja a waste-et. --- ## 1. A loop engineering paradigmaváltás A 2024-es év coding agent-ekkel való munkája így nézett ki: promptot írsz, contextet osztasz meg, olvasod a választ, írod a következő promptot. Az agent **eszköz volt**, és te tartottad az egész idő alatt. Ez a fázis véget ér. **Loop engineering = egy kis rendszert építesz, amely megtalálja a munkát, átadja az agent-nek, ellenőrzi az eredményt, rögzíti a történteket, és önállóan dönt a következő lépésről.** A rendszert egyszer megtervezed, és a rendszer promptolja az agent-et onnantól kezdve. Az Anthropic mérnökei most **nyolcszor annyi kódot mergelnek naponta**, mint 2024-ben, ez a szám vitatott, de a mechanizmus nem: az **áttétel-pont** átmozdult a promptolásról a loop design-ra. A cikk Addy Osmani hat részre bontását idézi: a loop megtalálja a munkát, promptolja az agent-et, ellenőrzi az eredményt, rögzíti a történteket, és dönt a következő lépésről, mindezt önállóan, az engineer „bérbe adja” a döntést a rendszernek. ## 2. A 4-condition test, mielőtt bármit építesz A loop engineering nem univerzális. A 4-condition test eldönti, hogy érdemes-e loopot építeni: **1. A feladat ismétlődik.** A loop a setup költségét sok futásra amortizálja. Egyszeri munkára egy jó prompt gyorsabb és olcsóbb. Ha a munka nem ismétlődik hetente, nincs loop, csak egy script, amit egyszer futtattál. **2. A verifikáció automatizált.** A loopnak kell valami, ami a mérnök nélkül is el tudja utasítani a rossz outputot. Tesztsuite, type checker, linter, build. Automatikus check nélkül visszakerülsz a székbe, és minden diff-et olvasol, pont azt a munkát, amit a loopnak el kellene végeznie. **3. A token budget elbírja a waste-et.** A loopok újraolvassák a contextet, retry-znak, explorálnak. Ez égeti a tokeneket, függetlenül attól, hogy a futás szállít-e bármit. A technika a budgettel skálázódik, ezért tűnik „nyilvánvalónak” azok számára, akiknek ingyen vannak a tokenjeik, és „vakmerőnek” azok számára, akik metered plan-en vannak. **4. Az agent senior engineer eszközökkel rendelkezik.** Logok, reprodukciós környezet, a kód futtatásának képessége. Enélkül a loop vakon iterál. **Aki nyer:** ismétlődő, machine-checkable munkát végző csapatok (CI failure triage, dependency bumps, lint-and-fix passes, issue-to-PR drafts), erős teszt suite-tal rendelkező codebase-ek, async-first multi-agent mintákat használó csapatok. **Aki kimarad:** solo builder-ek consumer plan-en, automated verifikáció nélküli kódbázisok, review capacity-hiányos csapatok (a loop több kódot generál, de a review marad a szűk keresztmetszet). ## 3. A 30-second loop check A 4-condition test a stratégiai döntés. A 30-second loop check a taktikai checklist, amit egy konkrét feladatra futtatsz, mielőtt loopot csinálsz belőle: - A feladat legalább hetente történik (kevesebb = setup cost soha nem amortizálódik) - Automatikus gate van (teszt, type check, build, linter), nélküle az agent saját házi feladatát javítja - Az agent futtatni tudja a kódot, amit módosít (reprodukciós környezet) - A loopnak van hard stop-ja (token budget, iteration count, time limit) - Human review merge, deploy vagy dependency change előtt (irreverzibilis action-ok emberi approval gate-et igényelnek) **Jó első loopok:** CI failure triage (nightly, classify, draft fix PRs), dependency bump PRs (weekly), lint-and-fix passes (PR open event-re), flaky test reproduction, issue-to-PR drafts. **Rossz első loopok:** architecture rewrites, auth/payments kód, production deploys, vague product work, bármi, ahol a „done” ítélet kérdése. ## 4. Az 5 építőkocka A 2. tier az 5 építőkockát mutatja be: **automations, worktrees, skills, connectors, sub-agents**. Ezek együttesen alkotják a loopot. ### 4.1 Automations, a szívverés Az automation az, ami a loopot **tényleges loop-pá** teszi, nem egyszeri futássá. Schedule-re, event-re vagy trigger condition-re fut. Minden más a loopban erre épül. - **Codex:** Automations tab, project, prompt, cadence, local checkout vagy background worktree. A triage inbox-ba landol, ami talált valamit; ami nem, archíválja magát. - **Claude Code:** három primitív, `/loop` session-scoped cadence-hez, Desktop scheduled tasks restart-survival-hoz, Routines laptop-off cloud runs-hoz, hooks lifecycle event-ekhez. Két fontos primitív az automation belsejében: `/loop` újrafut egy cadence-en (regular checks regardless of state); `/goal` addig megy, amíg egy általad írt condition ténylegesen teljesül (a stop condition-t egy külön kis modell ellenőrzi, tehát az agent, amelyik a kódot írta, nem ugyanaz, mint ami osztályoz). Ez a **maker-vs-checker split** alkalmazva a stop condition-re. ### 4.2 Worktrees, párhuzamosság káosz nélkül A második, hogy egynél több agent fut, a fájlok ütközni kezdenek. Két agent ugyanazt a fájlt írja ugyanaz a fejfájás, mint két mérnök ugyanazokat a sorokat írja anélkül, hogy beszélnének. A **git worktree** megoldja: külön working directory saját branch-en, közös repo history-val, az egyik agent szerkesztései szó szerint nem érhetik el a másik checkout-ját. Codex beépíti a worktree supportot (több szál ugyanazt a repo-t egyszerre), Claude Code közvetlenül exponálja a `git worktree`-t, `--worktree` flag a session saját checkout-jában, `isolation: worktree` setting a subagent-eken. A worktree-k kiveszik a mechanikai ütközést, de **te maradsz a ceiling**: a review bandwidth-ed dönti el, hány párhuzamos agent-et tudsz futtatni. ### 4.3 Skills, egyszer írd meg a projekt tudást A Skill az, hogy ne magyarázd el újra és újra ugyanazt a projekt kontextust minden session-ben, mint egy aranyhal. Mindkét eszköz ugyanazt a formátumot használja: egy mappa, benne egy `SKILL.md` (instructions és metadata), opcionális `scripts`, `references`, `assets` mappákkal. A loop szempontjából: a skill nélküli loop minden ciklusban nulláról rebuild-eli a teljes projekt kontextust. A skill-lel az intent **kompoundol**: a convention-ök, build lépések, „nem így csináljuk, mert az az egy incidens” — egyszer leírva kívül, minden futás által olvasva. A cikk egy `ci-triage` skill példát mutat be YAML formátumban (classification rules: env/flake/bug/dependency/infra; fix patterns; never do lista; state update). ### 4.4 Connectors, a loop a valódi eszközeidet érinti A loop, amelyik csak a fájlrendszert látja, kicsi loop. A **connectors** (MCP, Model Context Protocol) lehetővé teszik, hogy az agent olvassa az issue tracker-t, adatbázist kérdezzen, staging API-t hívjon, Slack üzenetet dobjon. Codex és Claude Code egyaránt beszélnek MCP-t, tehát az egyikhez írt connector általában működik a másikban is. A cikk szerinti leggyorsabban megtérülő connectorok: **GitHub** (read repos, create branches, open PRs, comment on issues, react to webhook events), a single biggest day-one win; **Linear vagy Jira** (update tickets, link PRs, close items automatically); **Slack** (post triage results, ping humans on escalations, summarize overnight runs); **Sentry / error tracker** (investigate live alerts, draft fixes). Ezek azok, amelyek a loopot „itt is tud csinálni valamit” szintről „az egész környezetedben tud cselekedni” szintre emelik. ### 4.5 Sub-agents, a maker-t tartsd távol a checker-től A loop leghasznosabb strukturális eleme: **szétválasztani az agent-et, amelyik ír, attól, amelyik ellenőriz**. Osmani framingje pontos: a modell, amelyik a kódot írta, „way too nice grading its own homework.” Egy második agent, más utasításokkal és néha más modellel, elkapja azt, amit az első kimagyarázott magának. Ez az **evaluator-optimizer pattern** az Anthropic 2024. decemberi engineering posztjából, új néven. Codex és Claude Code egyaránt támogatják: Codex TOML fájlokban definiálja a sub-agent-eket (`.codex/agents/`), Claude Code subagent-eket és agent team-eket használ (`.claude/agents/`). A szokásos split: egy agent explorál, egy implementál, egy verifikál a spec ellenében. A loop szempontjából: a loop akkor fut, amikor **te nem nézed**, és egy verifikáló, akiben tényleg megbízol, az egyetlen ok, amiért el tudsz menni. A sub-agent-ek több token-t égetnek (mindegyik saját modell- és tool-munkát végez), csak ott költsd őket, ahol egy második vélemény megéri az árat. ## 5. A state file, az agent felejt, a fájl nem Ez az elem, ami túl butának hangzik ahhoz, hogy számítson, pedig **minden működő loop gerince**. Markdown fájl, Linear board, JSON state, bármi, ami a single conversationön kívül él, és tartja, hogy mi kész és mi következő. **Az agent rövid távú memóriával rendelkezik.** Ami ezen a sessionön tanul, holnapra eltűnik, hacsak le nem írod. Osmani szabálya: az agent felejt, a repo nem. State nélküli loop minden futáskor újraindul; state-tel a loop **folytatódik**. A cikk egy `STATE.md` példát mutat be JSON formátumban: last run (date, classified, drafted, escalated), in progress (PR-ok állapota), completed today, escalated to humans, lessons learned (write here, not in chat), stop conditions met since last review. Két minta a state file helyére: **markdown a repóban** (STATE.md a root-ban vagy .claude/ alatt, version-controlled, simple, diff-readable, solo vagy kis csapat), vagy **külső rendszer** (Linear, GitHub Issues, database, survives across repos, queryable, team-wide visibility, production loop-ok). Hosszan futó loopoknál, amelyek elcsúszhatnak a goal-tól, a state file-t **párosítsd egy standing high-level spec-vel** (VISION.md vagy AGENTS.md), amit az agent minden futáskor újraolvas. A state megmondja, hol van az agent. A spec megmondja, hová tartson. ## 6. A minimum viable loop Ha a 4-condition test-et teljesítetted, **a legkisebb loopot építsd, ami működik**, mielőtt bármi fancy-t. Négy rész, nincs swarm. A négy rész egyszerű nyelven: 1. **Egy automation**, schedule-elt futás, ami cadence-en tüzel és tiszta condition-nél leáll. `/loop` Claude Code-ban vagy automation Codex-ben. `/goal` párosítva, ha azt akarod, hogy a loop addig fusson, amíg egy kimondott condition teljesül. 2. **Egy skill**, egyetlen SKILL.md, ami a projekt kontextust tárolja, amit az agent egyébként nulláról rebuild-elne minden futásnál. 3. **Egy state file**, markdown fájl vagy Linear board, ami rögzíti, mi kész és mi következő. A holnapi futás folytatja, nem újrakezdi. 4. **Egy gate**, a teszt, type check vagy build, ami automatikusan elutasítja a rossz munkát. Ez dönti el, hogy a loop segít-e vagy csak költ. **A sorrend számít:** előbb legyen egy manual run reliable, aztán alakítsd skill-lé, aztán wrap-eld loop-ba, aztán schedule-eld. A skip-ahead az, ahogy a loopok elbuknak a production-ben. A mérőszám, ami számít: **cost per accepted change**, nem az elköltött token, nem a kísérletek száma, nem a schedule-elt loop-ok száma. Ha az accepted-change rate 50% alatt van, review-munkát végzel, amit a loop megtakarított volna, és a loop veszít. ## 7. A Ralph Wiggum loop, a csendben elbukó loop Geoffrey Huntley mérnök dokumentálta és nevezte el ezt a failure mode-ot. Egy agent, amelyik completion token-t kellene kiadjon, csak amikor befejezte, **korán adja ki**, és a loop félkész munkán lép ki. Hard gate nélkül a loopok csendben buknak el és költenek tovább. A Ralph Wiggum loop akkor történik, amikor: - **Nincs valódi verifikáló**, csak egy második agent, akit „review”-ra kértek, nincs objectív signal. Két optimista egyetért. - **Lágy completion condition-ök**, a „done” az agent ítélete, nem teszt, build vagy type check. - **Nincs hard stop**, a loop addig megy, amíg valami külső le nem állítja (rate limit, te észreveszed), nem amíg a siker verifikálódik. A javítás a **step 11-ből jövő gate**, valami objectív, ami el tudja utasítani a munkát. Egy teszt, ami átmegy vagy elbukik. Egy build, ami lefordul vagy nem. Egy linter, ami nullát vagy nem-nullát ad vissza. Nem egy verifikáló, akinek van véleménye. Más mért failure mode-ok, amiket érdemes ismerni: - **Goal drift hosszú session-ökben**, minden summarization step lossy; a „ne csináld X” constraint-ek eltűnnek a 47. turn-re. Mitigation: standing VISION.md vagy AGENTS.md, újraolvasva minden futásnál. - **Self-preferential bias**, az agent, amelyik a kódot írta, túl kedves a saját házi feladatát javítva. Mitigation: külön verifikáló subagent, akinek nincs exposure-a a maker reasoning-jéhez. - **Agentic laziness**, a loop „elég done”-nak nyilvánítja a részleges completion-t. Mitigation: `/goal` objectív stop condition-nel, friss modell által ellenőrizve. ## 8. Comprehension debt and cognitive surrender Ez a failure mode, amelyik **élesedik, ahogy a loop jobb lesz, nem rosszabb**. Két named risk Osmani esszéjéből: - **Comprehension debt.** Minél gyorsabban szállít a loop kódot, amit nem te írtál, annál nagyobb a távolság a repo tartalma és a te megértésed között. A számla, ami fáj, nem a token számla, hanem az a nap, amikor egy rendszert kell debug-olnod, amit a csapat egyetlen tagja sem olvasott. - **Cognitive surrender.** A húzás, hogy ne formálj véleményt, és elfogadd, amit a loop visszaad. A loop design a gyógyszer, ha **ítélettel** csinálod, és a gyorsító, ha **gondolkodás elkerülésére** csinálod. Ugyanaz az akció, ellentétes eredmény. A mitigációk nem technikaiak: - **Olvasd a diff-eket.** Ha nem olvasod, amit a loop szállít, comprehension debt-et bérlesz compound interest-re. - **Spot-check a gate-et.** Válassz néhány PR-t, amit a loop nyitott, és ellenőrizd, hogy a teszt, ami jóváhagyta, tényleg elkapja-e azt a failure mode-ot, ami érdekel. A gate-ek rotálódnak. - **Blokkold a loop-ot az architecture work-ről.** Tartsd kis, machine-checkable változásokon. Amint megengeded, hogy ítélet kérdéseit érintse, a comprehension debt gyorsul. - **Pair-design loop-ot egy teammate-tel.** Egy második szempár a loop design-jánál elkapja a vakfoltokat, amiket a loop egyébként örökre kihasználna. ## 9. A security tax, a felügyelet nélküli loop felügyelet nélküli attack surface A loop unattended futása unattended attack surface. A threat model, amelyet a loopnak védenie kell: - **Generált kód unreviewed shipping.** A loop PR-eket nyit gyorsabban, mint egy ember olvasni tudja. Gate nélkül, amelyik security check-eket tartalmaz (SAST, dependency audit, secret scanning), insecure kód mergel automatikusan. - **Skills mint injection vektorok.** Egy loop, amelyik auto-installálja a skill-eket, örökli a description-jeikben rejtőző prompt injection-öket. Auditáld a skill forrásokat, mielőtt installálod. - **Credentials a logokban.** Debug logging hosszan futó loop alatt szétszórja a titkokat olyan logokban, amiket nem monitorozol. Disable verbose logging production loop-okban; sanitize, ami logolódik. - **Permission scope creep.** Egy loop, amelyik read-only permission-ökkel lett tesztelve, kap „csak egy” write permission-t kényelmi okokból, aztán soha többé nem auditálódik. Re-auditald a permission-öket 30 naponta. A cikk végén a „mistakes that turn loops into money pits” lista nyolc gyakori hibát sorol fel: loop építése a 4-condition test nélkül, nincs objectív gate, egy agent ír és verifikál, nincs state file, vague stop condition-ök, nincs token budget cap, consumer plan-en heavy verification, community skill-ek auto-installálása, loop-ok judgment-call work-ön, diff-ek nem olvasása. ## 10. A cikk Henky-szempontú jelentősége Ez a cikk a **frontier AI engineering** kategóriájának egyik legjobb 2026-os összefoglalója. A 14-step roadmap konkrét, mérhető, és a Henky által használt eszközökre (Codex, Claude Code) közvetlenül alkalmazható. Az ai-automation topic szempontjából öt szál a fontos: 1. **A promptolásról a loop design-ra váltás paradigmaváltása.** A Henky-ágenst használó podcast-processing pipeline már most is használ loop elemeket (sub-agent-ek, verifikáló auto-review, state file-ok a golden dataset-ben), és ez a cikk rendszerezi a jövőbeli fejlesztési lehetőségeket. 2. **A 4-condition test, mint döntési keretrendszer.** A 4 feltétel (ismétlődés, automatizált verifikáció, token budget, senior engineer tools) alkalmazható bármely agent engineering projektre. A cikk explicit tanácsa: „most developers don't need it yet” — ez összhangban van Henky saját SOP-jával, ahol a komplexitás-bevezetés előfeltétele a bizonyított haszon. 3. **A 5 építőkocka (automations, worktrees, skills, connectors, sub-agents) reusable pattern.** Ezek a komponensek a Henky saját agent-cookbook-jában is használhatóak, és a cikk konkrét eszköz-referencia-kat (Codex/Claude Code) ad. 4. **A Ralph Wiggum loop, comprehension debt, és a security tax, mint failure mode-ok.** A 14. lépés security tax különösen releváns a Henky privacy/security vonalán, a skill injection vektorok és a permission scope creep a loop engineering egyik legnagyobb kockázata. 5. **Az „agent forget, the file does not” alapelv a state file-ról.** A podcast-processing pipeline-ban a golden dataset, a MEMORY.md, és a topic file-ok a state file analógjai. A loop engineering szisztematizálja ezt a megközelítést. A cikk értéke: egy 3746 szavas, 14 pontos, gyakorlat-orientált tutorial, amely a promptolás paradigmaváltásától a loop design konkrét építőkockáin át a failure mode-okig és a security tax-ig terjed. A Henky által követett ai-automation vonalhoz több szálon kapcsolódik, és a jövőbeli loop engineering projektek referenciájaként szolgálhat. --- ## Forrás - **Eredeti cikk:** - **Szerző:** Lev Deviatkin (LinkedIn: linkedin.com/in/lev-deviatkin) - **Publikálva:** 2026-07-06 • **Platform:** Agent Cookbook (Beginner szint) - **Forrásanyagok:** Anthropic engineering docs (December 2024 evaluator-optimizer pattern), Addy Osmani long-form on loop engineering, AlphaSignal analysis, Geoffrey Huntley („Ralph Wiggum loop”) - **Cikk kulcsszavak:** loop engineering, prompter vs. loop designer, 4-condition test, 30-second loop check, automations, worktrees, skills, MCP connectors, sub-agents, state file, minimum viable loop, Ralph Wiggum loop, comprehension debt, cognitive surrender, security tax, Claude Code `/loop`, Claude Code `/goal`, Codex Automations, Anthropic 8x merge rate, Addy Osmani, Geoffrey Huntley - **Feldolgozás:** Henky-pipeline (`article_from_blog`, 2026-08-13, fő agent self-write, 3746 szó < 5000 küszöb)