Loop Engineering: Wie man Agent Loops richtig entwirft
Als ich zum ersten Mal einen Loop ohne echte Stoppbedingung baute, kostete es mich 12 Dollar und lief 28 Minuten, bevor ich ihn abbrach. Der Agent war nicht kaputt. Er tat genau das, was ich ihm sagte: weitermachen, bis die Aufgabe "erledigt" ist. Das Problem war, dass ich "erledigt" nie so definiert hatte, dass eine Maschine es prüfen konnte. Also generierte er weiter, verfeinerte weiter, verbrannte weiter Tokens — stimmte sich selbst im Kreis zu, während mein Geldbeutel sich still und leise leerte. Dieser eine misslungene Durchlauf lehrte mich mehr über Loop Engineering als jedes Tutorial.
Hier ist die Veränderung, die gerade stattfindet, und die meisten Entwickler haben noch nicht aufgeholt. Die Fähigkeit, die 2026 zählt, ist nicht das Schreiben eines cleveren Prompts. Es ist das Schreiben des Loops, der das Modell für dich ansteuert — und genau zu wissen, wie dieser Loop entscheidet, dass er fertig ist. Boris Cherny, der Schöpfer und Leiter von Claude Code bei Anthropic, sagte es unverblümt auf der Bühne bei Acquired Unplugged am 2. Juni 2026: "Ich prompte Claude nicht mehr. Ich habe Loops laufen, die Claude prompten und herausfinden, was zu tun ist. Mein Job ist es, Loops zu schreiben."
Das ist keine Wegwerfphrase. Das ist eine Stellenbeschreibung, die sich in Echtzeit verändert.
Eine kurze Anmerkung, bevor wir tief eintauchen, denn zwei Dinge teilen sich dasselbe Wort. Wenn du die praxisnahe, das-ist-was-schiefging-Review des Skills willst, der Loop-Building produktisiert, habe ich das separat in meiner Analyse von Anthropics Launch Your Agent Skill und dem außer Kontrolle geratenen Agent-Lauf, den er produzierte, behandelt. Dieser Beitrag ist ein Tool-Review. Dieser hier handelt von der Technik darunter — der Disziplin, den Loop selbst zu entwerfen, egal in welches Werkzeug du ihn gießt. Die beiden sind verwandt, nicht identisch. Lies diesen für das Warum und die Form; lies jenen für das Wie es sich anfühlte, ihn laufen zu lassen.
Am Ende hiervon wirst du in der Lage sein, einen Loop mit einer echten, überprüfbaren Stoppbedingung zu entwerfen — und, genauso wichtig, du wirst wissen, wann ein Loop überhaupt das falsche Werkzeug ist. Dieser zweite Teil ist es, wo sich die meisten Leute verbrennen.
Was ist Loop Engineering?
Loop Engineering ist die Praxis, Trigger, Aktion und Stoppbedingung eines autonomen Agent-Loops so zu entwerfen, dass er laufen, seine eigene Arbeit verifizieren und anhand objektiver Kriterien stoppen kann — anstatt sich auf einen einzelnen, von Menschen geschriebenen Prompt zu verlassen. Es behandelt den Loop, nicht den Prompt, als die Arbeitseinheit.
Denke darüber nach, wie du KI-Coding-Agents verwendet hast. Du schreibst einen Prompt. Du liest die Ausgabe. Du schreibst einen weiteren Prompt. Du bist der Loop. Deine Augen sind der Verifikationsschritt, dein Urteil ist die Stoppbedingung, und deine Finger sind das, was die nächste Iteration neu auslöst. Loop Engineering verlagert alle drei aus deinem Kopf in Code.
Cherny beschrieb seine eigene Entwicklung in drei Phasen, und sie passt nahtlos zu dem, was die meisten ernsthaften Entwickler gerade durchleben. Vor etwa einem Jahr schrieb er Code von Hand, mit Autocomplete, das an den Rändern half. Dann wechselte er dazu, fünf bis zehn Claude-Sitzungen parallel zu betreiben und jede manuell zu prompten — Tab-Wechsel wie ein Schnellkoch. Jetzt schreibt er Loops, die Claude für ihn prompten; ein paar hundert Agents lesen sein GitHub, sein Slack und sein Twitter und entscheiden, was als Nächstes gebaut wird. Der Mensch ging vom Code-Tippen zum Prompt-Tippen zur Maschinerie, die Prompts tippt.
Der Begriff selbst kristallisierte sich Anfang Juni 2026 heraus — "schreibe Loops, keine Prompts" — und sobald du den Rahmen verinnerlicht hast, kannst du ihn nicht mehr übersehen. Peter Steinberger, der OpenClaw baute (das meistgestarnte neue Repo in der GitHub-Geschichte), postete es am 7. Juni 2026 noch deutlicher: "Du solltest Coding-Agents nicht mehr prompten."
Starke These. Größtenteils richtig. Aber "größtenteils" trägt Gewicht, und wir kommen noch dazu, wo sie bricht.
Der Denken → Handeln → Beobachten → Bewerten Zyklus
Jeder Agent-Loop, auf das Wesentliche reduziert, ist derselbe Viertakt-Rhythmus, der sich wiederholt. Die Namen variieren — manche sagen Wahrnehmen/Entscheiden/Handeln/Beobachten, manche sagen Beobachten/Denken/Handeln/Verifizieren — aber die Musik ist identisch. Ich denke darüber nach als: Denken → Handeln → Beobachten → Stoppbedingung bewerten, dann zurück zum Anfang.
Denken: Der Agent betrachtet den aktuellen Zustand und entscheidet, was als Nächstes zu tun ist. Handeln: Er führt eine Operation aus — schreibt eine Datei, führt einen Befehl aus, ruft eine API auf. Beobachten: Er erfasst, was sich geändert hat — die Befehlsausgabe, den Fehler, den neuen Dateiinhalt, den Screenshot. Bewerten: Er prüft diese Beobachtung gegen die Stoppbedingung. Fertig? Beenden. Nicht fertig? Erneut denken mit den neuen Informationen.
Die Namensstreitigkeiten sind unwichtig. Was zählt, ist der vierte Takt. Die meisten gescheiterten Loops, die ich gesehen habe — einschließlich meines 12-Dollar-Desasters — haben einen starken Denken-Handeln-Beobachten-Zyklus und einen falschen Bewertungsschritt. Der Agent beobachtet seine eigene Ausgabe und fragt sich: "Gut genug?" Und natürlich sagt er ja, denn er benotet seine eigenen Hausaufgaben ohne Bewertungsschema. Ein Loop ohne etwas, das zurückdrückt, ist nur der Agent, der sich im Kreis selbst zustimmt.
Das ganze Spiel besteht darin, den vierten Takt echt zu machen.
Deshalb entwerfe ich Loops jetzt rückwärts. Bevor ich den Trigger schreibe, bevor ich eine einzelne Aktion schreibe, schreibe ich die Stoppbedingung auf und stelle eine Frage: Welches konkrete Ding in der Welt sagt mir, dass dies erledigt ist, das der Agent nicht fälschen kann? Ein Test, der besteht. Ein Type-Checker, der grün wird. Eine CI-Pipeline, die von rot auf grün wechselt. Ein HTTP 200 von einem Endpunkt, der vor einer Minute noch 500 war. Wenn ich dieses Ding nicht benennen kann, baue ich den Loop noch nicht. Der Loop ist nicht bereit — die Definition ist nicht bereit.
Also lasst uns die Anatomie richtig aufschlüsseln, denn jedes der drei Teile hat seine eigenen Fehlerarten.
Trigger, Aktion, Stoppbedingung: die Anatomie eines Agent-Loops
Ein Loop hat genau drei tragende Teile. Bekomme eines davon falsch hin und das Ganze wackelt.
Der Trigger ist das, was den Loop startet. Es kann ein menschlicher Befehl sein ("refaktoriere dieses Modul"), ein Zeitplan (alle fünfzehn Minuten), ein Ereignis (ein neues GitHub-Issue, eine Slack-Nachricht, ein fehlschlagender Test in CI) oder ein anderer Agent, der Arbeit übergibt. Chernys Setup mit ein paar hundert Agents wird durch seine eigene Aktivität ausgelöst — seine Commits, seine Nachrichten, seine Posts werden zu Signalen, die Agents aufgreifen und auf die sie reagieren. Der Trigger beantwortet: Wann hat dieser Loop das Recht zu existieren und Tokens auszugeben?
Die Aktion ist die Menge an Operationen, die der Agent innerhalb jeder Iteration ausführen darf. Hier zeichnest du den Explosionsradius. Eine Aktion könnte sein "Dateien in diesem Verzeichnis bearbeiten und die Testsuite ausführen." Es könnte sein "ein Bild generieren und speichern." Je enger und spezifischer der Aktionsraum, desto vorhersagbarer der Loop. Je vager — "tu was nötig ist" — desto kreativer und desto gefährlicher. Die meisten Token-verbrennenden Ausreißer, die ich beobachtet habe, kommen von einem Aktionsraum, der zu breit war für die Fähigkeit der Stoppbedingung, eine falsche Abzweigung zu erkennen.
Die Stoppbedingung ist das Verifikationstor — die objektiven Kriterien für "fertig." Dies ist der Teil, den jeder unterbaut. Es muss etwas sein, das extern zur eigenen Meinung des Agents ist. Matthew Berman, der die Loop Library am 18. Juni 2026 startete, rahmt Verifikation klar: es kann sein "ein bestandener Unit-Test, eine grüne CI-Pipeline oder ein LLM, das sagt 'ja, das ist vollständig.'" Beachte die Vertrauensreihenfolge dort. Ein Unit-Test ist eine Tatsache. Eine grüne Pipeline ist eine Tatsache. Ein LLM, das Vollständigkeit beurteilt, ist eine Meinung — nützlich, aber die schwächste der drei und die, die am wahrscheinlichsten schlechte Qualität abstempelt.
Hier ist die Design-Illustration, die ich im Kopf behalte. Angenommen, ich will einen Loop, der fehlschlagende Tests in einem Repo behebt. Trigger: ein geplanter Lauf oder ein Push, der CI rot macht. Aktion: den fehlschlagenden Test lesen, den Quellcode bearbeiten, die Suite erneut ausführen — und nur diese Operationen. Stoppbedingung: die vollständige Suite besteht, Punkt. Diese letzte Klausel ist der ganze Punkt. Der Loop kann keinen Sieg erklären, indem er sich selbst sagt, der Code sehe korrekt aus. Er erklärt Sieg, wenn npm test mit Exit-Code null endet. Der Test ist das Ding im Loop, das nein sagen kann. Ohne etwas, das nein sagen kann, hast du keinen Loop — du hast einen teuren Ja-Sager.
Diese Unterscheidung — zwischen einer Stoppbedingung, die eine Tatsache ist, und einer, die eine Meinung ist — erweist sich als das ganze Spiel. Was mich zu dem Teil bringt, über den niemand genug spricht.
Warum Verifikationstreue einen Loop macht oder bricht
Nicht alle Stoppbedingungen sind gleich geschaffen, und der Unterschied zwischen einer guten und einer schlechten ist der wichtigste Prädiktor dafür, ob ein Loop etwas Nützliches produziert oder etwas, das lediglich fertig aussieht.
Ich nenne das Verifikationstreue: wie getreu deine Stoppbedingung das misst, was dich wirklich interessiert. Hohe Treue bedeutet, dass das Tor das echte Ziel prüft. Niedrige Treue bedeutet, dass das Tor einen Proxy prüft, der leicht zu erfüllen und leicht zu täuschen ist.
Bermans Loop Library ist eine Goldgrube, um dies in Aktion zu sehen, und ich will hier präzise sein — das sind Loops, die er und seine Mitwirkenden gebaut und im Kampf getestet haben, nicht solche, die ich persönlich laufen ließ. Aber sie illustrieren das Treueproblem besser als alles, was ich konstruieren könnte.
Nimm seinen Thumbnail-Erstellungs-Loop. Das Setup: generiere zehn Thumbnails, bewerte sie gegen MrBeast-artige Referenz-Thumbnails, iteriere auf den Top-Drei. Ungefähr 27 Minuten pro Durchlauf. Trigger und Aktion sind scharf. Aber die Stoppbedingung? "Bewerte sie gegen MrBeast-Thumbnails." Das ist subjektiv. Es gibt keinen npm test für "ist dieses Thumbnail überzeugend." Die Verifikation ist ein LLM, das ein Bild betrachtet und eine ästhetische Meinung bildet, und ästhetische Meinungen sind wackelig. Der Loop läuft, er produziert Thumbnails, aber die "fertig"-Definition ist weich — was bedeutet, dass der Loop auf etwas konvergieren kann, das das Modell für gut hält, während ein menschlicher Ersteller völlig anderer Meinung sein könnte. Niedrige Treue ist kein Bug im Code. Es ist ein Bug in dem, was "fertig" bedeutet.
Schau dir nun seinen three.js-Loop an — den Bau eines 3D-Flugzeugs mit three.js, etwa 37 Minuten, mit iterativer visueller Verifikation durch Rendern im Browser. Höhere Treue als Thumbnails, weil der Agent tatsächlich die Szene rendern und sie bei jeder Iteration ansehen kann. Aber die Durchsicht-Transparenz gelang trotzdem nicht vollständig. Die Verifikation konnte bestätigen "ein Flugzeug existiert und rendert," aber "die Transparenz sieht richtig aus" war schwieriger auf einen objektiven Check festzunageln. Der Loop kam nah dran. Nah dran ist nicht fertig.
Dann gibt es die Beatles-Abbey-Road-Nachstellung in HTML/CSS — begrenzt auf acht Versuche, etwa sieben Iterationen tatsächlich durchgeführt, verifiziert durch Screenshot-Vergleich. Es verbesserte sich schrittweise bei jedem Durchgang und endete weit entfernt von perfekt. Und ehrlich gesagt ist dieses Beispiel das lehrreichste der drei, weil es die Grenze des Loops so deutlich zeigt. Screenshot-Verifikation hat mittlere Treue: sie kann "das Layout ist grundsätzlich falsch" erkennen, aber tut sich schwer mit "dieser bestimmte Farbverlauf ist leicht daneben." Die harte Begrenzung auf acht Versuche ist der unbesungene Held hier — es ist eine sekundäre Stoppbedingung, die eine endlose, unbefriedigbare Jagd verhindert. Wenn deine primäre Verifikation unscharf ist, ist eine harte Iterationsbegrenzung das, was den Loop davor bewahrt, zu meinem 12-Dollar-Desaster zu werden.
Die Lektion baut sich sauber auf. Objektive Stoppbedingungen (ein bestandener Test, ein Exit-Code, ein HTTP-Status) produzieren Loops, denen man vertrauen kann, unbeaufsichtigt zu laufen. Subjektive Stoppbedingungen (sieht das gut aus, ist das überzeugend) produzieren Loops, die einen Menschen im Sitz brauchen, oder zumindest eine harte Versuchsbegrenzung, damit sie schnell scheitern statt teuer zu scheitern.
Wenn du eine Regel aus diesem ganzen Abschnitt willst: Stimme die Autonomie des Loops auf seine Verifikationstreue ab. Tor mit hoher Treue? Lass ihn laufen. Tor mit niedriger Treue? Begrenze die Versuche und halte die Hand am Notschalter.
Bisher haben wir über einen Agent in einem Loop gesprochen. Aber die mächtigsten Muster — und die, die Cherny tatsächlich betreibt — beinhalten Agents, die einander kontrollieren.
Maker-Checker und verschachtelte Flotten: Skalierung über einen einzelnen Loop hinaus
Ein einzelner Agent, der Denken-Handeln-Beobachten-Bewerten macht, funktioniert gut für begrenzte Aufgaben. Die interessante Architektur beginnt, wenn du das Machen vom Prüfen trennst — und wenn Loops beginnen, Loops zu spawnen.
Das Maker-Checker-Muster ist das sauberste Upgrade, das du für einen Loop mit niedriger Treue machen kannst. Statt eines Agents, der sowohl die Arbeit produziert als auch beurteilt, ob sie fertig ist (das Hausaufgaben-Bewertungsproblem), teilst du die Rollen. Ein Agent macht — schreibt den Code, generiert das Design, entwirft den Text. Ein zweiter, separater Agent prüft — bewertet es, benotet es gegen Kriterien, sucht nach dem Fehler. Die gesamte Aufgabe des Checkers ist es, Gründe zu finden, nein zu sagen. Weil er die Arbeit nicht produziert hat, hat er kein Ego darin investiert, sie als fertig zu bezeichnen. Diese Trennung gibt dem Loop einen echten Gegner, und ein Loop mit einem echten Gegner ist ein Loop, der tatsächlich auf Qualität konvergieren kann.
Ich stütze mich jetzt ständig darauf. Wenn eine Stoppbedingung subjektiv sein muss — sagen wir, "ist dieses API-Design sauber" — bitte ich den Maker nicht, sich selbst zu bewerten. Ich starte einen zweiten Agent mit einem scharfen Bewertungsschema und dem Auftrag, streng zu sein. Die Outputqualität springt, weil jetzt etwas im Loop ist, das gebaut wurde, um zurückzudrücken.
Dann gibt es verschachtelte Flotten — Manager, die Sub-Agents steuern, Loops, die Loops orchestrieren. Das ist es, was Chernys "paar hundert Agents, die mein GitHub und Slack lesen und entscheiden, was gebaut werden soll" tatsächlich ist. Ein Top-Level-Loop beobachtet seine Aktivität und denkt über Prioritäten nach. Er sendet Sub-Loops aus, um spezifische Builds zu erledigen. Jeder Sub-Loop hat seinen eigenen Trigger, Aktionsraum und Stoppbedingung und berichtet zurück. Die Stoppbedingung des Manager-Loops ist nicht "habe ich Code geschrieben" — es ist "hat meine Flotte die richtigen Dinge ausgeliefert." Es sind Loops bis ganz nach unten, mit Verifikationstoren auf jeder Ebene.
Wenn du versuchst, etwas in diesem Maßstab zu architekturieren, verdienen die Orchestrierungsmuster ihre eigene tiefgehende Behandlung — ich habe beschrieben, wie man Manager, Sub-Agents und die Nachrichtenübermittlung zwischen ihnen strukturiert, in meiner Analyse der Claude Code Agent-Schwarm-Architektur. Die Kurzversion: verschachtelte Flotten multiplizieren sowohl deinen Durchsatz als auch deine Fehleroberfläche. Jede Ebene, der eine echte Stoppbedingung fehlt, ist eine Ebene, auf der schlechte Qualität eintreten und unbemerkt nach oben propagieren kann.
Und das Gerüst unter all dem ist wichtiger als die Agents selbst. Die Art, wie Anthropic sein langlebiges Agent-Gerüst entwirft — wie der Zustand über Iterationen hinweg persistent bleibt, wie der Kontext verwaltet wird, damit der Loop nicht in seiner eigenen Geschichte ertrinkt — hat grundlegend geprägt, wie ich über Loop-Langlebigkeit denke; ich habe das in meinem Beitrag über Anthropics Agent-Gerüst-Design aufgeschlüsselt. Ein Loop ist nur so gut wie das Gerüst, in dem er läuft.
Wenn du nickend dasitzt und denkst "großartig, ich werde alles loopen" — stopp. Das ist genau die Stelle, an der ich bremsen muss, denn die wichtigste Loop-Engineering-Fähigkeit ist zu wissen, wann man keinen bauen sollte.
Wann man KEINEN Loop schreiben sollte
Hier sind die unbequemen Daten, die die "hör auf zu prompten, fang an zu loopen"-Fraktion gerne überspringt. Eine Umfrage von 2025 unter 306 Praktikern ergab, dass 68 % der Produktions-Agents zehn Schritte oder weniger laufen, bevor ein Mensch eingreift. Lies das nochmal. Die Agent-Systeme, die in der Produktion tatsächlich funktionieren, sind keine autonomen Schwärme von zweihundert. Sie sind klein. Sie werden überwacht. Sie laufen eine Handvoll Schritte und dann übernimmt ein Mensch das Steuer.
Das ist kein Versagen der Technologie. Das ist die Technologie, die von Leuten benutzt wird, die auf die harte Tour gelernt haben, wo Loops brechen.
Der Fehlermodus hat jetzt einen Namen: Agent Slop. Es ist das, was du bekommst, wenn du über den Punkt hinaus automatisierst, an dem du noch für die Ausgabe bürgen kannst. Der Loop produziert weiter, das Volumen steigt weiter, und die Qualität degradiert still, weil nichts im System gebaut war, um die Abdrift zu fangen. Du endest mit tausend Commits, denen du nicht vertrauen kannst und die du nicht gelesen hast. Slop ist kein schlechter Code — es ist unbürgbarer Code, schneller generiert, als jeder Mensch ihn verifizieren kann.
Also hier ist meine ehrliche Checkliste, wann man den Loop ganz überspringen sollte:
Überspringe es, wenn du ein Solo-Entwickler auf einem Verbraucherplan bist. Loops geben bei jeder Iteration Tokens aus, und ein außer Kontrolle geratener Loop auf einem gemessenen Plan ist eine echte Rechnung. (Frag mich, woher ich das weiß — 12 Dollar in 28 Minuten, und das war ein kleiner.) Wenn du kostenbewusst bist, wird die Mathematik autonomer Loops schnell hässlich. Ich habe die vollständige Token-Ökonomie in meinem Leitfaden zur KI-Agent-Kostenoptimierung aufgeschlüsselt, und die Überschrift ist einfach: ohne ein hartes Tor scheitern Loops still und geben weiter aus. Stilles Scheitern plus gemessene Abrechnung ist die schlimmste Kombination in diesem ganzen Feld.
Überspringe es, wenn dein Code keine automatisierte Verifikation hat. Keine Tests, kein Type-Checker, keine CI? Dann ist deine einzig mögliche Stoppbedingung die Meinung eines LLMs — das Tor mit der niedrigsten Treue, das es gibt. Du hast keinen Loop; du hast eine teure Art, plausibel aussehende Diffs zu generieren. Baue zuerst die Tests. Die Verifikationsinfrastruktur ist die Loop-Infrastruktur. Ein Loop ohne ein hartes Tor zum Zurückdrücken ist der Agent, der sich im Kreis selbst zustimmt, und das ist genau die Slop-Maschine.
Überspringe es, wenn dein echtes Nadelöhr die Review-Kapazität ist, nicht die Tippgeschwindigkeit. Dieser Punkt ist subtil und erwischt gute Ingenieure. Loops machen die Produktion schneller. Sie tun nichts für das Review. Wenn du bereits in PRs ertrinkst, die du nicht schnell genug reviewen kannst, hilft das Hinzufügen eines Loops, der zehnmal mehr Code generiert, nicht — es begräbt dich. Die Einschränkung hat sich nur verschoben. Du hast den Teil optimiert, der nicht das Problem war. Bevor du einen Loop baust, frage dich ehrlich: Ist Tippen mein Nadelöhr, oder ist Bürgen mein Nadelöhr? Wenn es Bürgen ist, macht ein Loop die Dinge schlimmer.
Das vereinigende Prinzip: Ein Loop ist nur so vertrauenswürdig wie das Ding darin, das nein sagen kann. Kein Test, kein Type-Check, kein echter Fehler, auf den reagiert werden kann — kein Loop. Nur ein Agent, der sich selbst zunickt, während die Uhr läuft.
Was das tatsächlich an deiner Arbeit ändert
Also wo lässt dich das praktisch, diese Woche?
Die ehrliche Lesart der "schreibe Loops, keine Prompts"-Bewegung ist, dass sie richtungsmäßig korrekt und taktisch übertrieben ist. Die Zukunft sind wirklich Loops — Cherny hat nicht Unrecht, dass sein Job jetzt das Schreiben der Maschinerie ist, nicht der Prompts. Aber die 68 %-Zahl ist der Realitätscheck: die Loops, die den Kontakt mit der Produktion überleben, sind klein, bewacht und überwacht. Der Traum einer Flotte von zweihundert Agents, die unbeaufsichtigt läuft, ist real für die Leute, die kugelsichere Verifikation um jede Ebene herum gebaut haben. Für alle anderen ist es ein Slop-Generator mit Kreditkarte.
Was ich heute tatsächlich tun würde: Nimm eine repetitive Aufgabe, die du mit einem KI-Agent machst — die, bei der du immer wieder dieselbe Art von Prompt tippst. Schreibe zuerst die Stoppbedingung auf, vor allem anderen. Mache sie zu einer Tatsache, nicht zu einer Meinung: ein Test, ein Exit-Code, ein Status-Check. Wenn du diese Tatsache nicht benennen kannst, hast du gerade entdeckt, dass die Aufgabe nicht loop-bereit ist, und du hast dir eine 12-Dollar-Lektion erspart. Wenn du sie doch benennen kannst, hast du den schwierigsten Teil des Loops bereits gebaut. Trigger und Aktion sind die leichte Hälfte.
Das mentale Modell, das du von hier mitnehmen sollst, ist klein genug, um auf einen Klebezettel zu passen: Ein Loop ist eine Maschine zum Wiederholen von Denken-Handeln-Beobachten, bis ein Ding, das nein sagen kann, ja sagt. Entwirf dieses "Ding, das nein sagen kann" zuerst. Alles andere ist Leitungsarbeit.
Der außer Kontrolle geratene Loop, der mich 12 Dollar kostete, war kein Versagen des Agents. Es war ein Versagen der Definition — ich baute die Leitungen, bevor ich das Tor baute. Baue zuerst das Tor. Dann kannst du den Loop laufen lassen und tatsächlich vertrauen, was er dir überreicht, wenn er stoppt.
Häufig gestellte Fragen
Was ist Loop Engineering?
Loop Engineering ist die Disziplin, Trigger, Aktion und Stoppbedingung eines autonomen Agents so zu entwerfen, dass er laufen, seine eigene Ausgabe verifizieren und anhand objektiver Kriterien stoppen kann — anstatt von einem einzelnen, von Menschen geschriebenen Prompt abhängig zu sein. Die Arbeitseinheit verschiebt sich vom Prompt zum Loop selbst. Für die vollständige Anatomie siehe den Abschnitt Trigger/Aktion/Stoppbedingung oben.
Ist Loop Engineering dasselbe wie Prompt Engineering?
Nein. Prompt Engineering optimiert eine einzelne Anweisung, die du dem Modell gibst; Loop Engineering optimiert die Maschinerie, die das Modell wiederholt promptet und entscheidet, wann die Arbeit erledigt ist. Wie Boris Cherny es ausdrückte: "Mein Job ist es, Loops zu schreiben" — der Prompt wird zu einem internen Detail des Loops, nicht zu dem Ding, das du von Hand erstellst.
Wann sollte man keinen Agent-Loop verwenden?
Überspringe einen Agent-Loop, wenn du ein Solo-Entwickler auf einem Verbraucherplan bist (Token-Kosten summieren sich bei jeder Iteration), wenn dein Code keine automatisierte Verifikation hat (Tests, Typen, CI), die als objektive Stoppbedingung dienen kann, oder wenn dein echtes Nadelöhr die Review-Kapazität ist und nicht die Tippgeschwindigkeit. Eine Umfrage von 2025 unter 306 Praktikern ergab, dass 68 % der Produktions-Agents zehn Schritte oder weniger laufen, bevor ein Mensch eingreift — klein und überwacht schlägt autonom und unbürgbar.
Was ist das Maker-Checker-Muster bei KI-Agents?
Das Maker-Checker-Muster teilt einen Agent-Loop in zwei Rollen: Ein Agent produziert die Arbeit und ein separater Agent benotet sie gegen Kriterien. Da der Checker die Ausgabe nicht erstellt hat, hat er keinen Anreiz, sie abzustempeln — was dem Loop einen echten Gegner gibt, der zurückdrücken kann. Es ist die sauberste Lösung für Loops, deren Stoppbedingung andernfalls subjektiv wäre.
Was macht die Stoppbedingung eines Agent-Loops zuverlässig?
Verifikationstreue. Ein objektives Tor — ein bestandener Unit-Test, eine grüne CI-Pipeline, ein HTTP 200 — ist eine Tatsache, die der Agent nicht fälschen kann, sodass der Loop unbeaufsichtigt laufen kann. Ein subjektives Tor, wie ein LLM, das beurteilt, ob ein Bild "gut aussieht," ist eine Meinung, die leicht zu täuschen ist, also braucht es einen Menschen im Sitz oder eine harte Begrenzung der Versuche. Stimme die Autonomie des Loops darauf ab, wie getreu sein Tor das echte Ziel misst.
Lass uns zusammenarbeiten
Sie möchten KI-Systeme bauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe gerne.
- Fiverr (Maßgeschneiderte Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
