Agentic Loops: Warum dein KI-Assistent mehr liefert als du denkst

Stell dir folgendes Szenario vor: Es ist kurz nach 23 Uhr. Du hast eine Funktion fertigzustellen und schiebst seit einer Stunde Code hin und her mit einem KI-Assistenten. Prompt rein, Antwort raus. Code rein, Code raus. Manchmal funktioniert's. Manchmal nicht. Und ob du wirklich weißt, was da gerade passiert?

Kommt dir bekannt vor?

Hier ist die unbequeme Wahrheit: Die meisten Entwickler nutzen KI-Tools so wie einen Taschenrechner, bei dem man die Tasten noch selbst drücken muss. Klar, das Ding rechnet. Aber was genau passiert dabei? Keine Ahnung. Und wenn das Ergebnis dann plausibel klingt, aber subtil falsch ist – ja, dann sitzt du um Mitternacht am Debugger.

Die Teams, die tatsächlich produktiven Code mit KI ausliefern, haben etwas anderes verstanden. Sie haben aufgehört, KI-Unterstützung als Prompt-und-Antwort-Spiel zu betrachten. Stattdessen bauen sie Systeme – Schleifen – die es der KI erlauben, kleine, sichere, überprüfbare Änderungen kontinuierlich vorzunehmen. Die Ergebnisse sprechen für sich: weniger Regressionen, weniger Kontextüberlauf, Diffs die man tatsächlich lesen kann.

Das Problem mit dem Alles-auf-einmal-Ansatz

Ein-Shot-Prompting hat einen verlockenden Reiz. „Schreib mir ein User-Authentifizierungssystem." Erledigt. „Refaktoriere das gesamte Modul auf die neue API." Zack. Fühlt sich produktiv an. Fühlt sich schnell an.

Bis es das nicht mehr tut.

Denk mal durch, was wirklich passiert, wenn du eine große Aufgabe auf einmal an eine KI übergibst. Zuerst prallst du gegen die Kontextwand. Die meisten Codebasen, mit denen es sich zu arbeiten lohnt, sind zu groß für das Gedächtnis einer KI. Also fängt sie an zu raten – Annahmen über Abhängigkeiten, Namenskonventionen, Architekturmuster, die komplett falsch sein können.

Dann kommt das Review-Problem. Wenn die KI einen 500-Zeilen-Diff zurückliefert – was machst du damit? Du überfliegst ihn. Du vertraust ihm mehr, als du solltest, weil die KI so sicher klingt. Du mergst und hoffst.

Hope is not a quality control process – Hoffnung ist kein Qualitätssicherungsprozess.

Das dritte Problem ist das Hinterhältigste. KI-Modelle sind darauf trainiert, hilfreich zu sein. Das bedeutet, sie sind darauf trainiert, selbstsicher zu klingen. Wenn eine KI dir Code liefert, der vernünftig aussieht, sieht er wahrscheinlich deshalb vernünftig aus, weil sie auf vernünftigen Code trainiert wurde. Das bedeutet nicht, dass er für deinen spezifischen Kontext korrekt ist. Ohne ein Gate, das tatsächliches Verhalten prüft, wird Selbstsicherheit zum einzigen Akzeptanzkriterium – und Selbstsicherheit ist ein furchtbarer Proxy für Korrektheit.

Rein in die Schleife

Die Alternative klingt fast enttäuschend simpel: Statt eines großen Prompts viele kleine Schritte. Nach jedem Schritt: Arbeit prüfen. Dann den nächsten Schritt.

Act. Check. Repeat.

Das ist ein Agentic Loop in seiner grundlegendsten Form. Und wenn das zu offensichtlich klingt, um es zu diskutieren – bedenk, dass die meisten Teams es immer noch nicht tun. Die Magie liegt nicht im Konzept. Sie liegt in der Disziplin, es konsequent durchzusetzen.

So sieht das in der Praxis aus. Statt die KI zu bitten, „alle fehlgeschlagenen Tests zu fixen", würdest du:

1. Testsuite ausführen und den ersten Fehler identifizieren
2. Die KI bitten, genau diesen einen Fehler zu beheben
3. Tests erneut ausführen, um den Fix zu verifizieren
4. Wenn bestanden: weiter zum nächsten Fehler; wenn fehlgeschlagen: Änderung zurücknehmen
5. Wiederholen, bis null Fehler übrig sind – oder die KI meldet, dass sie nicht weiterkommt

Was passiert hier? Jede Änderung wird unabhängig verifiziert. Wenn etwas kaputtgeht, weißt du genau, welcher Edit es verursacht hat. Wenn etwas funktioniert, bleibt es. Die Schleife baut eine Ratchet aus verifiziertem Fortschritt, statt einen Haufen hoffentlich-korrekten Codes.

Die drei Regeln, die es zum Laufen bringen

Nicht alle Schleifen sind gleich. Eine schlecht designte Schleife ist schlechter als keine Schleife überhaupt – sie kann ewig laufen und kosmetische Änderungen vornehmen, oder sie kann selbstsicher Dinge kaputtmachen, während sie tut, als würde sie arbeiten. Die Schleifen, die tatsächlich funktionieren, haben drei unverzichtbare Eigenschaften.

Erstens: ein automatisiertes Gate, das man nicht überreden kann. Das Gate ist dein Wahrheitsdetektor. Es könnte eine bestandene Testsuite sein, ein Linter ohne Fehler, ein Type Checker ohne Typfehler, oder ein automatisierter Screenshot-Vergleich, der visuelle Regressionen erkennt. Der entscheidende Punkt: Das Gate ist deterministisch und objektiv. Du kannst dich nicht daran vorbeireden – und die KI auch nicht. Wenn der Code das Gate nicht passiert, ist er nicht passiert. Reverted, nicht gemergt.

Das ist schwerer, als es sich anhört, denn es bedeutet, Infrastruktur für deine Gates zu bauen. Du brauchst echte Tests mit echter Abdeckung. Du brauchst deinen Type Checker, der wirklich läuft. Du brauchst die CI/CD Pipeline als gleichberechtigten Bürger, nicht als Nachgedanke.

Zweitens: eine Änderung pro Iteration. Das fühlt sich schmerzhaft langsam an, wenn du One-Shot-Prompting gewohnt bist. Warum nicht alle Type-Fehler auf einmal beheben? Warum nicht jede Linting-Warnung in einem Durchlauf adressieren?

Weil – wenn du Änderungen bündelst und etwas kaputtgeht, hast du keine Ahnung, was die Ursache war. Die KI könnte drei Dinge fixen, eines kaputtmachen, und das Gesamtergebnis sieht positiv aus – also wird gemergt. Jetzt hast du eine Regression ohne klaren Schuldigen.

Eine Änderung, eine Verifikation, ein Urteil. Pro Schritt langsamer, aber insgesamt monument schneller, weil jeder Schritt unabhängig prüfbar und revertierbar ist. Wenn etwas in Produktion kaputtgeht, kannst du per Git Bisect die exakte Änderung finden, die es verursacht hat – statt einen halbfertigen Wust aus zusammenhängenden Modifikationen zu debuggen.

Drittens: eine ehrliche Abbruchbedingung. Eine Schleife ohne Abbruchbedingung ist entweder unendlich oder stoppt willkürlich. Beides ist schlecht. Die Abbruchbedingung sollte ein messbares Signal sein: Testcount bei null, ein „nichts zu verbessern"-Report in aufeinanderfolgenden Runden, ein Evaluationsscore, der plateau erreicht.

Die Disziplin hier ist, ehrliche Übersprünge zu akzeptieren. Wenn der Code tatsächlich gut ist, ist die korrekte Ausgabe „changed nothing – nothing needed changing." Eine Schleife, die weiß, wann sie fertig ist, ist zehn Schleifen wert, die marginale Änderungen weiterdrehen, um produktiv auszusehen.

Was Schleifen finden, das Prompts übersehen

Lass mich ein konkretes Beispiel geben, warum das wichtig ist.

Stell dir einen Self-Improvement Loop vor, der auf einem Production Admin Panel läuft. Die Schleife macht Screenshots jeder Seite, bittet die KI, ein Usability-Problem pro Runde zu identifizieren und zu beheben, führt Type Checks und Linting aus, und macht weiter, bis nichts mehr zu verbessern ist.

Über mehrere Runden produziert dieser Loop dutzende echter Verbesserungen. Saubere UI-Politur. Bessere Fehlermeldungen. Intelligentere Empty States.

Aber der wertvollste Fix war kein Polish – es war ein Bug. In einer Runde flaggte der Screenshot-Harness, dass eine Settings-Seite den Full-Page-Crash-Screen des Frameworks rendertes. Das Ding: Dieser Crash war komplett client-seitig. Die API Health Checks waren die ganze Zeit grün gewesen, weil die API in Ordnung war. Ein Mensch, der Screenshots reviewed, hätte vielleicht über diese Seite gescrollt oder es als transienten Rendering-Glitch abgetan.

Der automatisierte Loop hat ihn gefunden, den eigentlichen Fehler extrahiert („Cannot read properties of undefined (reading 'memes')"), ihn auf einen State-Merge-Bug im Component Lifecycle zurückverfolgt und an der Wurzel behoben. Und weil der Harness jetzt weiß, dass er nach diesem Crash-Screen-Pattern suchen muss, wird er diese ganze Bug-Klasse für immer abfangen.

Das ist der Payoff. Eine Schleife macht nicht nur Arbeit – sie baut eine Ratchet, die verifizierte Verbesserungen akkumuliert und verifizierte Regressionen am Zurückkommen hindert.

Warum das für dein Team relevant ist

Wenn du ein Startup aufbaust, hast du keine Zeit für KI-Tools, die ständige Aufsicht brauchen. Wenn du Entwickler bist, hast du keine Geduld für Tools, die mehr Bugs reinbringen als sie beheben.

Agentic Loops adressieren beide Bedenken. Sie machen KI-Unterstützung echt verlässlich, indem sie Vertrauen durch Verifikation ersetzen. Sie machen Fortschritt messbar, indem sie jede Änderung verantwortlich machen. Sie machen Debugging handhabbar, indem sie sicherstellen, dass du, wenn etwas kaputtgeht, genau weißt, wann und warum.

Das Beste daran? Dieser Ansatz ist nicht auf Code-Generierung beschränkt. Dasselbe Pattern funktioniert für automatisierte Tests, Bug Hunting, Security Scanning, Dokumentations-Updates, Dependency Management – überall dort, wo du One-Shot-Prompts benutzt hast, aber von kontinuierlicher Verifikation profitieren könntest.

Ob du allein arbeitest oder ein Team leitest: Die Frage ist nicht, ob du KI zum Coden nutzt. Die Frage ist, ob du sie so nutzt, dass sie dich tatsächlich schneller macht – oder ob sie dich nur beschäftigt aussehen lässt, während sie technischen Schuldenberg vergrößert.

Schleifen sind nicht der einzige Weg, mit KI zu arbeiten. Aber sie sind der einzige Weg, den ich gesehen habe, der zu ernsthafter Produktionsarbeit skaliert, ohne ein Grab voller plausibel-aber-falsch-Code anzuhäufen.

Dein Zug.