# Loop Engineering — Addy Osmani (2026-06-07) > Forrás: > Eredeti hossz: 2593 szó. Ez a magyar összefoglaló a legfontosabb gondolatokat emeli ki, recitáló-elv alapú szűréssel. --- ## Bevezetés Addy Osmani 2026. június 7-én megjelent „Loop Engineering” című cikke arról szól, hogyan tolódik át a fejlesztői munka súlypontja a promptolásról a rendszertervezés felé: ahelyett, hogy te magad piszkálnád az AI-agentet, egy olyan rendszert építesz, ami helyetted piszkálja azt — egy ütemezett, önjáró, visszacsatolásos hurkot (loopot). Addy szerint ez lehet a jövőnk az AI kódoló ügynökökkel — de korai még, szkeptikus, és a tokenköltségek miatt nagyon oda kell figyelni. --- ## Mi a loop engineering A definíció egyszerű: **loop engineering = önmagad kiváltása a promptoló szerepéből**. Ahelyett, hogy te írsz egy promptot, elolvasod a választ, írsz egy újabbat, és így tovább kézzel, építesz egy kis rendszert, ami megtalálja a munkát, szétosztja, ellenőrzi, lejegyzi, mi készült el, és eldönti, mi legyen a következő lépés — és ez a rendszer „pökli” az agentet helyetted. A loop itt nem szkript: **rekurzív cél**, ahol definiálsz egy szándékot, és az AI addig iterál, amíg a cél teljesül. A cikk két kulcsmondatot emel be a kontextusba: > **Peter Steinberger:** „You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.” — *„Nem kéne, hogy te promptold a kódoló agentet. Olyan loopokat kell tervezned, amik promptolják az agentet.”* > **Boris Cherny (Claude Code, Anthropic):** „I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” — *„Én már nem promptolom a Claude-ot. Loopok futnak, amik promptolják a Claude-ot, és kitalálják, mit kell tenni. Az én dolgom loopokat írni.”* Addy ezt úgy keretezi, hogy a **harness engineering** (az egyszeres agent környezete) fölé épül egy újabb réteg: a **factory modell**, ami időzítve fut, kis segéd-agenteteket spawnol, és saját magát eteti inputtal. Ami meglepő: ez ma már nem barkácmunka. Egy éve még halom bash-t írtál, és az a te magánbirodalmad volt. Ma a loop építőelemei **a termékekbe be vannak sütve** — a Codex appban és a Claude Code-ban is megvan mind. --- ## A hat építőelem (5 + 1 memory) Egy működő loop öt dologra és egy helyre van szüksége, ahova emlékezik: ### 1. Automations — a szívverés Ez teszi a loopot tényleges looppá, nem pedig egyszeri futássá. Az ütemezés a pulzus. - **Codex app:** az *Automations* fülön kiválasztod a projektet, a promptot, a gyakoriságot, és hogy a saját checkoutodon vagy háttér-worktree-n fusson-e. A találatok a *Triage inboxba* kerülnek, az üres futások archiválódnak. - **Claude Code:** ugyanoda ér el `/loop` (intervallumra ismétel), cron ütemezés, lifecycle hook-ok, vagy akár GitHub Action, ami a laptopod lecsukása után is fut. Van két in-session primitív, ami a cikk szíve: - **`/loop`** — adott cadenciával újrafuttat. - **`/goal`** — addig megy, amíg egy **verifiable stopping condition** (ellenőrizhető leállási feltétel) igazzá nem válik. Minden forduló után egy **külön kis modell** nézi meg, kész vagyunk-e — vagyis a kódot író agent nem saját magát osztályozza. Mindkét termékben megvan, mindkettőben `/goal` a neve. Maga a minta. ### 2. Worktrees — párhuzamosság izolálása Amint egyszerre kettőnél több agent fut, a fájlok ütköznek. Két agent ugyanazt a fájlt írja = két mérnök ugyanazt a sort committolja. A **git worktree** erre a problémára a válasz: külön working directory, közös repo-történet, egy agent fizikailag nem nyúlhat a másik checkoutjához. - **Codex:** beépített worktree per thread. - **Claude Code:** `git worktree`, `--worktree` flag session nyitáshoz, vagy `isolation: worktree` subagent beállítás. Addy hangsúlyozza: a worktree kiveszi a mechanikai ütközést, de **a te review-sávszélességed a plafon** — az orchestration tax cikkében írt emberi oldal nem tűnik el. ### 3. Skills — projekt-tudás leírása A skill az, ami miatt nem kell minden sessionben újra elmagyarázni a projekt kontextust. Formátuma egyszerű: mappa + `SKILL.md` + opcionális scriptek, referenciák, assetek. Codex-ben `$skill` vagy `/skills` hívja (vagy a leírás alapján implicit), Claude Code-ban ugyanúgy. A skill az **intent debt** ellenszere: az agent hideg indítással kezd minden sessiont, és ha bármilyen lyuk van a szándékodban, magabiztos tippeléssel tölti ki. A skill ezt a szándékot kívülre írja — konvenciók, build lépések, „nem így csináljuk, mert X incidens volt egyszer” — és onnantól **compoundol**, nem pedig újra levezeti a projektet minden körben. Fontos distinkció: **a skill az authoring formátum, a plugin a szállítási mód**. Ha repo-k közt akarod megosztani, pluginba csomagolod. ### 4. Plugins és connectors — a loop eléri a valódi eszközeidet Egy loop, ami csak a fájlrendszert látja, nagyon kicsi loop. A **connectors** (MCP-re épülnek) bekötik az issue trackert, az adatbázist, egy staging API-t, a Slack-et. A Codex és a Claude Code is beszél MCP-t, így a másiknak írt connector általában átmegy a másikba is. A **plugin** connectorokat és skilleket csomagol egybe, hogy a csapattársad egy lépésben telepítse a te felállásodat, ne nulláról rakja össze. Ez a különbség az „agent mondja, hogy itt a fix” és a „loop megnyitja a PR-t, linkeli a Linear ticketet, és pingolja a csatornát, ha zöld a CI” között. ### 5. Sub-agents — a maker és a checker szétválasztása A leghasznosabb strukturális elem: **az író és az ellenőrző legyen két külön agent**. A modell, ami a kódot írta, túl kedves a saját házijának osztályozásában. Egy másik agent más utasításokkal, néha más modellel, elkapja azt, amibe az első belebeszélte magát. - **Codex:** csak kérésre spawnol, párhuzamosan futtatja, és összefésüli a válaszokat. Subagentek TOML-ben definiálhatók a `.codex/agents/` alatt — name, description, instructions, opcionális modell és reasoning effort. - **Claude Code:** subagentek `.claude/agents/` alatt, plusz *agent teams*, amik munkát adnak át egymásnak. A klasszikus felosztás: egy explorer, egy implementer, egy verifier a spec ellen. A loop kontextusában azért kritikus, mert **a loop akkor fut, amikor nem nézed** — egy megbízható verifier az egyetlen, ami miatt el tudsz menni. Több tokenbe kerül (minden subagent saját modell- és tool-munkát végez), úgyhogy oda költsd, ahol a második vélemény megéri. ### 6. Memory — a hatodik darab A lista „öt dolog és egy hely, ahova emlékezik”. Memory: **markdown fájl** (pl. `AGENTS.md`, progress file) vagy **Linear board** MCP connectoron át. Bármi, ami a beszélgetésen kívül él, és tartja, mi készült és mi következik. Elsőre túl butának hangzik, de a long-running agenteknél ez a kulcs: a modell **minden futás között elfelejt mindent**, a memóriának lemezen kell lennie, nem a contextben. *Az agent felejt, a repo nem.* --- ## Codex vs Claude Code — ugyanaz a forma, más nevek | Elem | Codex app | Claude Code | |---|---|---| | Automations | Automations fül, Triage inbox, `/goal` | Scheduled tasks, cron, `/loop`, `/goal`, hooks, GitHub Actions | | Worktrees | Beépített worktree per thread | `git worktree`, `--worktree`, `isolation: worktree` subagenten | | Skills | `SKILL.md`, `$name` vagy implicit | `SKILL.md` | | Plugins / connectors | Connectors (MCP) + plugins | MCP servers + plugins | | Sub-agents | TOML `.codex/agents/` | Subagentek `.claude/agents/`, agent teams | | Memory | Markdown / Linear MCP-n | `AGENTS.md`, progress fájlok / Linear MCP-n | A nevek kicsit mások, a képesség ugyanaz. Ha ezt egyszer látod, **abbahagyod a tool-vitát**, és olyan loopot tervezel, ami mindkettőben működik. --- ## Egy konkrét loop példa: a reggeli automation Addy „reggeli automation”-je, amit ciklusban futtat: 1. **Automation** reggelente fut a repón. A prompt hív egy **triage skillt**, ami beolvassa a tegnapi CI failure-öket, a nyitott issue-kat, a friss commitokat, és a találatokat kiírja egy markdown fájlba vagy Linear boardra. 2. Minden találatra, ami érdemes, a thread nyit egy **izolált worktree-t**, és küld egy **sub-agentet** a fix megírására. 3. Egy második sub-agent **reviewzza** a draftot a projekt skillek és a meglévő tesztek ellen. 4. **Connectors** megnyitják a PR-t és frissítik a ticketet. 5. Amit a loop nem tud kezelni, a **triage inboxba** kerül, Addyhoz. 6. A **state fájl** a gerince az egésznek: emlékszik, mit próbáltak, mi ment át, mi nyitott — így a holnapi reggeli futás ott folytatja, ahol a mai abbahagyta. Amit egyszer megtervezel, nem kell többé promptolnod egyetlen lépésnél sem. Steinberger mondata testet ölt. --- ## Három figyelmeztetés A loop megváltoztatja a munkát, de **nem töröl ki téged a képből**. Sőt, három probléma élesedik, ahogy a loop jobb lesz: ### 1. Verification — továbbra is a te dolgod Egy felügyelet nélkül futó loop egyben **felügyelet nélkül hibázó loop**. A verifier sub-agent pont arra való, hogy a loop „kész” szava jelentsen valamit — de még ekkor is *„kész”* egy állítás, nem bizonyíték. Addy ismétli a mantráját a *code review in the age of AI*-ból: **olyan kódot szállíts, ami működését te magad ellenőrizted**. ### 2. Comprehension debt — a megértés rothad Minél gyorsabban szállít a loop kódot, amit nem te írtál, annál nagyobb a szakadék a létező rendszer és a fejedben lévő modell között. Ez a **comprehension debt**, és egy sima loop csak gyorsítja a növekedését, hacsak nem olvasod el, amit a loop gyártott. ### 3. Cognitive surrender — ne add fel a véleményedet Amikor a loop magától fut, nagy a kísértés, hogy felhagyj a véleményalkotással és elfogadd, amit ad. Addy ezt **cognitive surrender**-nek hívja. A loop tervezése **orvosság, ha ítélettel teszed, és gyorsító, ha azért csinálod, hogy ne kelljen gondolkodnod**. Ugyanaz a cselekvés, ellentétes eredmény. --- ## Konklúzió > *„Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do. That's what makes loop design harder than prompt engineering, not easier.”* Cherny mondata nem arról szól, hogy a munka könnyebb lett. Arról szól, hogy **a leverage point elmozdult**. > **Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.** *— Addy Osmani, 2026-06-07*