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: https://agent-cookbook.com/tutorial/loop-engineering-the-14-step-roadmap-from-prompter-to-loop-designer • 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:

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.
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.
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.
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:

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.
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.
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.
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.
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: https://agent-cookbook.com/tutorial/loop-engineering-the-14-step-roadmap-from-prompter-to-loop-designer
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)