The Loop: Warum manche mit AI-Agents magische Ergebnisse erzielen und andere nur Müll
“The reason agentic work feels ‘magical’ for some people and ‘useless’ for others is rarely the model. It’s the loop.” — nibzard, Agentic Handbook
Stell dir zwei Entwickler vor. Gleicher Tech-Stack, gleiches Modell, gleiche IDE. Der eine liefert ein komplettes Feature in drei Stunden. Inklusive Tests, inklusive Edge Cases, bereit für den Review. Der andere kämpft seit zwei Tagen. Sein Agent halluziniert API-Endpoints die nicht existieren, implementiert Features halb, behauptet steif und fest alles funktioniere. Nichts kompiliert.
Ich kenne beide Szenarien. Und der Unterschied hatte nichts mit dem Modell zu tun.
AI-Agents ohne Feedback-Loop sind Zufallsgeneratoren
Die typische Erfahrung mit AI Coding Agents sieht so aus: Du gibst eine Aufgabe rein, der Agent produziert 200 Zeilen Code, meldet stolz “Production Ready!”, und dann startest du die Anwendung. Fehler. Überall Fehler. Also gibst du die Fehlermeldung zurück, der Agent entschuldigt sich höflich, ändert drei Zeilen, produziert neue Fehler. Nach einer Stunde hast du mehr kaputt als vorher.
Das ist kein Bug. Das ist das erwartbare Verhalten eines Systems ohne Feedback-Mechanismus.
Anthropic hat genau dieses Muster in ihrer eigenen Forschung dokumentiert, als sie Claude auf ihrer Codebasis arbeiten liessen:
“Claude’s failures manifested in two patterns. First, the agent tended to try to do too much at once.” — Anthropic Engineering
Der Agent versucht zu viel auf einmal. Der Kontext läuft voll. Features bleiben halb implementiert. Und dann kommt das zweite Pattern, das noch tückischer ist:
“One final major failure mode that we observed was Claude’s tendency to mark a feature as complete without proper testing.” — Anthropic Engineering
Der Agent sagt “fertig” ohne je getestet zu haben. Denk mal darüber nach. Anthropic selbst, die Firma die Claude baut, dokumentiert dass ihr eigener Agent Features als erledigt markiert ohne sie zu verifizieren. Das ist kein Randfall. Das ist das Standardverhalten.
Warum passiert das? Weil es keinen Mechanismus gibt, der den Agent zwingt seine eigene Arbeit zu überprüfen. Keinen Compiler der “das funktioniert nicht” sagt, keinen Test der rot wird, kein Gate das blockiert. Der Agent generiert Text, das ist alles was er tut. Ob dieser Text funktionierenden Code darstellt, weiss er nicht, solange ihm niemand das Ergebnis der Ausführung zurückgibt.
Stell dir einen Junior-Entwickler vor. Erster Tag im Job. Kein Code Review, kein CI/CD, keine Tests, kein Pair Programming. Er schreibt Code, committed direkt auf main, geht nach Hause. Natürlich wird das Ergebnis schlecht. Nicht weil der Entwickler dumm ist, sondern weil die Feedback-Mechanismen fehlen.
Genau so behandeln die meisten Leute ihre AI-Agents.
The Loop: Das Prinzip das alles verändert
Letztes Jahr habe ich angefangen, systematisch zu tracken wie ich mit AI Coding Agents arbeite. Welche Sessions produktiv waren, welche im Chaos endeten. Das Muster war eindeutig. Jede erfolgreiche Session hatte eine Gemeinsamkeit: einen geschlossenen Feedback-Zyklus. Jede gescheiterte Session hatte eine Gemeinsamkeit: keinen.
Peter Steinberger, Gründer von PSPDFKit und aktuell mit OpenClaw unterwegs, hat das im Pragmatic Engineer Podcast auf den Punkt gebracht:
“The good thing — how to be effective with coding agents — is always you have to close the loop. It needs to be able to debug and test itself. That’s the big secret.” — Peter Steinberger, Pragmatic Engineer Podcast
Das grosse Geheimnis. Kein besserer Prompt nötig, kein Prompt-Engineering-Kurs. Der Agent braucht die Fähigkeit, seine eigene Arbeit zu überprüfen und zu korrigieren.
Steinberger geht noch weiter und erklärt, warum Code der ideale Anwendungsfall für AI-Agents ist:
“That’s the whole reason why those models that we currently have are so good at coding but sometimes mediocre at writing — because there’s no easy way to validate. But code I can compile, I can lint, I can execute, I can verify the output.” — Peter Steinberger, Pragmatic Engineer Podcast
Code hat etwas, das die meisten anderen Domänen nicht haben: objektive Validierung. Es kompiliert oder es kompiliert nicht, der Test ist grün oder rot, der Linter meldet Fehler oder keine. Kein “naja, kommt drauf an”. Diese binäre Natur macht Code zum perfekten Terrain für AI-Agents. Aber nur wenn man diese Validierung auch tatsächlich einbaut.
Ohne Loop sieht der Workflow so aus: Prompt rein, Output raus, hoffen dass es passt. Das ist eine Slot Machine. Manchmal Jackpot, meistens nicht.
Mit Loop sieht es anders aus: Prompt rein, Code generiert, automatisch kompiliert, Tests laufen, Fehler erkannt, Agent korrigiert, Tests laufen erneut. Grün. Nicht hoffen, sondern wissen.
Das ist der Unterschied zwischen Zufall und System.
Wie man den Loop in der Praxis schliesst
Die Theorie klingt offensichtlich. Natürlich braucht man Feedback. Aber wie sieht das konkret aus, wenn ich morgen früh mein nächstes Feature bauen will?
Ich habe in den letzten Monaten drei Ansätze identifiziert, die zusammen den Loop schliessen. Keiner davon funktioniert allein. Alle drei zusammen verändern alles.
Requirements als ausführbare Spezifikationen
Der erste und wichtigste Shift: Ein Requirement ist keine vage Beschreibung. “Bau mir ein Login-Formular” ist kein Requirement. Das ist ein Wunsch. Und Wünsche sind das, womit die meisten Leute ihre Agents füttern.
Ein Requirement das den Loop schliesst sieht anders aus. Es hat konkrete Erfolgskriterien. “Das Login-Formular akzeptiert E-Mail und Passwort. Bei ungültiger E-Mail erscheint eine Fehlermeldung unter dem Feld. Bei falschem Passwort erscheint ein generischer Fehler, kein Hinweis ob die E-Mail existiert. Nach drei Fehlversuchen wird der Account für 15 Minuten gesperrt. Ein erfolgreicher Login setzt einen JWT-Token mit 24h Expiry.”
Der entscheidende Punkt: Diese Erfolgskriterien WERDEN die Tests. Jedes Kriterium lässt sich in einen automatisierten Test übersetzen. Und diese Tests schliessen den Loop. Der Agent schreibt Code, die Tests laufen, sie sind rot, der Agent korrigiert, die Tests laufen erneut, sie sind grün. Loop closed.
Jede Agent-Session wird dadurch wegwerfbar. Das klingt kontraintuitiv, ist aber befreiend. Wenn der Agent sich komplett verrennt, lösche ich die Session und starte neu. Das Requirement und die Tests bleiben bestehen. Ich verliere nichts ausser ein paar Minuten Compute-Zeit.
In einem Projekt letzte Woche habe ich eine komplexe Datenbank-Migration mit diesem Ansatz gebaut. 14 Erfolgskriterien, 14 Tests, vorher definiert. Der Agent brauchte zwei Anläufe. Die erste Session war nach 40 Minuten in einer Sackgasse. Ich habe sie gelöscht, neu gestartet, und die zweite Session hat in 25 Minuten alle 14 Tests grün bekommen. Ohne die vordefinierten Tests hätte ich den Unterschied zwischen “fast fertig” und “komplett kaputt” erst beim manuellen Testen gemerkt. Wahrscheinlich Stunden später.
Steinbergers praktisches Playbook
Steinberger hat einen Ansatz der radikaler ist als meiner. Er baut seine gesamte Architektur so, dass Agents sie validieren können.
Er lässt Agents mit jedem einzelnen Feature Tests schreiben. Kein Feature ohne Test, keine Ausnahme. Er hat CLI-Tools gebaut, damit der Agent sich selbst debuggen kann. Der Agent braucht Werkzeuge zur Selbstkorrektur, und diese Werkzeuge existieren nicht out of the box.
Sein “Gate”-Konzept ist einfach und brutal effektiv: Linting, Building, Type-Checking, alle Tests müssen bestanden sein bevor Code als fertig gilt. Kein manuelles “sieht gut aus”. Automatische Validierung.
Und dann dieses Detail, das mich am meisten beeindruckt hat:
“Even now for websites, I built the core in a way that can be run via a CLI. So I have this perfect execution loop.” — Peter Steinberger, Pragmatic Engineer Podcast
Er baut Websites so, dass der Core über eine CLI ausgeführt werden kann. Nicht weil das technisch nötig wäre, sondern weil es dem Agent einen geschlossenen Feedback-Loop gibt. Er designed seine Architektur für Agent-Verifizierbarkeit. Das ist ein fundamentaler Shift in der Art wie wir Software-Systeme denken.
Die Architektur bestimmt die Agent-Effektivität. Nicht der Prompt. Nicht das Modell. Die Frage ist: Kann der Agent seine eigene Arbeit überprüfen? Wenn die Antwort nein ist, wird das Ergebnis Zufall sein, egal wie gut das Modell ist.
Plan-Then-Execute statt Blindflug
Der dritte Baustein kommt von Boris Cherny, dem Erfinder von Claude Code:
“Start every complex task in plan mode. Pour your energy into the plan so Claude can 1-shot the implementation.” — Boris Cherny, X-Post
Die Energie gehört in den Plan, nicht in die Implementierung. Bei einer komplexen Aufgabe starte ich im Plan Mode. Ich beschreibe was gebaut werden soll, welche Dateien betroffen sind, welche Abhängigkeiten existieren, wie die Erfolgskriterien aussehen. Der Agent erstellt einen detaillierten Plan. Erst wenn der Plan stimmt, geht es an die Umsetzung.
Steinberger hat hier eine interessante Gegenposition. Er nutzt keinen formalen Plan Mode, sondern führt ein Gespräch mit dem Agent. Er arbeitet sich gemeinsam zum Problem vor, iteriert über die Lösung, korrigiert den Kurs. Weniger formell, mehr Dialog.
Was beide Ansätze gemeinsam haben: Bewusste Steuerung statt blindes Prompting. Der Mensch gibt die Richtung vor, definiert die Grenzen, setzt die Erfolgskriterien. Der Agent führt aus und validiert. Das ist keine Delegation an ein autonomes System. Das ist geführte Zusammenarbeit mit einem sehr schnellen, sehr fleissigen, aber manchmal halluzinierenden Assistenten.
Der kritische Fehler den ich bei den meisten sehe: Sie geben dem Agent eine komplexe Aufgabe und lassen ihn einfach loslaufen. Kein Plan, keine Grenzen, keine Checkpoints. Das ist so als würde man einem Praktikanten sagen “bau mal das Feature” und drei Tage nicht nach ihm schauen.
Die drei Feedback-Loops die jeder einrichten sollte
Genug Theorie. Hier sind die drei konkreten Loops die den Unterschied machen. Ich habe sie in der Reihenfolge ihrer Wichtigkeit aufgelistet, und ja, der erste klingt lächerlich trivial.
Der Compile/Build Loop ist die Basis. Der Agent muss seinen Code kompilieren und ausführen können. Das klingt so offensichtlich dass es fast peinlich ist, es zu erwähnen. Aber die Realität sieht anders aus. Laut einer Analyse von Anthropic waren fehlende Build-Verification-Steps einer der häufigsten Gründe für Agent-Failures in längeren Sessions. In vielen Setups generiert der Agent Code in einer isolierten Umgebung ohne Zugang zum Build-System. Er schreibt TypeScript das nie durch den Compiler läuft. Er importiert Packages die nicht installiert sind. Ohne Build-Loop ist alles Spekulation.
Der Test Loop ist der eigentliche “Close the Loop”. Jedes Feature braucht Tests, und der Agent schreibt sie mit. Die Tests validieren direkt das Requirement. Wenn ich sage “die API muss bei ungültigem Token einen 401 zurückgeben”, wird daraus ein automatisierter Test. Ist der Test rot, weiss der Agent dass er nicht fertig ist. Kein Interpretationsspielraum, keine Diskussion.
Der Lint/Quality Loop fängt alles ab, was die Tests nicht abdecken. Statische Analyse, Formatierung, Type-Checking. Automatische Gates die verhindern, dass schlechter Code durchrutscht. Unused imports, fehlende Error-Handling-Blöcke, Security-Patterns. Das ist die dritte Verteidigungslinie.
Steinbergers Gate-Konzept fasst alle drei zusammen: Alle Loops müssen bestanden sein bevor etwas als “fertig” gilt. Keine Ausnahmen. Kein “das fixen wir später”. Das klingt streng, aber es entlastet enorm. Ich muss nicht mehr jede Zeile reviewen. Die Loops fangen das Gröbste ab. Mein Review fokussiert sich auf Architektur-Entscheidungen und Business-Logik, nicht auf fehlende Semikolons und kaputte Imports.
In der Praxis sieht das so aus: Ich definiere meine Erfolgskriterien, der Agent generiert Tests daraus, schreibt die Implementierung, der Build läuft, die Tests laufen, der Linter läuft. Alles grün? Feature fertig. Etwas rot? Der Agent sieht den Fehler und korrigiert. Automatisch. Ohne dass ich eingreifen muss.
Das ist der Loop. Generate, check, fix, repeat. So simpel. So effektiv.
Warum das ein Mindset-Shift ist und kein Tool-Problem
Ich sehe ständig die gleiche Diskussion: “Welches Tool ist besser? Claude Code oder Codex? Cursor oder Windsurf?” Die Frage ist falsch. Es ist als würde man fragen welcher Schraubenzieher besser ist, wenn das eigentliche Problem ist, dass man die falsche Schraube benutzt.
Der Shift ist: Vom “Prompter” zum Requirements Engineer. Vom Menschen der dem Computer sagt was er tun soll, zum Menschen der definiert woran man erkennt dass es richtig ist.
Traditionell habe ich Code geschrieben und gehofft dass er funktioniert, dann manuell getestet. Mit AI-Agents schreibe ich zuerst die Definition von “funktioniert”, dann lasse ich den Agent Code und Tests generieren. Meine Arbeit verschiebt sich vom WAS zum WORAN-MAN-ES-ERKENNT.
Die Ironie daran ist fast komisch. Die “alte” Software-Engineering-Disziplin, Testing, CI/CD, klare Spezifikationen, saubere Architektur, wird im AI-Zeitalter wichtiger denn je. All die Dinge die wir seit Jahren predigen und oft ignoriert haben. Plötzlich sind sie nicht mehr nice-to-have. Sie sind der Unterschied zwischen einem Agent der magische Ergebnisse liefert und einem der Müll produziert.
TDD, Test-Driven Development, war jahrelang ein Ideal das die meisten nicht praktiziert haben. Jetzt ist es der natürliche Workflow mit AI-Agents. Erst die Tests, dann die Implementierung. Nicht aus ideologischen Gründen, sondern weil es der einzige Weg ist, den Loop zu schliessen.
Requirements Engineering war jahrelang das ungeliebte Stiefkind der Software-Entwicklung. “Schreib einfach Code” war die Devise. Jetzt entscheidet die Qualität der Requirements direkt über die Qualität des AI-Outputs. Schlechte Requirements, schlechter Output. Präzise Requirements mit messbaren Erfolgskriterien, präziser Output.
Es ist kein Zufall. Es ist ein Feedback-System. Und Feedback-Systeme brauchen klare Signale.
Nimm dein nächstes Feature. Bevor du den Agent startest, schreib die Erfolgskriterien auf. Nicht vage, nicht “es soll funktionieren”. Konkret. Messbar. Testbar. Lass den Agent zuerst die Tests schreiben. Dann die Implementierung. Schau was passiert, wenn der Agent seinen eigenen Output überprüfen kann.
Der Unterschied wird offensichtlich sein. Nicht weil du einen besseren Prompt geschrieben hast. Nicht weil du ein besseres Modell benutzt.
Sondern weil du den Loop geschlossen hast.
Du brauchst kein besseres Modell. Du brauchst einen besseren Loop.