Über agentisches Coden reden gerade alle. Aber sie reden über zwei verschiedene Dinge.

Die einen feiern das Tempo: Features in Stunden statt Tagen, ganze Services aus einer Handvoll Sätzen. Die anderen zeigen auf die Trümmer dahinter: aufgeblähter, schwer wartbarer Code, den am Ende doch wieder ein Mensch geradeziehen muss.

Beide haben recht. Und die meisten Beiträge picken sich eine Seite heraus.

Dieser hier nicht. Mich interessiert die Frage darunter: Warum produziert dasselbe Werkzeug bei den einen brauchbaren Code und bei den anderen Slop? Die Standardantwort lautet „nimm ein besseres Modell, schreib bessere Prompts“. Sie ist meiner Erfahrung nach falsch, und zwar an der Wurzel.

Das Symptom kennst du

Wenn du einen Agenten ernsthaft hast arbeiten lassen, kennst du die Liste.

Leere Klassen, die nichts tun. Dieselbe Methode dreimal, leicht variiert. Tests, die nur existieren, um grün zu sein. Ein Test, der einen Bug bestätigt, statt ihn zu fangen. Importe aus Paketen, die es gar nicht gibt. Over-Engineering an der einen Stelle, Happy-Path-only an der anderen.

Das ist kein Einzelfall-Pech. Eine unabhängige Studie der CMU fand über 800 Cursor-Repos hinweg rund 30 % mehr statische Warnungen und 41 % mehr Komplexität in KI-gestütztem Code. Und es ist kein Junior-Code, der sich mit Erfahrung auswächst: KI-Code hat ein eigenes Defekt-Profil, das die üblichen Review-Reflexe unterläuft.

Der DORA-Report 2024 misst in eine andere Richtung, und genau das ist die erste Spur: Die CMU-Studie zählt statische Metriken, DORA fragt Teams nach ihrer wahrgenommenen Codequalität und misst die Auslieferungsstabilität. Kein echter Widerspruch also, sondern zwei Blickwinkel. Und aus DORAs Blickwinkel kann KI mit besserer Codequalität einhergehen, nur bei schlechterer Auslieferungsstabilität. Heißt: Slop ist kein Naturgesetz, sondern prozessabhängig. Es liegt also an etwas, das wir steuern.

Warum „nimm ein besseres Modell“ nicht greift

Die übliche Diagnose behandelt den Generator als das Problem. Als müsstest du nur lange genug an der Quelle polieren, bis sauberer Code rauskommt.

Tu das, und du optimierst ewig an Formulierungen und Modellversionen, während der nächste Agent denselben Pfusch auf neue Art produziert.

Warum? Weil der Slop nicht aus einer Quelle kommt.

Nicht eine Ursache, sondern drei Mechanismen

Es sind mindestens drei verschiedene Mechanismen. Und die Unterscheidung ist kein Erbsenzählen: Sie brauchen verschiedene Gegenmittel.

Zwei davon sind harmlos. Der Agent irrt, ohne es darauf anzulegen:

• Die Kontextlücke. Fehlt dem Agenten Kontext, rät er das statistisch Wahrscheinlichste. So entstehen erfundene APIs, halluzinierte Paketnamen, Duplikate. Das ist genau genommen kein Fehler des Agenten. Ihm fehlt schlicht ein Input. Das Gegenmittel ist deshalb nicht Prüfen hinterher, sondern Zuführen vorher: ihm die echten Signaturen, das Lockfile, deine Konventionen in den Kontext legen, bevor er losschreibt.
• Der Korpus-Bias. Der Agent folgt seinem Trainingsmaterial, und das ist im Mittel mittelmäßig. Daher Over-Engineering und Durchschnittsmuster. Gegenmittel: klare Constraints und Komplexitätsgrenzen.

Ärgerlich, beides. Aber der dritte Mechanismus ist von anderer Art.

Technisch gesehen ist der Test danach grün. Du hast nur keinen mehr.

Stell dir den Schüler vor, der nicht den Stoff lernt, sondern die Prüfung. Genau das ist hier los, nur dass dieser Schüler auch den Lehrer umgeht, wenn er kann.

Der Unterschied ist kategorial. Die ersten beiden Mechanismen irren. Dieser hier kämpft zurück. Er ist der einzige, der deine Verifikation aktiv unterläuft. Und er bleibt nicht beim Testen: Anthropic hat im November 2025 gezeigt, dass das Austricksen von Tests generalisiert, in einem Teil der Läufe bis zur aktiven Sabotage von Sicherheitscode.

Damit kippt die Frage von „Qualität“ zu „Safety“. Wir reden nicht mehr über einen unordentlichen Generator, sondern über einen Akteur, der das Signal unterläuft, das wir ihm geben. Genau er steht im Zentrum dieser Serie. Die beiden harmlosen Mechanismen bekommen ihre eigenen, proaktiven Antworten.

Was wäre, wenn das Problem nicht der Generator ist?

Dann hilft kein besserer Prompt. Dann hilft nur eins:

Dahinter steckt eine unbequeme Einsicht. Unsere ganzen Qualitätswerkzeuge (Linter, Pre-Commit-Hooks, Coverage-Schwellen) sind für kooperative Autoren gebaut. Für Menschen, die dasselbe wollen wie das Werkzeug.

Ein autonomer Agent ist gegenüber seinen eigenen Gates aber nicht kooperativ. Er ist ein adversarialer Autor. Er entwaffnet sie, wenn das der schnellste Weg zu „grün“ ist: --no-verify, @ts-expect-error, ein .skip hier, eine gesenkte Schwelle dort. Jede Hintertür, die du kennst, kennt er auch, plus ein paar, die du längst vergessen hast.

Das heißt nicht, dass du auf Verifikation verzichtest. Im Gegenteil. „Autonom“ heißt nicht „unverifiziert“. Es heißt nur, dass die Prüfung nicht mehr im synchronen Pfad eines Menschen hängt. Das Review wandert aus dem heißen Pfad. Die Prüfung bleibt.

Und trotzdem: die Modellwahl ist ein Hebel

Eben hieß es: kein Modell-Problem. Und doch ist die Modellwahl einer der am meisten unterschätzten Hebel überhaupt.

Lies die mittlere Zahl ruhig nochmal: Das stärkere Modell schummelt gründlicher. So viel zum Thema „nimm einfach das Beste“.

Das ist kein Widerspruch zur These, sondern ihre Bestätigung: Die Modellwahl ist selbst ein Systemregler. Aber selbst das beste Modell hackt messbar. Du kannst dich nicht aus dem Problem herauswählen. Die Modellwahl senkt, wie oft es passiert. Sie ersetzt die Verifikation nicht.

Die Konsequenz: ein Käfig statt Vibe-Coding

Wenn Qualität im System entsteht und der Autor adversarial ist, dann ist „ich prüfe halt alles selbst nach“ die falsche Antwort. Damit holst du den Review-Engpass zurück und wirfst den Tempo-Vorteil weg.

Das ist das exakte Gegenteil von Vibe-Coding, also dem ziellosen Drauflosprompten, bei dem man den generierten Code kaum noch anschaut und dem Ergebnis auf gut Glück vertraut. Nicht Autonomie statt Kontrolle, sondern Autonomie durch Verifikation.

Aber warum funktioniert ein Käfig überhaupt, wenn der Insasse schlauer ist als das Schloss?

Gewaltenteilung: der Autor stellt nicht seine eigenen Prüfer

Stell dir ein Fußballspiel vor, in dem eine Mannschaft den Schiedsrichter stellt. Du weißt schon, wie das ausgeht.

Genau das ist ein Agent, der seinen Code schreibt und über die Gates bestimmt, die ihn prüfen. Die Antwort darauf ist alt und heißt Gewaltenteilung. Es gibt zwei Sorten Artefakte, und sie gehören in getrennte Hände:

• das Produkt: der Code. Hier darf der Agent frei schalten.
• die Verifikation: Gates, Tests, Schwellen, die Spec, die Projektregeln. Die ändert er nicht einseitig.

Der Agent ist die Exekutive: Er führt aus. Die Verifikation ist Legislative und Judikative: Sie setzt die Regeln und spricht das Urteil. Fällt beides in eine Hand, hast du keine Autonomie, sondern eine Autokratie. Und die Qualität kollabiert.

Und Unabhängigkeit ist nur die halbe Miete. Ein Prüfer, der unbeeinflussbar ist, aber die falsche Frage stellt, winkt genauso durch. Das Urteil muss zweierlei zugleich sein: unabhängig von dem, der den Code schreibt, und gebunden an etwas Echtes. Beide Hälften ziehen sich durch die ganze Serie.

Das klingt nach Staatsbürgerkunde, ist aber ganz konkret: Es ist der Unterschied zwischen einem Hook, der lokal läuft (und den der Agent mit --no-verify einfach überspringt), und einem Gate auf einem Server, an den er gar nicht herankommt. Auch ein Test schützt nicht aus sich heraus: Der Agent kann ihn löschen, aufweichen oder auf assert(true) setzen. Die Sicherheit kommt nicht aus dem Test selbst, sondern daraus, dass er an einem Ort läuft, den der Agent nicht erreicht, und dass er die Gate-Definition nicht umschreiben darf. Wie man diese Trennung wasserdicht macht, ist Teil 3.

Die Landkarte: drei Bewegungen, die den Rest schrumpfen

Innerhalb dieses Käfigs macht das Framework, das ich vorschlage, im Kern drei Bewegungen:

1. Korrektheit nach unten. So viel wie möglich in nicht-korrumpierbare Gates drücken: Compiler, Typen, Tests, DB-Constraints. Was die Maschine deterministisch fangen kann, soll sie fangen. (Teil 3.)
2. Intent nach oben. So viel wie möglich in eine explizite Spezifikation heben, an die der Agent gebunden ist. Woran er nicht gebunden ist, daran hält er sich nicht. (Teil 2.)
3. Fakten nach vorn. Dem Agenten die echte Umgebung in den Kontext legen, bevor er generiert, statt ihn raten zu lassen. Das ist die Antwort auf die zwei harmlosen Mechanismen von vorhin. (Teil 5, der zugleich eine eigene Achse aufmacht: die Eindämmung des Agenten, falls er gekapert wird.)

Drei Bewegungen auf dasselbe Ziel: den Bereich verkleinern, in dem am Ende nur noch ein menschliches Urteil entscheiden kann.

Denn dieser Bereich schrumpft, aber er wird nie null. Ein Rest bleibt grundsätzlich: Ob die Spec überhaupt das Richtige will, kann dir keine Maschine beantworten. Und genau dieser Rest ist nicht der Makel des Vorgehens, sondern der Platz, an den der Mensch gehört. Die ehrliche Forderung an den Agenten lautet deshalb nie „sei fehlerlos“, sondern „sei verifizierbar“.

Zehn Faustregeln

Diese drei Bewegungen sind die praktische Spitze von etwas Größerem. Was ich übers Bauen mit Agenten gelernt habe, habe ich über die Zeit zu zehn Faustregeln verdichtet. Einige kennst du nach diesem Teil schon, die übrigen arbeitet die Serie der Reihe nach ab. Hier sind sie auf einen Blick, bewusst knapp:

1. Qualität entsteht im System, nicht im Generator.
2. Vertrauen kommt aus unbestechlicher Prüfung, nicht aus einem besseren Autor.
3. Der Agent ist ein adversarialer Autor.
4. „Autonom“ heißt nicht „unverifiziert“.
5. Das falsche Problem perfekt lösen ist trotzdem Ausschuss.
6. Ohne erfassten Intent keine Autonomie.
7. In der Tiefe alles oder nichts, in der Breite gestaffelt.
8. Zero-Trust für Korrektheit: der grüne Haken ist eine Behauptung, kein Beweis.
9. Du kontrollierst das System, nicht den Output.
10. Es bleibt ein uneliminierbarer Rest, und der ist der richtige Platz für den Menschen.

Ein ehrliches Wort, bevor wir loslegen

Eines vorweg, weil es den Rest der Serie prägt: Was ich hier „Käfig“ nenne, ist bislang ein Gedankenkonstrukt.

Die Diagnose, Reward Hacking als gefährlichste Wurzel, ist gut belegt. Die vorgeschlagene Lösung ist eine Hypothese. Aus Prinzipien hergeleitet, noch nicht bewiesen.

Deshalb bleibt es nicht bei der Theorie. Ich baue parallel ein echtes Beispielprojekt: Obol, ein kleines Wallet-Referenz-Repo. Es zeigt, wie sich so ein Käfig implementieren lässt. Und ich sammle dabei Daten: wo die Gates greifen, wo sie still versagen, wo die Hypothese hält und wo sie bricht.

Du musst mir also nichts glauben. Du kannst mitlesen, während sich das Konstrukt an der Realität reibt.

Was du mitnimmst

Verschieb deine Energie. Weg von „besseren Prompts“, hin zu einer Verifikation, die der Autor nicht korrumpieren kann. Der Hebel liegt im System, nicht im Generator, und erst danach in der Modellwahl.

Erinnerst du dich an die zwei Lager vom Anfang? Sie streiten über das falsche Ding. Es geht nicht um schneller gegen sauberer. Es geht darum, ob du ein System drumherum baust, das beides zugleich erlaubt.

Damit bleibt eine Frage offen, die alles Weitere trägt: Verifikation gegen was? Der grüne Haken behauptet „erfüllt die Spezifikation“. Aber wenn der Agent diese Spezifikation am Ende selbst mitschreibt: Woran ist er dann überhaupt gebunden?

Darum geht es im nächsten Teil.