Loop Engineering: Was die neue Arbeitstechnik mit KI-Agenten taugt – und wann ein guter Prompt reicht
Ich beginne unüblich, mit zwei Zitaten. Boris Cherny, der Schöpfer von Claude Code, sagt: „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.“ Addy Osmani, Engineering-Lead bei Google Chrome, definiert die Technik gleich mit: „Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.“
Über Loop Engineering schreibt gerade buchstäblich jeder Winkel der KI-Szene: Technikbeschreibungen, Erfahrungsberichte, Ratschläge, Kritik. Vor diesem Hintergrund entsteht das Gefühl, das Prompt-Engineering sei gestorben und wer heute noch von Hand promptet, müsse dringend umlernen, Zyklen zu starten.
Stimmt das? Ja und nein. Loop Engineering ist eine sehr wirksame Arbeitstechnik, die weder das Prompten noch die Einrichtung von KI-Agenten ablöst. Sie setzt eine Ebene obendrauf – und die brauchen Sie nur in Situationen, in denen ein Loop wirklich etwas beiträgt. Das Schwierigste daran ist nämlich nicht, einen Loop zu starten. Das Schwierigste ist, aus ihm ein brauchbares Ergebnis zu holen. Wie das geht, welche Loop-Typen es Stand Juli 2026 gibt und woran sie in der Praxis scheitern, zeige ich in diesem Beitrag, inklusive einer Checkliste für Ihren ersten eigenen Loop.
Woher die Idee stammt: ein Thermostat aus dem Jahr 1620
Der Holländer Cornelis Drebbel baute um 1620 einen Brutkasten für Hühnereier, der die Temperatur selbst hielt. Die Konstruktion: Erwärmt sich das Quecksilber über dem Feuer, dehnt es sich aus und drückt eine Klappe im Ofenrohr zu. Fällt die Temperatur, zieht sich das Quecksilber zusammen, die Klappe öffnet sich. Drebbels Ofen gilt als eines der ersten dokumentierten Systeme mit Rückkopplung: Es vollzieht eine Aktion, misst das Ergebnis und leitet daraus die nächste Aktion ab.
Dieses Muster hat viele Nachfahren. Deming goss es als „Plan, Do, Check, Act“ in die Qualitätslehre. Und im Juli 2025 verpasste der australische Softwareentwickler Geoffrey Huntley ihm einen Namen aus den „Simpsons“: Ralph Wiggum, die Figur, die nicht durch Klugheit glänzt, aber niemals aufgibt. Huntleys Ralph-Technik besteht in Reinform aus einer einzigen Bash-Zeile:
while :; do cat PROMPT.md | claude-code ; doneEin Coding-Agent bekommt denselben Prompt so lange vorgesetzt, bis das Ergebnis trägt. Zum Start der Technik war das nötig, weil die Modelle beim Programmieren noch unzuverlässig arbeiteten. Binnen eines Jahres wurden aus der Bash-Schleife echte Produktfunktionen: Die /goal-Funktion in Codex beschreibt einen Zielzustand samt Prüfkriterium, Claude Code zog mit /goal, /loop und /schedule nach, dazu kamen Starts nach Zeitplan und nach Ereignissen: „Prüfe alle fünf Minuten offene Pull-Requests, antworte auf Reviews, repariere kaputte Tests.“
Falls Sie keinen Code schreiben: Bleiben Sie trotzdem dran. Im Code sind Loops nur deshalb zuerst gereift, weil Tests und Compiler in Sekunden ein ehrliches Signal liefern. Das ist kein Zufall, sondern System. Andrej Karpathy erklärt in seinem Sequoia-Gespräch „From Vibe Coding to Agentic Engineering“ (April 2026), warum Modelle ausgerechnet in Mathematik und Programmierung am schnellsten besser werden: Die Labore trainieren sie per Reinforcement Learning in Umgebungen, in denen sich das Ergebnis automatisch verifizieren lässt. Wo ein prüfbares Signal existiert, wächst die Fähigkeit; Loops nutzen denselben Hebel in der Anwendung. Ein günstiger, ehrlicher Messwert ist die Kernbedingung, unter der ein Loop überhaupt Sinn ergibt – und solche Messwerte gibt es weit über den Code hinaus: Stimmen die Summen in der Tabelle? Öffnet sich der Link? Liegt das Datum im richtigen Fenster? Hat jede Behauptung eine Quelle? Sogar in Schreibaufgaben lassen sich Loops einsetzen. Wie, dazu komme ich noch.
Sind Prompts damit erledigt?
Keineswegs, und da übertreiben sowohl Cherny als auch Osmani ein wenig. Um einen Loop zu starten, schreiben Sie dem Agenten einen Prompt. Innerhalb des Loops promptet das Modell dann sich selbst, und es gibt bis heute genug Situationen, in denen ein Loop schlicht überflüssig ist. OpenAI selbst positioniert /goal als Werkzeug für lange, mehrschrittige Aufgaben; für die einzelne Aufgabe genügt in den meisten Fällen ein gewöhnlicher, sauber formulierter Prompt.
Ich sortiere die Ebenen für mich inzwischen unter dem Arbeitsbegriff „Modell-Management“, ohne Anspruch auf Allgemeingültigkeit: Wie ein Manager Menschen und Ressourcen führt, führt ein Mensch, der mit KI arbeitet, mehrere Instanzen zugleich. Prompting bleibt die Grundfertigkeit, Anfragen präzise zu stellen: Ziel, gewünschtes Ergebnis, Format, Grenzen, nötige Prüfungen. Kontext-Engineering sorgt dafür, dass das Modell alle Informationen hat, die für die Aufgabe nötig sind; wohin die Tokens dabei verschwinden, habe ich an anderer Stelle gezeigt. Die Agenten-Hülle bestimmt, mit welchen Werkzeugen das Modell arbeitet – wie ein solcher Agent von innen aufgebaut ist, war hier schon Thema. Loop Engineering steuert als vierte Ebene den Zyklus: wann starten, was prüfen, was erinnern, wann anhalten.
Je besser die Modelle werden, desto mehr dieser Ebenen stehen bereit. Nötig sind längst nicht alle in jedem Fall.
Welche Loop-Typen gibt es?
Der Begriff ist jung, die Systematisierung läuft noch. Die brauchbarste Einteilung stammt aus dem Beitrag „Getting started with loops“ des Claude-Code-Teams vom 30. Juni 2026. Die Definition dort ist angenehm schlicht: Ein Loop ist ein Agent, der Arbeitsdurchläufe wiederholt, bis ein Stopp-Kriterium greift.
keine Prüfung — nur die Hoffnung, dass es geklappt hat
Von da aus sortiert sich das Feld nach dem Auslöser. Schrittweise Loops sind die Überraschung der Liste: Ihr normaler Dialog mit einem Modell ist bereits ein Loop. Sie stellen eine Aufgabe, lesen die Antwort, präzisieren, das Modell versucht es erneut – und das Stopp-Kriterium sind Sie selbst mit Ihrem „gut, passt so“. Sobald Sie diesen Zyklus bewusst drehen, etwa das Modell bitten, die eigene Antwort nach benannten Kriterien zu bewerten und nachzubessern, betreiben Sie schon halbes Loop Engineering. Ziel-Loops sind das klassische /goal: Das Stopp-Kriterium ist ein prüfbares Ziel oder ein Versuchslimit, „hole die Bewertung über 90 Punkte, maximal fünf Anläufe“. Zeit-Loops laufen nach Plan, /loop und /schedule. Proaktive Loops starten bei einem Ereignis, ganz ohne Menschen: Ein Test fällt durch, der Agent repariert. Ein Bug-Report kommt an, der Agent untersucht und legt ein Ticket an. Eine Abhängigkeit bekommt eine neue Version, der Agent aktualisiert und lässt die Prüfungen laufen.
Aus meiner Praxis ein Beispiel für Zeit-Loops: Mein Agent Hermes schickt mir jeden Tag zwei Zusammenstellungen nach Telegram. Die erste, mit Börsendaten, ist der Grenzfall – ein reiner Wecker mit festem Format, das sich seit Langem nicht ändert, und trotzdem ein Loop: Er startet täglich, liefert und lässt mich eingreifen, wenn etwas klemmt. Die zweite, eine Nachrichtenauswahl, ist feiner gebaut: Ich lese die Sammlung, sage dem Agenten, was gelungen ist und was fehlt, und er arbeitet die Rückmeldung in seine Such- und Schreib-Skills ein. Am nächsten Tag ist die Auswahl spürbar anders. Handgebaute Zyklen brauchte ich dafür keine; Hermes bringt die Skill-Nachbesserung nach Nutzerkommentaren von Haus aus mit.
Zwei Prinzipien aus dem Claude-Code-Beitrag würde ich mir einrahmen. Erstens: Wenn ein Durchlauf das Ziel verfehlt, korrigieren Sie nicht den Einzelfall – Sie schreiben die Lehre daraus ins System, damit sie für alle künftigen Starts gilt. Genau das passiert, wenn Hermes nach meinem Kommentar seinen Skill anpasst: Ich redigiere eine Zusammenstellung, die Verbesserung lebt in allen folgenden. Zweitens, das Geld: Setzen Sie explizite Stopp-Kriterien, nehmen Sie Skripte statt Modell-Überlegungen, wo die Arbeit deterministisch ist (warum soll ein Modell über eine Datumsprüfung „nachdenken“, die eine Codezeile erledigt?), und koppeln Sie das Startintervall an die echte Änderungsfrequenz. Ein Loop, der alle fünf Minuten etwas prüft, das sich einmal am Tag ändert, verbrennt schlicht Tokens.
Was berichten die Praktiker?
Die Klassifikation ist die Theorie. Wie Loops tatsächlich eingesetzt werden, hat Gergely Orosz, Autor des Newsletters The Pragmatic Engineer, am 14. Juli 2026 in einer großen Auswertung „What is loop engineering?“ zusammengetragen, auf Basis von rund 210 Antworten von Entwicklerinnen und Entwicklern.
Das Bild ist aufschlussreich. In der realen Arbeit dominieren zwei der vier Typen: Loops nach Ereignissen und Loops nach Zeitplan. Die typischen Produktionsfälle klingen wie der Traum eines müden Teamleads: automatische Pull-Requests für jeden Fehler im Log, die Reparatur „flackernder“ Tests, eine nächtliche Aufpasser-Routine, Incident-Untersuchungen auf frischen Spuren, lange Migrationen, die ein Agent über Wochen zieht.
Interessanter als die Erfolge sind die Klagen. Drei Enttäuschungen ziehen sich durch die Antworten. Die erste: Agenten driften bei langen Läufen ab – dazu gleich mein eigener Fall. Die zweite: die Kosten. Loops fressen Tokens mit beeindruckendem Appetit, denn jede Iteration ist ein vollwertiger Agenten-Durchlauf, und Iterationen gibt es per Definition viele. Die dritte ist die aufschlussreichste: Viele Praktiker berichten, dass ein Mensch im Loop bessere Ergebnisse liefert als volle Autonomie. Nicht, weil das Modell dumm wäre. Sondern weil der Mensch der günstigste Sensor für genau die Dinge ist, die sich maschinell nicht prüfen lassen. Karpathy nennt die Eigenschaft dahinter „jagged intelligence“, gezackte Intelligenz: Dasselbe Modell, das eine Codebasis von 100.000 Zeilen refaktoriert oder eine Zero-Day-Lücke findet, schlägt im Alltag vor, die 50 Meter zur Autowäsche zu Fuß zu gehen. Ein Loop erbt diese Zacken und bemerkt sie selbst nicht – der Mensch am Rand des Zyklus schon.
Auf dieser Beobachtung baue ich den Rest des Beitrags auf: Wie sieht ein Loop aus, der ehrlich prüft, rechtzeitig bremst und den Menschen an der richtigen Stelle einsetzt?
Woran scheitern Loops wirklich?
Die unbequeme Antwort: am Menschen. Genauer an seiner Bequemlichkeit, denn einen Loop zu starten und die Verantwortung an ihn abzugeben ist leicht. Eine gute Prüfung zu entwerfen ist Arbeit.
Ein Fall aus den letzten Wochen. Ich versuche, einen Threads-Account zum Thema KI-Nachrichten aufzubauen; die Inhalte erstellt derselbe Hermes (unter der Haube lief GPT-5.5, inzwischen GPT-5.6). Der Startplan wirkte solide wie ein Uhrwerk. Etwa eine Woche führte ich den Account von Hand, dann übergab ich an Hermes: jeden Morgen den Kanal analysieren, frische Nachrichtenanlässe zum Thema KI sammeln, zehn Entwurfs-Threads vorbereiten. Aus diesen Entwürfen wählte ich aus, redigierte, veröffentlichte über den Tag verteilt. Am nächsten Morgen parste Hermes den Kanal, verglich, welche Entwürfe ich genommen und wie ich sie verändert hatte, besserte seine Such- und Schreib-Skills nach – und der nächste Durchlauf startete auf verbessertem Stand.
Die ersten Tage lief es gut, der Agent lieferte zuverlässig frische Entwürfe. Dann fiel mir etwas auf. Die Threads bestanden strikt aus drei Beiträgen. Die Einstiege folgten zwei, drei immer gleichen Mustern. Und die Themen rutschten immer weiter zu „KI in der Wissenschaft“ mit einem kleinen Rest an Produktmeldungen. Was war passiert?
Hermes hatte als Prüfer im Loop nicht meinen Geschmack gesehen, denn den kann er nicht sehen. Er sah dessen Schatten: die Länge der gewählten Threads, wiederkehrende Einstiegsmuster, ein Wissenschaftsthema, das ein paar Tage gut lief. Diese Messgrößen optimierte er, gewissenhaft und immer weiter. Das ist Goodharts Gesetz in Aktion: Sobald eine Messgröße zum Ziel wird, taugt sie nicht mehr als Messgröße.
Gut, der KI-Prüfer driftet. Aber ist das wirklich nur mein Einzelfall?
Taugt eine KI als Prüfer im eigenen Loop?
Zurück zu Drebbel, kurz. Sein Regler funktionierte aus einem einzigen, simplen Grund: Quecksilber kann keine Wünsche für Wirklichkeit ausgeben. Es dehnt sich exakt so weit aus, wie der Ofen heiß ist, und es ist ihm gleichgültig, was die Heizung darüber „denkt“. In KI-Loops übernimmt die Rolle dieses Thermometers oft eine zweite KI – und genau an dieser Stelle beginnen die Probleme, die sich in Zahlen fassen lassen.
In diesem Juli erschien dazu eine Untersuchung mit dem sprechenden Titel „More Convincing, Not More Correct“ von Chenyu Zhou – überzeugender, aber nicht richtiger. Der Aufbau: Ein Modell löst Mathematikaufgaben aus dem GSM8K-Datensatz, ein zweites bewertet die Lösungen als Richter, ohne Zugriff auf die richtige Antwort. Dann wird das ausführende Modell darauf trainiert, die Zustimmung des Richters zu gewinnen, während der Autor jede Antwort still gegen einen versteckten Goldstandard prüft, den der Richter nie sieht. Das Ergebnis: Die Zustimmung des Richters stieg von 72 auf 94 Prozent – von außen sieht das aus, als würde das System rasant klüger. Die tatsächliche Korrektheit blieb bei rund 20 Prozent stehen. Der Ausführende lernte nicht, besser zu lösen. Er lernte, überzeugender auszusehen. Auch ein Gremium aus drei Richtern half wenig: Das Ensemble winkte rund 55 Prozent der falschen Antworten durch, und die Täuschungen wirkten über Richter aus verschiedenen Modellfamilien hinweg, von Qwen über Llama bis Gemma.
Meine Threads-Geschichte ist die Alltagsversion desselben Mechanismus. Hermes schrieb nicht interessanter, er schrieb näher an dem, was der Prüfer im Loop absegnen würde. Ein Richter ohne Zugang zur Realität bewertet Plausibilität, und Plausibilität ist trainierbar.
Klingt nach einem Todesurteil für Loops? Ist es nicht. Dieselbe Untersuchung zeigt nämlich auch den Riegel: Löst der Richter die Aufgabe zuerst selbst und vergleicht den Kandidaten dann mit seiner eigenen, festgehaltenen Lösung, fällt der Anteil fälschlich durchgewinkter Antworten von 71,9 auf 1,2 Prozent. Die allgemeinere Nachricht dahinter: Die Selbstprüfung beginnt zu arbeiten, sobald von außen Information in den Zyklus fließt. Ein Codelauf, eine Quellensuche, eine Datenbankabfrage, eine nachgerechnete Summe, eine menschliche Redaktion – etwas, das nicht aus dem Modell selbst stammt. Daraus folgt die Regel, die ich über jeden komplexen Loop hängen würde: Jede Iteration muss Information bekommen, die es in der vorherigen nicht gab. „Lies es noch einmal und verbessere es“ ist keine Information.
Wie bleibt ein Loop frisch? Forschung und Verwertung trennen
Für mein Threads-Experiment war der einfachste Ausweg, die redaktionelle Auswertung wieder selbst zu schreiben: welche Entwürfe warum schwach waren, welche Themen fehlten, welche Experimente sich lohnen würden. Nur widerspricht tägliche Handarbeit dem Zweck des ganzen Aufbaus, der maximalen Automatisierung. Also bin ich anders vorgegangen: Feedback gebe ich als Text einmal pro Woche, und für den Alltag habe ich ein Prinzip in den Loop geholt, das im Management seit Langem bekannt ist – das Dilemma aus Exploration und Exploitation, aus Erkunden und Verwerten.
Hermes hatte sich prächtig in Richtung Verwertung optimiert: Er nahm die Signale aus dem Kanal und nutzte sie aus. Das Erkunden, das ich nie beauftragt hatte, ließ er folgerichtig weg. Jetzt ist der Prozess umgebaut. Hermes liefert weiter jeden Morgen zehn Entwürfe, aber mit anderer Aufteilung: Sechs entstehen aus der Kanalanalyse, vier sind Experimente – neue Themen aus seinem eigenen Wissensstand, andere Machart (Struktur, Anzahl der Beiträge, Einstiege) und ganz neue Formate wie Kurzposts, Bilder oder Fragen an die Leser. Einmal pro Woche bekommt der Agent mein Text-Feedback zu beidem.
Ehrlicherweise: Auch die Experimente beginnen sich nach einiger Zeit zu ähneln. Ich rechne damit, dass ich ihre Zahl senke und dafür die Sprünge größer werden lasse; für belastbares Feedback reichen erfahrungsgemäß zwei bis drei experimentelle Posts pro Woche, danach beeinflussen sie den Hauptstrom von selbst. Die schöne Pointe: Handgebaute Zyklen waren nie nötig. Die Skill-Nachbesserung nach Kommentaren bringt Hermes mit, ich habe nur die Aufteilung der Entwürfe und den Feedback-Rhythmus festgelegt.
Brauchen Sie überhaupt einen Loop?
Beginnen wir mit der Frage, die am meisten Geld spart. Als Filter formuliere ich sie so: Was genau erfährt das System nach dem nächsten Durchlauf – und wie verändert das den übernächsten? Wenn Sie darauf keine Antwort haben, brauchen Sie keinen Loop. Dann reicht ein guter Prompt, und der ist um ein Vielfaches billiger. Gibt es eine Antwort, entscheiden zwei Größen über den Zuschnitt: der Preis der Prüfung und der Preis eines Fehlers. Die typischen Situationen habe ich in eine Tabelle gelegt:
| Situation | Rolle des Loops |
|---|---|
| Ein ehrlicher maschineller Test existiert (Code mit Tests, Daten mit Abgleich) | Hohe Autonomie möglich |
| Regeln plus subjektives Urteil (Redaktion, Analytik, Office-Aufgaben) | Loop bereitet vor und filtert, der Mensch entscheidet |
| Geschmack oder Strategie entscheiden fast alles | Kurze Iterationen mit häufiger menschlicher Reaktion |
| Zwischen den Durchläufen kommt keine neue Information an | Kein Loop – ein einzelner Prompt genügt |
| Fehler sind irreversibel oder teuer (Publikation, Zahlung, Löschung) | Zwingende menschliche Bestätigung vor der Aktion |
Lesen Sie die Tabelle als Spektrum, nicht als zwei Lager „geeignet / ungeeignet“. Mein Threads-Loop lebt in der zweiten und dritten Zeile gleichzeitig: Die Mechanik (Frische der Anlässe, Dubletten, Struktur) prüft der Loop, der Geschmack bleibt bei mir.
Bevor Sie einen Loop bauen, beantworten Sie sieben Fragen. Sie bilden den Pass des Loops und zugleich das Briefing für den Agenten, der ihn umsetzen soll:
- Ziel – zu welchem Ergebnis führt der Loop? Nicht „verbessere, bis es gut ist“, sondern „erfüllt diese Bedingungen“. Das Ziel darf offen enden, etwa ein Threads-Account, der jeden Tag mit Inhalt gefüllt wird.
- Trigger – was startet die Arbeit: ein Kommando, ein Zeitplan oder ein äußeres Ereignis? Bei mir liegen die Entwürfe jeden Morgen um sieben in Telegram.
- Eine Iteration – was genau passiert in einem Durchlauf? In meinem Beispiel: Kanalanalyse, Skill-Anpassung, zehn frische Entwürfe.
- Prüfung – woher kommt das ehrliche Signal, und wie verändert es den nächsten Durchlauf? Hermes vergleicht meine redaktierten Fassungen mit seinen Entwürfen.
- Gedächtnis – was überlebt die Grenze zwischen den Versuchen: Fortschritt, Absagen samt Begründung, bereits probierte Wege? Bei mir sind das die Skills für Anlass-Suche und Texterstellung.
- Bremsen – alle Enden außer dem Erfolg: „ein tragfähiges Ergebnis gibt es nicht, und das ist die Antwort“, eine feste Zahl Iterationen ohne Fortschritt, ein ausgeschöpftes Budget. Das sind legitime Ausgänge, keine Niederlagen. Ein Loop, der sagen kann „heute gibt es nichts“, ist wertvoller als einer, der eine Norm herauspresst.
- Mensch – alles, was das System nicht entscheiden kann. In meinem Fall: Geschmack, Themensetzung, die Veröffentlichung selbst.
Und was dann? Einen fertigen Prompt für alle Lebenslagen kann ich Ihnen nicht geben; bei Hermes ist die Architektur eine andere als bei /goal in Codex oder Claude Code. Der gemeinsame Ablauf ist trotzdem einfach. Schritt 1: Starten Sie den Agenten und lassen Sie ihn zuerst den aktuellen Stand zu Loop Engineering zusammentragen – das Wissen der Modelle veraltet in Monaten, ohne Websuche arbeiten sie hier oft mit überholten Kommandos. Schritt 2: Übergeben Sie den ausgefüllten Sieben-Fragen-Pass mit der Aufgabe, daraus einen Loop zu bauen. Schritt 3: Fahren Sie einen Testlauf, schauen Sie zu und kommentieren Sie, was abweicht.
Häufige Fragen zu Loop Engineering
Was ist Loop Engineering? Loop Engineering ist das Entwerfen und Steuern von Zyklen, in denen ein KI-Agent Arbeitsdurchläufe wiederholt, bis ein Stopp-Kriterium greift. Der Begriff etablierte sich 2025/2026 rund um Techniken wie Huntleys Ralph-Loop und Funktionen wie /goal in Codex und Claude Code. Der Kern ist nicht die Wiederholung, sondern die Prüfung: Jeder Durchlauf muss an einem ehrlichen Signal gemessen werden.
Ersetzt Loop Engineering das Prompt-Engineering? Nein. Der Loop selbst wird mit einem Prompt beauftragt, und innerhalb des Zyklus promptet das Modell sich selbst. Für einmalige Aufgaben bleibt ein präziser Einzelprompt das günstigste Werkzeug; OpenAI positioniert /goal ausdrücklich für lange, mehrschrittige Aufgaben.
Wann lohnt sich ein Loop nicht? Wenn zwischen den Durchläufen keine neue Information entsteht. Ein Loop, der nur „noch einmal lesen und verbessern“ wiederholt, optimiert Plausibilität statt Qualität. Ebenfalls kritisch: Aufgaben mit teuren, irreversiblen Fehlern wie Zahlungen oder Löschungen – dort gehört vor jede Aktion eine menschliche Bestätigung.
Was kostet ein Loop? Jede Iteration ist ein vollständiger Agenten-Durchlauf und verbraucht entsprechend Tokens. In der Praxiserhebung von Gergely Orosz (Juli 2026, rund 210 Antworten) zählen die Kosten zu den drei häufigsten Enttäuschungen. Gegenmittel: explizite Stopp-Kriterien, Skripte für deterministische Prüfungen und ein Startintervall, das zur echten Änderungsfrequenz passt.
Funktionieren Loops auch außerhalb der Programmierung? Ja, sobald ein günstiges, ehrliches Prüfsignal existiert: stimmige Summen, erreichbare Links, belegte Aussagen, Datumsfenster. Bei Geschmacks- und Strategiefragen bleibt der Mensch der Prüfer im Loop – wie in meinem Threads-Beispiel, in dem der Agent die Mechanik übernimmt und ich die Auswahl.
Vierhundert Jahre später
Am Anfang stand ein Ofen, der sich selbst regelte, weil Quecksilber nicht schmeicheln kann. Genau daran entscheidet sich bis heute, ob ein Loop trägt: an einem Prüfsignal, das der Wirklichkeit verpflichtet ist und nicht dem Wunsch, gut auszusehen. Karpathy zitiert im selben Gespräch einen Satz, der ihn geprägt hat und der über jedem Loop hängen könnte: Denken lässt sich delegieren, Verstehen nicht. Der Loop übernimmt die Durchläufe. Das Urteil darüber, was ein gutes Ergebnis ist, bleibt bei Ihnen. Es gibt übrigens die begründete Ansicht, dass der handgebaute Loop ein Übergangsphänomen ist – Funktionen wie /goal stecken bereits in den Agenten, und mit jeder Generation werden sie selbst vorschlagen, wo sich ein Zyklus lohnt. Bis dahin prüfen Sie es an einem eigenen Fall: Nehmen Sie eine Aufgabe, die Sie diese Woche dreimal von Hand angestoßen haben, und füllen Sie den Sieben-Fragen-Pass aus. Bleibt bei Frage 4 kein ehrliches Signal übrig, sparen Sie sich den Loop – und behalten den Prompt.