Warum Ihr Agent niemals aufhört

Warum Ihr Agent niemals aufhört Image: AI generated

Das 24/7-Prahlen

„Ich lasse meinen Agenten 24 Stunden am Tag laufen."

Ein Satz, den man auf X häufig sieht. Als ob ein Agent mehr leisten würde, je länger er läuft. Als ob ein Mensch produktiver wäre, wenn er nicht schläft.

Doch angesichts dieses Satzes stellt sich nicht Bewunderung ein, sondern eine Frage.

„Warum ist er noch nicht fertig?"

Ein System, das anhalten kann, ist ein gesundes System

Ich habe einem Agenten die Aufgabe übertragen, Tests für 527 Funktionen zu schreiben. Das Ergebnis:

Autonomer Agent:  40 / 527 erledigt, dann „Fertig" erklärt
CLI-Schleife:     527 / 527 vollständig durchlaufen, dann beendet

Die CLI-Schleife brauchte eine Stunde. Nicht 24 Stunden. Sie bearbeitet eine Funktion, verifiziert sie, geht bei Erfolg zur nächsten über und hält an, wenn alles erledigt ist. Der Kern dieser Schleife ist nicht die Geschwindigkeit, sondern dass die Terminierungsbedingung mechanisch definiert ist.

TODO → Test schreiben → Coverage messen → PASS/DONE → nächste → ... → alles erledigt → Stopp

finite. measurable. monotonic. Deshalb konvergiert sie. Deshalb hält sie an.

Anhalten zu können ist keine Schwäche. Es bedeutet, gesund zu sein.

Drei Gründe, warum ein Agent nicht aufhört

Dass ein Agent über lange Zeit läuft, hat in der Regel einen von drei Gründen.

1. Der Verifizierer ist schwach

"looks good"
"seems better"
"more scalable"
"clean architecture"

Das sind keine Konvergenzkriterien. Das sind subjektive Urteile. go test liefert pass/fail zurück, aber wer entscheidet über „clean architecture"? Ein anderes LLM? Das ist, als würde man einen betrunkenen Freund fragen: „Bin ich betrunken?"

Empirische Befunde stützen das. LLM-Richter zur Code-Bewertung lassen sich schon von oberflächlichen Varianten bedeutungsgleichen Codes verzerren, sodass Punktzahlen aufgebläht oder ungerechtfertigt gekürzt werden (Moon et al. 2025), und Modelle beugen ihre eigene Antwort in 58,19 % der Fälle aus Gefälligkeit (SycEval, Fanous et al. 2025). „looks good" hat nichts mit Korrektheit zu tun. Hinzu kommt, dass ein schwaches Kriterium nicht nur dafür sorgt, dass nichts anhält – wird die Messung zum Ziel, verkommt die Messung (Goodharts Gesetz; Manheim & Garrabrant 2018), und leistungsfähige Reasoning-Modelle lösen die Aufgabe nicht frontal, sondern hacken das Verifikationsverfahren selbst (Bondarenko et al. 2025).

Ohne Konvergenzkriterium gibt es kein Ende.

2. Die Aufgabe hat keine Grenzen

"Verbessere die Codebasis"
"Mach die Architektur sauberer"
"Optimiere immer weiter"

Das sind Aufgaben ohne Terminierungsbedingung. Auch menschliche Entwickler irren mit solchen Zielen endlos umher. Beim Agenten ist es nicht anders. „Verbessern" ist eine Richtung, kein Ziel.

3. Die Entropie übersteigt die Korrekturgeschwindigkeit

Das häufigste und heimtückischste Muster.

Der Agent fügt bei jeder Änderung Abstraktionen hinzu. Er führt Indirektionen ein. Er schafft unnötige Generalisierungen. Der Code scheint „besser zu werden", aber in Wahrheit wächst die neue Entropie schneller, als der Verifizierer sie entfernt.

Die heute geschaffene Abstraktion → wird morgen wieder entfernt → übermorgen wieder hinzugefügt

Das ist nicht-monotone Optimierung (non-monotonic optimization). Es sieht aus wie Fortschritt, ist aber Stillstand. Es sieht aus wie ein Perpetuum mobile, verbraucht aber nur Energie. In diesem Fall ist die Energie der Token.

Großangelegte empirische Studien erfassen diese Drift. Die Einführung von Cursor steigerte zwar die kurzfristige Geschwindigkeit, doch Warnungen der statischen Analyse und die Codekomplexität nahmen kontinuierlich zu, und diese Akkumulation war die Hauptursache der langfristigen Verlangsamung (He et al. 2025, 807 Open-Source-Repositories). In über 300.000 von KI verfassten Commits überlebten 22,7 % der eingeführten Probleme bis zur aktuellen Version als technische Schuld (Liu et al. 2026). Die Korrektur holt die Entropie nicht ein.

Kein Suchproblem, sondern ein Constraint-Satisfaction-Problem

Hier zeigt sich ein grundlegender Unterschied in der Sichtweise.

„Lässt man den Agenten lange laufen, kommt ein besseres Ergebnis heraus" – das ist der Blick, der Softwareentwicklung als Suchproblem (search problem) versteht. Die Erwartung, dass eine lange Suche in einem weiten Raum eine bessere Lösung findet.

Doch Softwareentwicklung ist im Kern ein Constraint-Satisfaction-Problem (constraint satisfaction problem).

Die Typen müssen stimmen
Die Tests müssen bestehen
Die Coverage muss erfüllt sein
Das Schema muss übereinstimmen
Die Lint-Regeln müssen eingehalten werden

Sind all diese Constraints erfüllt, ist Schluss. Es gibt nichts „mehr zu suchen". Constraints definieren, erfüllen und anhalten. Das ist alles.

Code ist bereits eine maschinell prüfbare Domäne (machine-checkable domain). Compiler, Typechecker, Tests, Coverage, Linter, Schema-Validierung – all das sind deterministische Verifizierer. Warum lässt man den Agenten endlos suchen, wo diese Verifizierer doch existieren?

Auch die Forschung zum Lernen weist in dieselbe Richtung. Nutzt man deterministische Verifizierer wie Unit-Tests als Belohnung – einen verifiable reward –, steigt die Code-Korrektheit gegenüber offener Generierung (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). Der Verifizierer ist kein Werkzeug, das die Suche eingrenzt. Er ist der Beleg dafür, dass dieses Problem von vornherein keine Suche ist, sondern Erfüllung.

Die Bedingungen einer guten Schleife

Eine gute Agentenschleife schließt sich in fünf Schritten:

1. Aufgabe definieren   — Was soll erreicht werden (mechanisch entscheidbares Ziel)
2. Umfang begrenzen     — eine Einheit nach der anderen (Funktion, Endpunkt, Datei)
3. Symbolische Prüfung  — deterministisches Werkzeug fällt pass/fail-Urteil
4. Konvergenz           — bei Erfolg weiter, bei Fehler mit Feedback erneut
5. Terminierung         — gibt es keine offenen Punkte mehr, Stopp

In dieser Struktur übernimmt das LLM nur Schritt 3 (die Generierung). Alles andere erledigt die Maschine. Entscheidend ist insbesondere, dass die Maschine das „Ende" bestimmt. Überlässt man dem LLM die Terminierungsentscheidung, hört man bei 40/527 ein „Fertig".

Auch die Experimente weisen in dieselbe Richtung. Hängt man einem LLM Selbstkritik (self-critique) an, bricht die Leistung bei Reasoning- und Planungsaufgaben sogar ein und verbessert sich nur dann deutlich, wenn man einen externen, soliden Verifizierer anhängt (Stechly et al. 2024). Intrinsische Selbstkorrektur ohne externes Feedback scheitert oder verschlechtert das Ergebnis nach der Korrektur mitunter sogar (Huang et al. 2023). Es hat seinen Grund, die Terminierung nicht dem LLM zu überlassen.

Creative Writing und Code sind verschieden

Es gibt eine Ausnahme. Nicht jede Domäne ist so.

Schreiben, Marketing, Design – in diesen Bereichen ist der Verifizierer schwach. „Ist dieser Satz gut?" lässt sich nicht mechanisch entscheiden. In solchen Bereichen kann eine lange Suche sinnvoll sein. Der Agent generiert mehrere Varianten, und der Mensch wählt aus.

Code aber ist anders. Code ist bereits eine Welt voller deterministischer Verifizierer. In dieser Welt ist langes Umherirren (wandering) keine Suche, sondern Drift.

Die Frage

Wie viele Stunden läuft Ihr Agent gerade schon?

Konvergiert er, oder driftet er?

Kann er anhalten?

Und wenn er anhalten kann: Warum hat er noch nicht angehalten?

Weiterführende Lektüre (extern)

Designing agentic loops — Simon Willison. Nur mit klaren Erfolgskriterien und einer bestehenden Testsuite kann sich eine Agentenschleife selbst verifizieren und anhalten – das konstruktive Gegenstück zu diesem Artikel.
Building Effective Agents — Anthropic. Coding ist ideal für Agenten, weil sich die Lösung durch automatisierte Tests verifizieren lässt – der deterministische Verifizierer wird zum Stoppsignal.
Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. Die zentrale Designentscheidung ist nicht ein besseres Modell, sondern eine messbare Terminierungsbedingung; und er warnt vor dem „confidence laundering", bei dem flüssiger Output die Nicht-Konvergenz verdeckt.
Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. Zuverlässigkeit entsteht nicht aus dem Modell, sondern aus einer Harness deterministischer Werkzeuge (computational controls) – abzugrenzen von KI-gestützten, inferenziellen Kontrollen.
Reward Hacking in Reinforcement Learning — Lilian Weng. „Wird eine Messung zum Ziel, ist sie keine gute Messung mehr" – eine technische Aufbereitung des Mechanismus, mit dem ein schwacher Verifizierer als Belohnung den Proxy gamen lässt.
Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. Je mehr Input-Token sich anhäufen, desto schlechter wird der Output – die mechanische Ursache dafür, dass eine Schleife aus Hinzufügen, Entfernen und erneutem Hinzufügen nicht Selbstkorrektur, sondern Selbstverstärkung wird.
Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. KI verstärkt die vorhandene Sorgfalt – bei geringer Sorgfalt beschleunigt sie das Chaos; eine praxisnahe Perspektive auf das Phänomen, dass Entropie der Korrektur davonläuft.

Quellen

Terminierungsentscheidung · Grenzen der Selbstverifikation

Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · Unzuverlässigkeit der Selbstkritik

Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Drift · Zunahme der KI-Codekomplexität

He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Verifizierbare Belohnung · Verifizierer-basierte Codegenerierung

Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward Hacking · Specification Gaming

Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)