Loopcraft, uitgelegd: Het samenstellen van autonome loops — en de controles die bedrijven nodig hebben

De grens van het werken met AI-agents heeft zojuist een naam gekregen voor het volgende niveau: loopcraft — de kunst van het ontwerpen en stapelen van autonome loops, populair gemaakt door Latent Space's AINews in juni 2026 ("Loopcraft: The Art of Stacking Loops") om een convergentie te benoemen onder de praktijkervaringen die in het Latent Space-artikel werden verzameld — Peter Steinberger, Boris Cherny en Andrej Karpathy (Latent Space, juni 2026). De convergentie is opvallend wanneer je ze naast elkaar legt. Peter Steinberger's vaste advies: je zou coding-agents niet meer moeten prompten — je zou loops moeten ontwerpen die je agents prompten. Anthropic's Claude Code-lead Boris Cherny, in de dertien woorden die we één keer citeren: "I don't prompt Claude anymore. I write loops, the loops do the work." En Andrej Karpathy, die de inzet voor autonome research zo groot formuleert als maar kan: veel van het werk in het komende tijdperk bestaat, in het kader van het artikel, uit het effectief stapelen van loops — het zo inrichten dat het volledig autonoom is, jezelf verwijderen als de bottleneck, en de historische neiging weerstaan om dingen zelf op te lossen. Lees die samen en de verschuiving die ze beschrijven is structureel, niet stilistisch: de eenheid van werk verschuift van de prompt (een menselijke beurt) naar de loop (een ontworpen, zelfrijdende cyclus), en vervolgens van de loop naar de stapel — loops die andere loops spawnen, voeden, verifiëren en verbeteren, waarbij de mens de architectuur ontwerpt in plaats van erin te zitten. Veel artikelen zullen uitleggen waarom dit zo boeiend is. Deze gids is de referentie voor het deel dat bepaalt of het het contact met een onderneming overleeft: wat loopcraft is, waar het vandaan komt, hoe het verschilt van de disciplines waarop het voortbouwt — en wat een stapel autonome loops vereist van de infrastructuur, want elke laag waaruit je een mens verwijdert, is een laag waar de controles al klaar moeten staan. Zoals met al onze referenties voor de korte termijn, zullen we deze pagina bijwerken naarmate de praktijk en de woordenschat zich verder ontwikkelen.

Wat is Loopcraft? Een definitie

Loopcraft is de praktijk van het produceren van werk door het ontwerpen van autonome loops — zelfrijdende cycli waarin een agent handelt, zijn resultaat verifieert en opnieuw probeert of doorgaat zonder menselijke tussenkomst — en, karakteristiek, door ze te stapelen: het samenstellen van loops tot gelaagde systemen waarin hogere loops lagere loops creëren, sturen, evalueren en verbeteren. De primitive is bekend uit een jaar agentic praktijk: geef een agent een doel, een verificatiesignaal (tests, een checker, een rubriek) en toestemming om te itereren, en hij stuurt zichzelf naar een resultaat. Loopcraft benoemt wat er vervolgens op de grens van de technologie gebeurt. Eén loop schrijft code tegen tests; een loop daarboven verwerkt binnenkomende issues en spawnt werk-loops voor elk ervan; een loop daarboven beoordeelt de outputs, werkt de specificaties en skills bij waarop de werk-loops draaien, en verwijdert patronen die falen; een buitenste loop bewaakt de kwaliteit en kosten over alles wat eronder ligt. De positie van de mens verandert op elk niveau — van auteur van prompts, naar ontwerper van een loop, naar architect van de stapel — en de bepalende discipline van het ambacht, in Karpathy's bewoordingen, is zelf-verwijdering: de zaken zo inrichten dat ze volledig autonoom zijn, omdat een mens binnen de cyclus het plafond voor de doorvoer vormt. Een verduidelijking voor gerelateerde zoekopdrachten: loopcraft is geen lus-constructie in code (for/while), geen regelkringtheorie uit de robotica en geen product — het is een vakterm van beoefenaars voor de ontwerpskill, zoals "staatskunst" de skill benoemt en niet een staat.

Een korte geschiedenis: van prompting tot loops en stapels

De stamboom is kort en steil. 2023–2024: prompting — de mens bij elke beurt, kwaliteit begrensd door de aandacht van de mens. 2025: de loop doet zijn intrede naarmate agents betrouwbare verify-and-retry krijgen — het discours uit de praktijk van dat jaar (Cherny's operationele patronen, Steinberger's build-logs) convergeert op het geven van controleerbare doelen aan agents en hen laten itereren, en loop engineering ontstaat als de genoemde discipline voor het goed bouwen van één loop: de triggers, verificatie, budgetten en stopcondities. Begin 2026: de AI Engineer World's Fair maakt loops tot haar ordenende vocabulair — een inner loop van grotendeels autonoom werk door agents, een outer loop van engineers die toezicht houden en verbeteren — en functionaliteiten voor parallelle agents (het spawnen van subagents, agent-teams, multi-agent research) brengen de compositie van loops naar de dagelijkse tooling. Juni 2026: het populairmakende artikel — Latent Space's AINews-editie geeft de convergentie de titel "Loopcraft: The Art of Stacking Loops," verankerd in Steinberger's advies om loops te ontwerpen in plaats van prompts, Cherny's praktijk waarin loops het werk doen, en Karpathy's kader rond het stapelen van loops en jezelf verwijderen bij autonoom onderzoek. Onze vaste historische kanttekening is van toepassing: de naamgeving loopt achter op de praktijk — teams stapelden al triage-loops op werk-loops op review-loops voordat iemand er een naam aan gaf — en de naamgeving is van belang omdat dit het moment is waarop de praktijk bespreekbaar, onderwijsbaar en, voor onze doeleinden hier, bestuurbaar wordt. Dat laatste gesprek is amper begonnen, en dat vormt de tweede helft van deze pagina.

Loopcraft vs. Prompting, Loop Engineering en de Software Factory

Drie grenzen duiden de term. Tegenover prompting: een prompt is een menselijke beurt; een loop is een ontworpen cyclus die zonder draait — de verschuiving in de praktijk is van het schrijven van instructies naar het schrijven van het systeem dat instructies geeft en controleert, wat verklaart waarom het niveau van de vaardigheid verschuift van formulering naar architectuur. Tegenover loop engineering: loop engineering — de discipline die onze loop engineering-gids behandelt — is het ambacht van één loop: het betrouwbaar, begrensd en observeerbaar maken van een enkele autonome cyclus. Loopcraft is de compositielaag daarboven: welke loops je moet bouwen, hoe ze stapelen, waar de verificatie op elk niveau leeft en waar het resterende oordeel van de mens aan wordt besteed. Loop engineering verhoudt zich tot loopcraft zoals machine-ontwerp zich verhoudt tot productie-ontwerp; je kunt geen loops stapelen die individueel niet deugdelijk zijn, en deugdelijke loops die niet gestapeld zijn, laten de meeste hefboomwerking onbenut. Tegenover de software factory: de fabriek — onze software factory-gids behandelt dit — is de industriële organisatie van dezelfde beweging: gestandaardiseerde inputs, door agents bemande stations, kwaliteitscontrole, door bewijs ondersteunde outputs. Een fabriek is geconstitutionaliseerde loopcraft; loopcraft is het ambacht dat de ontwerpers van een fabriek uitoefenen. De drie termen vormen een overzichtelijke ladder — engineer de loop, craft de stapel, industrialiseer de fabriek — en de bedrijfsvragen worden op elke sport moeilijker, omdat elke sport meer mensen uit meer cycli verwijdert.

Loopcraft in de onderneming: Het beheren van de stapel

Hier komt TrueFoundry in beeld, via de observatie die het enthousiasme over het algemeen overslaat: elke laag waaruit je een mens verwijdert, is een laag waar het menselijk oordeel al opnieuw geïmplementeerd moet zijn als infrastructuur. Binnen een prompt-gestuurde workflow is de mens het budget (ze stoppen wanneer het duur wordt), de guardrail (ze merken het wanneer het fout is) en de audit trail (ze herinneren zich wat er is gebeurd). Een loop verwijdert die mens één keer; een stapel verwijdert hen op elk niveau; en Karpathy's discipline om dingen niet zelf op te lossen is alleen veilig als het oplossen — het begrenzen, het controleren, het vastleggen — structureel gebeurt. De mechanica laat zich deels en eerlijk in kaart brengen. Gemediëerde bewerkingen draaien binnen door beheerders afgedwongen gateway-limieten: budget- en rate-regels op overeenkomend verkeer — terwijl enveloppen per loop op elke diepte een ontwerp voor applicatie-allocatie blijven — zodat de overeenkomende requests van een holstellig weglopende werk-loop kunnen worden afgesneden zodra de toewijzing en stops bereikt zijn — budgetregels evalueren overeenkomend LLM-verkeer tegen geconfigureerde team-, gebruikers- of metadata-scopes — een spawn-boom die put uit de enveloppe van een parent is een allocatie-ontwerp op applicatieniveau, geen gedocumenteerd productgedrag, dus samengestelde stapels hebben expliciete regels per scope of allocatie op orchestrator-niveau nodig om de totale uitgaven te begrenzen. De cumulatieve rekenkunde is niet hypothetisch — loops die loops spawnen is precies het mechanisme achter de CI/CD-tokenexplosie die onze tokenexplosie-analyse documenteert. Elke loop draagt een identiteit en laat een trace achter: de stille failure mode van gestapelde autonomie is het witwassen van verantwoordelijkheid — de actie die vijf lagen diep wordt uitgevoerd onder niemands naam — wat verklaart waarom loops worden uitgevoerd op de Agent Harness met traces op stap-niveau die de spawn-keten vastleggen: welke loop welke heeft gemaakt, onder wiens gezag, en wat er is gedaan. Verificatie is ook een loop — de buitenste: de watch-loop die de stapel nodig heeft, is online evaluatie die live output continu scoort plus guardrails die elke model- en tool call in-flight controleren (guardrails-documentatie) — mechanische waakzaamheid die de plaats inneemt van de mens die niet langer elke laag leest. En de ingrijpende grenzen van de stapel krijgen gates: het hele punt van stapelen is dat de meeste cycli onbeheerd draaien, wat precies de reden is waarom de weinige overgangen die er toe doen — mergen naar protected branches, het aanraken van productiegegevens, spawnen voorbij een bepaalde diepte of fleet-grootte — goedkeuringsgates in de harness zijn, de enige plek waar het oordeel van de architect terugkeert in het systeem dat hij heeft ontworpen. Dit is de enterprise-vorm van loopcraft: de betrouwbaarheidsdiscipline die onze ETCLOVG-gids toepast op één loop, recursief toegepast op een stapel — en de operations op fleet-schaal die onze fleet-runtime-gids behandelt, zijn hoe de stapel eruitziet vanaf de stoel van de beheerders.

Checklist voor Enterprise Loopcraft

Zes vragen voordat je hoger gaat stapelen: Draait elke loop binnen een afgedwongen budget en rate limit die hij niet kan verwijderen, met toewijzingen die overerven van parent op gespawnd child? Draagt elke loop een unieke identiteit, zodat acties op vijf lagen diep nog steeds herleidbaar zijn naar een verantwoordelijke principal? Is de spawn-keten getraced — de maker, de autoriteit en de stappen van elke loop te reconstrueren uit het harness-record? Is er een buitenste watch-loop — online evals en guardrail-metrieken — die geen enkele werk-loop kan uitschakelen? Zijn er goedkeuringsgates geplaatst op de ingrijpende overgangen van de stapel, en alleen daar, zodat de gates de doorvoer overleven? En is er een plafond voor diepte en fleet-grootte — een structureel antwoord op "wat voorkomt dat de stapel zichzelf blijft stapelen"? Zes keer ja is enterprise loopcraft; de nee's vormen de afstand tussen een architectuur en een incidentenrapport.

De toekomst van Loopcraft: Waar we op gaan letten

Voorspellingen, met een slag om de arm. Verwacht dat de praktijk zich zal formaliseren zoals haar voorloper dat deed: loop engineering ging in minder dan een jaar van build-logs naar een benoemde discipline met patronen, en de patronen van loopcraft — triage-stapels, verbeter-loops die specificaties en skills bewerken, watch-loops als permanente infrastructuur — zijn al zichtbaar in de parallelle agent-tooling die elke grote harness nu meelevert. Verwacht dat het governance-gesprek met de gebruikelijke vertraging zal arriveren, en wel stevig, omdat gestapelde autonomie precies die risico's concentreert waarover directies worden geïnformeerd: onbeheerde uitgaven, onbeheerd tool-bereik en verantwoording die vervaagt met de diepte — op welk punt budget-overerving, spawn-keten-traces en diepteplafonds niet langer het kader van deze pagina zijn, maar de taal van inkoopprocessen worden. En verwacht dat de diepste vraag van het komende jaar die van Karpathy zal zijn, omgekeerd: hij zegt dat het spel bestaat uit het effectief stapelen van loops en jezelf verwijderen als de bottleneck; de versie van de onderneming is beslissen welke 'zelf' te verwijderen — de mens als doorvoer-bottleneck kan verdwijnen, maar de mens als anker voor verantwoording niet, en de gehele kunst van enterprise loopcraft is het zo bouwen van de stapel dat het verwijderen van de eerste nooit stilzwijgend de tweede verwijdert. We zullen deze gids bijwerken naarmate het ambacht rijpt; de bewering die geen herziening nodig zal hebben, is de bewering die elke laag van de stapel herhaalt: autonomie versterkt zichzelf, en dat geldt ook voor de controles.

Veelgestelde vragen over Loopcraft

Wat is loopcraft in AI?

Loopcraft is de praktijk van het produceren van werk door het ontwerpen van autonome loops — zelfrijdende agent-cycli met ingebouwde verificatie en retry — en het stapelen daarvan: het samenstellen van loops die andere loops spawnen, sturen, evalueren en verbeteren, waarbij de mens de architectuur ontwerpt in plaats van erin te prompten. De term werd in juni 2026 populair gemaakt door Latent Space, ter benoeming van de samenkomende praktijk van Peter Steinberger, Boris Cherny en Andrej Karpathy.

Hoe verschilt loopcraft van loop engineering?

Loop engineering is de discipline van het goed bouwen van één autonome loop — de triggers, verificatie, budgetten en stopcondities. Loopcraft is de compositielaag daarboven: welke loops je moet bouwen, hoe ze stapelen, waar de verificatie op elk niveau leeft en waar de resterende menselijke beoordeling aan wordt besteed. Je hebt loop engineering nodig om loopcraft uit te oefenen; loopcraft is de reden waarom loop engineering zich versterkt.

Wat zijn de risico's van het stapelen van autonome loops?

De failure modes hebben de vorm van een stapel: holstellig weglopende recursie (loops die loops spawnen), combinatorische vermenigvuldiging van kosten, verantwoording die vervaagt met de diepte, en drift die zich opbouwt door lagen die geen mens leest. Het begrenzen hiervan vereist geconfigureerde gateway-limieten op overeenkomend verkeer, goedkeuringen voor gevoelige tools, traces van root- en subagents — en ontwerpen op applicatieniveau voor budgetallocatie, identiteit per loop, supervisor-processen en diepteplafonds.

Welke infrastructuur vereist enterprise loopcraft?

Een beheerd vlak waarop elke loop draait: budgetten en rate limits per loop met overerving van parent op child, unieke identiteiten per loop, harness-uitvoering met traces op stap-niveau die de spawn-keten vastleggen, guardrails op elke model- en tool call, traces en gekoppelde evaluatoren als bewijs voor een afzonderlijk ontworpen supervisor-proces — de orchestrator of applicatie beslist wanneer lagere loops moeten worden gestopt, opnieuw geprobeerd, geëscaleerd of gewijzigd, en menselijke goedkeuringsgates op de ingrijpende grenzen van de stapel.

Referenties

• De term en zijn bronnen — Latent Space / AINews, "Loopcraft: The Art of Stacking Loops" (juni 2026: de naamgeving; de standpunten van Steinberger, Cherny en Karpathy over het ontwerpen van loops, loops die het werk doen, het stapelen van loops en het verwijderen van jezelf als de bottleneck — het ene directe citaat en alle parafrases zijn afkomstig uit het overzicht van hun openbare verklaringen in deze editie).
• TrueFoundry-documentatie — Agent Harness (stap-traces; goedkeuringsgates; officieel diagram); budgetten (officiële afbeelding); guardrails.
• Dizze blog — loop engineering op enterprise-niveau; het uitvoeren van loops op fleet-schaal; ETCLOVG: de betrouwbaarheidsdiscipline; de agentic tokenexplosie in CI/CD; de software factory, uitgelegd; online evaluatie bij de gateway.

Er is één direct citaat van minder dan vijftien woorden gebruikt, in-line toegeschreven aan Boris Cherny zoals samengevat in de geciteerde Latent Space-editie; de standpunten van Steinberger en Karpathy zijn geparafraseerd uit hetzelfde overzicht van hun openbare verklaringen. Het kader voor stack-governance — budget-overerving, spawn-keten-traces, diepteplafonds — is een redactionele bijdrage van TrueFoundry op basis van functionaliteiten die zijn geparafraseerd uit openbare documentatie die actueel was op het moment van schrijven; de productafbeeldingen zijn eigen documentatie-assets van TrueFoundry, overgenomen met bronvermelding. Latent Space, Peter Steinberger, Boris Cherny, Andrej Karpathy en Anthropic evalueren of ondersteunen TrueFoundry niet. Dit is een dynamische referentie en zal worden herzien naarmate het ambacht en de woordenschat zich verder ontwikkelen.

‍