Az AI‑vel vezérelt fejlesztési gyakorlatban a „loop” szó pillanatnyilag divatos fogalom, de nem mindenki ugyanarra gondol, amikor használja. Laurie Voss a LinkedInen megjelent eredeti cikkében arra hívja fel a figyelmet, hogy legalább négy különböző architektúra rejlik a kifejezés mögött. Az alábbiakban összefoglalom ezeket a jelentéseket, példákkal és a konferenciákon elhangzott érvekkel.
1) A végrehajtási loop: az ügynök belső cselekvés‑megfigyelés ciklusa
Ezt a típust a legtöbben képzelik el egy „agent” hallatán: az ügynök meghív egy eszközt, elolvassa az eredményt, eldönti a következő lépést, és ismétel. Addy Osmani ezt az „inner execution loop”-nak nevezte: az a belső ciklus, amelyet az ügynök viszonylag önállóan futtat. A loop akkor zárul, amikor környezeti visszajelzés érkezik (teszteredmény, API‑válasz, fájltartalom), vagy amikor az ügynök úgy dönt, hogy készen van — akár helyesen, akár nem. A gyakorlati javítások egyike az, hogy ezt a loopot külső ellenőrzéssel (másik loop) veszik körbe, hogy ne fogadjuk el automatikusan az ügynök önértékelését.
2) A feladat (task / Ralph) loop: újraindítás a specifikáció teljesüléséig
Ez a modell — Geoffrey Huntley által „Ralph loop”-ként bemutatott megközelítés — a specifikáció újrafuttatását jelenti: az ügynököt többször, minden iterációnál teljesen friss kontextusablakkal indítják, egyetlen feladat elvégzésére. Az ismételt újratáplálás célja a kontextusromlás (context rot) és a tömörödés kivédése, amelyek hosszú munkamenetek alatt rejtetten rontják az eredményeket. A loop iterálandó egysége egyetlen artefaktum; a kilépési feltétel a specifikációnak való megfelelés és a tesztek átadása. Az ember írja a specifikációt, mérlegeli a készséget, és felügyeli a ciklust: azonosítja a hibamintázatokat és javítja őket, hogy ne ismétlődjenek.
3) A termék (product / software factory) loop: a szoftvergyártósor
A leghangosabban ezt a verziót említették az AI Engineer World’s Fairen. Tereza Tizkova (Factory) a szoftvergyárat úgy definiálta, mint „a teljes loopot, a teljes életciklust az autonóm szoftverfejlesztéshez”. Zach Lloyd (Warp) részletezte a lifecycle lépéseit: triage, specifikáció, implementáció, review, verifikáció, kiadás és monitorozás. Warp saját kódját egy Factory platform, Oz alá tette, és tudatosan növeli az automatikus PR‑merge arányát alacsony kockázattól magasabb felé (például 20% felől 60% felé). Anthropic belsőleg hasonló kísérletet folytat: a cég szerint a termékcsapat kódjának 65%-át az ottani Claude Tag generálja, és Mike Krieger World’s Fair‑es bemutatása szerint az eszközök „delegáló és proaktív” szerepet töltenek be — nem pusztán hibajavítást kérnek, hanem felelősséget vállalnak kódrészekért és önállóan vesznek fel feladatokat.
A task és execution loopoknak jól definiált kilépési feltételeik vannak; a termékloop ezzel szemben folyamatosan iterál a kódbázison és a backlogon. A zárójelzések külső forrásból érkeznek: új hibajegyek, production logok, felhasználói visszajelzés vagy review‑eredmények. Az emberi szerep konfigurálható: szervezettől függ, hogy hol és mikor kapcsolódnak be emberek (például magas kockázatú változtatásoknál marad‑e a code review emberi feladat).
4) A rendszer (system / autoresearch) loop: az ügynök a rendszert fejleszti
Roland Gavrilescu (Introspection) ezt autoresearchnek nevezi: az elsődleges rendszer az ügyfél‑felé dolgozik (inner loop), míg a külső loop a fő rendszer tanulmányozásán és karbantartásán iterál. Ez magában foglalja a promptokat, harness‑okat, modellválasztásokat és magukat az értékeléseket. Konkrét példák is vannak: Andrej Karpathy 2026 márciusában publikált autoresearchére hivatkoztak — körülbelül 630 sor Python, ami egy GPU‑n 50 hipotézis‑szerkesztés‑értékelés kísérletet futtatott le éjszaka. Meta‑nál a Brain2Qwerty v2 esete (2026. június vége) megmutatta, hogy az ügynökök iteratívan módosították a kódbázist jobb dekódolási architektúrák feltalálására, érdemi javulást elérve a szóhibaarányban; ugyanakkor a Meta megjegyzi, hogy a végső tréningkonfigurációkat még kézzel választották ki. A rendszerloop kilépési jelzései a legkomplexebbek: értékelések, emberi bírák, szűrt termékvisszajelzés és Roland javaslata szerint egy explicit „kérdezz embert” eszköz, amelyen keresztül az ügynök tacit tudást gyűjt.
Melyik nem valódi loop: Agentic MapReduce
A Cognition‑tól ismert Agentic MapReduce (vagy Devin Security Swarm) mint párhuzamos, korlátozott ügynökökkel dolgozó minta nem feltétlenül loop: a dispatch‑gather‑validate lépések csővezetékként működnek, és önmagukba nem táplálnak vissza új ciklust. A fan‑out topológia bármelyik négy loopon belül alkalmazható, de önmagában nem hoz létre visszacsatolással rendelkező loopot.
A felügyeleti (oversight) loop: ki áll a tetején?
Swyx eredeti diagramjában a legkülső gyűrű „???? loop” volt, igazi kimeneti feltétel nélkül. Voss ezt a réteget oversight loopnak nevezi: itt állítják be a célokat, osztják el a költségvetést és selejtezik a munkát — ez az a gyűrű, ahol embernek kell élnie. Addy szerint „a belső loop képesség; a külső loop ügynökség”. A World’s Fairen a viták nagy része arról szólt, ki tartsa kezében ezt a gyűrűt: egy tábor (Zach, Roland) az autonómia fokozatos növelését javasolja, checkpointokkal és koncepció szerint előbb „zenekarokat” kell építeni (orchestrák, ahol van ember‑karmester), mások (Geoffrey Litt, Paul Bakaus) attól tartanak, hogy a túl nagy delegálás az emberek célját és tulajdonlását veszélyezteti.
Autonómia mint állítható kapcsoló és mérnöki kérdés
Voss hangsúlyozza: az autonómia minden egyes loopon külön‑külön állítható. Lehet teljesen autonóm execution loop egy erősen felügyelt product loopon belül, vagy adhatsz ügynököknek rendszerloopot, miközben a célkitűzést teljesen emberi kézben tartod. A valódi mérnöki kérdés nem „melyik tábor győz?”, hanem „milyen információkra van szükség ahhoz, hogy minden diódát helyesen állítsuk be?”
A cikk vége arra hívja fel a figyelmet, hogy a „loop” szó iránti lelkesedés mögött valós gyakorlat áll: az emberek egyre magasabb absztrakciós szintre lépnek és a humán döntést egyre feljebb tolják a veremben. A négy loop elnevezése térképet ad: most, hogy tudod, melyiket építed, tisztábban látszik, hová érdemes mászni.
A fenti összegzés Laurie Voss eredeti írásának rekonstruált, magyar nyelvű áttekintése; a cikk eredetileg a LinkedInen jelent meg, és a felsorolt események, nevek és százalékadatok az ő cikkéből származnak.
