A loop engineering lényege, hogy nem te magad adod be a promptot az AI-ügynöknek minden egyes lépésnél, hanem olyan rendszert tervezel, amely maga iterálja a célt addig, amíg az teljesen meg nem valósul. A loop itt egyszerűen egy rekurzív cél: meghatározod a szándékot, és az AI ismétlődően dolgozik rajta, amíg a megadott feltétel igaz nem lesz. Addy Osmani szerint ez lehet a jövő módja annak, ahogy kódügynökökkel dolgozunk, bár még kezdeti stádiumban vagyunk, és komoly óvatosságra int a tokenköltségek miatt.
A loop gondolata több iparági szereplő állításával is egybecseng: Peter Steinberger azt mondta, hogy "már nem kellene kódügynököket promptolnod — inkább loopokat kell tervezned, amelyek promptolják az ügynököket". Boris Cherny, az Anthropic Claude Code részlegének vezetője hasonlóan fogalmazott: ő már nem a Claudet promptolja, hanem olyan loopokat ír, amelyek a Claudet promptolják; a saját munkája szerinte loopok megírására szorítkozik.
Mi változott a korábbi munkafolyamathoz képest?
Az elmúlt években a tipikus munkaforma az volt: te írsz egy jól megfogalmazott promptot, megadsz kontextust, elolvasod a választ, majd újra promptolsz. Az ügynök eszköz maradt, te kézben tartottad a párbeszédet. A loop engineering ehelyett egy kis rendszert épít, amely megtalálja a teendőket, kiosztja őket, ellenőrzi az eredményt, naplózza mi történt, és eldönti a következő lépést — és ez a rendszer maga promptolja az ügynököket.
Ez ma már nem feltétlenül egy házilag összetákolt bash-szkriptek halmaza: sok alapfunkció mostanra beépül a termékekbe. Az Osmani által vizsgált példák — a Codex app és a Claude Code — nagyon hasonló építőkockákat kínálnak, így a loop tervezése független lesz attól, hogy épp melyik eszközt használod.
Egy loop öt alkotóeleme (plusz a memória)
Egy működő loophoz öt fő képesség és egy külső állapot/tár szükséges:
- Automations: ütemezett futtatások, amelyek önállóan felfedeznek és triázsolnak.
- Worktrees: elszigetelt munkakönyvtárak, hogy párhuzamos ügynökök ne ütközzenek.
- Skills: projektre írt tudás és szabályok, hogy ne kelljen minden futásnál újra elmagyarázni a kontextust.
- Plugins és connectors: csatlakozók a már használt eszközökhöz (issue tracker, CI, Slack stb.).
- Subagents: külön ügynökök a „készítő” és a „ellenőrző” szerepek szétválasztására.
És a hatodik: a memória — egy Markdown fájl, Linear tábla vagy más, a beszélgetésen kívül élő állapot, amely tárolja, mi lett megpróbálva, mi sikerült és mi maradt nyitva. A modell elfelejti a futások közti állapotot, ezért a memória lemezen kell legyen, nem csupán a kontextusban.
Részletek: miért fontos mindegyik elem?
Automations — a loop szíve
Az automatizálás az, ami ciklikussá teszi a folyamatot. A Codex appban az Automations fülön kijelölhetsz projektet, promptot, gyakoriságot és azt, hogy helyi checkouton vagy background worktree-ben fusson. A találatok triage inboxba kerülnek, a semmit nem találó futások archiválnak magukat. OpenAI belső használatban napi issue triage-re, CI összegezésre, commit-összefoglalók írására és hibakeresésre alkalmaz ilyesmit. Az automations hívhat skillt is, így a visszatérő logikát fenntarthatóvá teszed.
Claude Code hasonló képességeket ad ütemezéssel és hookokkal (/loop parancs, cron, GitHub Actions támogatás). Mindkettő lehetővé teszi autonóm feladatok megadását és ütemezését.
Mindkét eszköz tartalmaz egy per-session primitívet is: /loop újra fut egy ütemezés szerint, /goal pedig addig fut, amíg a te általad megadott feltétel igaz nem lesz; minden kör végén egy külön modell ellenőrzi, hogy befejeződött-e a feladat.
Worktrees — párhuzamos munka izolálva
Több ügynök futtatásakor a fájlütközések tipikus hibaforrásai lesznek. A git worktree külön munkamappát ad, saját branch-csel, így egy ügynök módosításai fizikailag nem érintik a másik checkoutját. Codex beépített worktree-támogatást nyújt; Claude Code lehetővé teszi a --worktree flaget és az isolation: worktree beállítást subagent szintjén. A munka mennyiségét azonban továbbra is a te emberi átolvasási sávszélességed szabja meg.
Skills — a projektintencitás újrahasznosítása
A skill egyszerűen egy mappa SKILL.md fájllal, benne útmutatással, metainformációval, kiegészítő scriptekkel vagy assetekkel. Ha meghívod a skillt ($ vagy /skills), az ügynök elolvassa a projekt specifikus tudást a futás során, tehát nem kell minden alkalommal újra elmagyarázni az elveket és konvenciókat. Ez csökkenti az „intenciós adósságot”: az ügynök nem találgatja a projekt szokásait minden alkalommal, hanem a leírt szabályokra támaszkodik.
Pluginok és connectors — a loop a valós eszközeidbe hatol
Ha a loop csak a fájlrendszert látja, akkor szűk látókörű. A connectors (MCP alapokon) lehetővé teszik, hogy az ügynök olvassa az issue trackert, lekérdezzen adatbázist, hívjon staging API-t vagy postoljon Slackbe. Codex és Claude Code is beszél MCP-t, így egy connector sokszor áthozható egyik eszközből a másikba. A pluginok pedig összecsomagolják a skill-eket és connectorokat egy telepíthető egységbe.
Subagents — különíteni a készítőt és a lektorát
A leghasznosabb szerkezeti döntés a loopban az, hogy elválasztod a kódot író ügynököt a kódot ellenőrzőtől. A készítő hajlamos túlzottan bizalmasan értékelni a saját munkáját; egy másik, gyakran eltérő modell által végzett ellenőrzés fogja elkapni a hibákat. Codex és Claude Code egyaránt támogat alügynököket (.codex/agents/ vagy .claude/agents/ TOML fájlokkal), és tipikus felosztás, hogy egy ügynök felfedez, egy implementál, egy pedig verifikál a projektszabályok alapján.
Ez tokenköltségben is megmutatkozik: több alügynök több modellhívást és eszközhasználatot jelent, tehát érdemes őket ott alkalmazni, ahol a második vélemény megéri a költséget.
Egy tipikus loop példája
Egy gyakori minta: minden reggel fut egy automation, amely átnézi a repo CI-futásokat, nyitott issue-kat és a legutóbbi commitokat, majd az eredményt egy Markdown fájlba vagy Linear boardra írja. Minden értékelhető találathoz a folyamat nyit egy izolált worktree-t, küld egy subagentet, hogy megtervezze a fixet, és egy másikat, hogy ellenőrizze azt a projekt skills és tesztek alapján. A connectorok megnyitják a PR-t és frissítik a ticketeket; amit a loop nem tud végrehajtani, az a triage inboxba kerül emberi beavatkozásra. A state fájl emlékszik, mi volt korábban megpróbálva és mi maradt nyitva, így a következő futás folytatja, ahol a korábbi abbahagyta.
A lényeg: egyszer megtervezed a loopot — nem promptolod sorra a lépéseket minden egyes alkalommal.
Mit nem csinál meg helyetted a loop?
A loop megváltoztatja a munkamódszert, de nem helyettesíti a mérnököt. Három fő kockázat éleződik:
- Verifikáció: a loop hibákat is futhat felügyelet nélkül. A maker/checker felosztás növeli a megbízhatóságot, de a "kész" státusz egy állítás, nem bizonyíték. A végső felelősség, hogy olyan kód kerüljön ki, amit te igazoltál, továbbra is emberi feladat.
- Megértés romlása (comprehension debt): minél gyorsabban szállít a loop kódot, amit te magad nem írtál, annál nagyobb lehet az eltérés a rendszer és a te tényleges megértésed között. Ha nem olvasod át, nő az adósság.
- Kényelmi vakság (cognitive surrender): könnyű abbahagyni a gondolkodást és minden eredményt elfogadni, amit a loop visszaad. A loop megtervezése lehet gyógyír, ha tudatosan végzed; de a loop lehet a gyorsítószer is, ha a tervezéssel a gondolkodást kerülöd.
Ajánlás: építsd a loopot, maradj mérnök
Osmani szerint ez a munkánk fejlődésének valószínű előnézete. Ugyanakkor ha teljes mértékben ráhagynád a terméket a loopokra átvizsgálás nélkül, a minőség romlana, és lehetsz egyre mélyebbre ásva egy lefelé tartó spirálban. Állíts be loopokat, használd őket, de ne hagyd el a közvetlen promptolás hatékonyságát sem — a lényeg a megfelelő egyensúly megtalálása.
Két ember ugyanazt a loopot felépítve teljesen ellentétes eredményre juthat: az egyik gyorsabban mozog a dolgokban, amelyeket mélyen ért, a másik pedig éppen hogy elkerüli a megértést. A loop nem tud különbséget; te tudod. Éppen ezért a loop-tervezés nehezebb, mint a promptolás: a hatalmi pont eltolódott. Építsd a loopot úgy, hogy szándékod maradjon mérnökként részt venni, ne csak a „go” gomb megnyomójaként működj.
