This blog post is also available in English
Wer Agenten ohne Tests, Linting oder Architektur-Constraints arbeiten lässt, merkt schnell, wohin das führt. Der Code kompiliert, funktioniert vielleicht sogar, aber niemand kann mehr sagen, was passiert, wenn man an einer Stelle etwas ändert. Die Struktur erodiert, Boundaries verschwimmen, und nach ein paar Wochen hat man einen klassischen Big Ball of Mud, nur dass er diesmal in Rekordzeit entstanden ist.
Das eigentliche Problem ist dabei nicht, dass Agenten schlechten Code schreiben. Sie schreiben den Code, den man ihnen erlaubt zu schreiben, und ohne Guardrails ist alles erlaubt. Das skaliert nicht — schon gar nicht mit der Geschwindigkeit, die Agenten mitbringen. Vibe Coding, das Generieren von Code auf Zuruf ohne systematische Kontrolle, fühlt sich anfangs wie ein enormer Produktivitätssprung an. Aber ohne Richtung produziert man vor allem schneller technische Schulden.
Die Frage ist eigentlich simpel: Wenn ich nicht mehr jede Zeile lese, wie übernehme ich trotzdem Ownership über den Code? Die Antwort darauf liegt näher als gedacht, denn wir haben dieses Problem schon einmal gelöst.
Das Problem ist nicht neu
Stell dir vor, du steigst in ein bestehendes Projekt ein. Das Team hat gewechselt, die ursprünglichen Entwickler sind längst weg, und du erbst 200.000+ Zeilen Code. Du verstehst nicht jede Zeile, nicht mal jedes Modul. Trotzdem shipst du Features, fixt Bugs und übernimmst Verantwortung. Das ist normaler Brownfield-Alltag, und jeder von uns hat das schon gemacht.
Niemand würde erwarten, dass du in einem Brownfield-Projekt erst jede Zeile gelesen und verstanden haben musst, bevor du einen Pull Request öffnen darfst. Stattdessen verlässt du dich auf Systeme: Tests sagen dir, ob du etwas kaputt gemacht hast, Linter setzen Konventionen durch, CI-Pipelines fangen Fehler ab, bevor sie es in die Produktion schaffen. Du verstehst den Teil, den du anfasst, und vertraust darauf, dass der Rest abgesichert ist.
Und genau das ist die Erkenntnis, auf die es ankommt: Für Ownership muss ich nicht jede Zeile kennen. Für Ownership muss ich sicher sein, dass meine Änderung funktioniert und nichts kaputt macht.
KI-generierter Code ist im Grunde nichts anderes als Code von einem Kollegen, der nicht mehr im Raum sitzt, nur dass dieser Kollege deutlich schneller und deutlich mehr produziert. Was Brownfield überhaupt erst möglich macht, ist gute Modularisierung: Lose Kopplung, Hohe Kohäsion. Gut geschnittene Module erlauben es dir, einen kleinen Teil zu verstehen und sicher zu verändern, ohne das Gesamtsystem im Kopf haben zu müssen. Agenten profitieren davon genauso, denn je besser die Modulschnitte, desto fokussierter und fehlerfreier arbeiten sie.
Das Wissen, wie man Code besitzt, den man nicht geschrieben hat, steckt also schon in uns. Die Frage ist nur, wie wir es auf die Arbeit mit Agenten übertragen.
Von der Spreadsheet zur Lint Rule
Boris Cherny, heute bekannt als Creator von Claude Code, liefert dafür ein gutes Beispiel im Podcast von The Pragmatic Engineer. Bei Meta war er einer der produktivsten Code Reviewer, und seine Methode war überraschend analog: ein Spreadsheet. Jedes Mal, wenn er in einem Review denselben Kommentar hinterließ, etwa „Bitte kein any hier” oder „Fehlerbehandlung fehlt”, trug er ihn in die Liste ein. Tauchte dasselbe Feedback drei- bis viermal auf, schrieb er eine Lint Rule dafür.
Das Prinzip dahinter: Repetitives menschliches Feedback wird zu automatisierter Durchsetzung. Statt immer wieder dasselbe in Code Reviews zu sagen, baut man ein System, das es für einen sagt. Der Reviewer wird zum Systemdesigner.
Dass sich dieser Aufwand lohnt, ist auch messbar. Eine interne Studie bei Meta hat gezeigt, dass saubere Codebases einen zweistelligen Prozent-Impact auf die Engineering Productivity haben. Halbfertige Migrationen, inkonsistente Patterns und veraltete Konventionen verlangsamen nicht nur menschliche Entwickler, sondern verwirren KI-Modelle genauso. Ein Agent, der in einer Codebase mit drei verschiedenen Fehlerbehandlungs-Patterns arbeitet, wird alle drei reproduzieren. Konsistenz ist die Grundlage dafür, dass sowohl Menschen als auch Agenten effektiv arbeiten können.
Chernys Spreadsheet-Methode klingt fast banal, aber sie enthält ein Prinzip, das im Kontext von KI-Agenten eine ganz neue Dimension bekommt. Dazu gleich mehr.
Der Agent Harness — mehr als nur das Tool
Wenn wir das Prinzip „wiederkehrendes Feedback in Tooling umwandeln” ernst nehmen, stellt sich die Frage: Wo lebt dieses Tooling eigentlich? In welchem System greifen Lint Rules, Tests, Architektur-Checks und Prompts ineinander?
Die Antwort ist der Agent Harness. Im Kern ist das zunächst das Agent-Programm selbst, also Claude Code, Codex oder Cursor mit seiner Agentic Loop. Über Hooks können wir dort direkt integrieren und dem Agenten bei jeder Aktion Feedback geben. Aber zum Harness gehört auch der Agent Workflow drumherum: die Umgebung, in der der Agent arbeitet. Über Git Hooks und CI/CD-Pipelines können wir auch dort ansetzen und dem Agenten Feedback geben, bevor Code überhaupt gemergt wird.
Die zentrale Frage ist: Wenn ich einen neuen Constraint durchsetzen will, an welchem Integrationspunkt baue ich ihn ein? Zwei Pyramiden helfen bei dieser Entscheidung, beide inspiriert von der Testpyramide.
Die Tooling Pyramid deckt die deterministische Seite ab. Am Fundament stehen Agent Hooks, die vor oder nach Tool Calls ausgeführt werden. Weil sie bei fast jeder Aktion des Agenten laufen, müssen die integrierten Funktionen extrem schnell sein. Alles was länger dauert, bremst den Agenten bei jedem einzelnen Schritt aus. Darüber liegen Git Hooks (Pre-Commit, Pre-Push), die seltener laufen und deshalb auch etwas mehr Zeit kosten dürfen. Hier passen Formatter, Linter oder schnelle Tests gut rein. An der Spitze steht CI/CD. Dort landen Checks, die so lange dauern, dass man sie nicht zusätzlich lokal laufen lassen will, etwa umfangreiche Testsuiten oder Security Scans. Das Prinzip ist dasselbe wie bei der Testpyramide: Was immer laufen soll, muss schnell sein. Was langsamer ist, gehört weiter nach oben.
Die Prompt Pyramid adressiert durch Prompts alles, was sich nicht deterministisch prüfen lässt. Das Sortierkriterium hier ist der Grad der Spezialisierung: Je allgemeiner eine Information ist, desto weiter unten gehört sie, weil sie bei jeder Aufgabe relevant ist. Je spezifischer, desto weiter oben, weil sie nur in bestimmten Situationen gebraucht wird. An der Basis stehen CLAUDE.md und Global Rules, die immer im Kontext des Agenten geladen sind. In der Mitte stehen Conditional Rules, die gelten wenn der Agent in bestimmten Bereichen der Codebase arbeitet, und Skills, die geladen werden wenn der Agent eine bestimmte Art von Aufgabe erledigt. An der Spitze stehen Docs, Specs und ADRs, die nur on-demand verfügbar sind wenn der Agent sie aktiv braucht. Im Kern ist das Context Engineering: die richtige Information zur richtigen Zeit im Kontext, ohne das Token-Budget zu sprengen.
Die Entscheidungsregel zwischen den beiden Pyramiden: If you can tool it, tool it. If you can’t, prompt it. Was sich deterministisch prüfen lässt, gehört in die Tooling Pyramid. Architekturentscheidungen, Domain-Konventionen oder Stilfragen sind dafür zu lose und gehören in die Prompt Pyramid. Deterministische Durchsetzung ist Prompts gegenüber grundsätzlich vorzuziehen.
Der Harness ist nie fertig
Ein Agent Harness ist nichts, das man einmal aufsetzt und dann vergisst. Er wächst mit jedem PR, den man reviewt.
Der Zyklus beginnt unspektakulär: Der Agent produziert einen Pull Request, und im Review fällt ein Problem auf, zum Beispiel ein Import aus einer Schicht, die nicht zugreifen darf, oder ein Test ohne Assertions. Bis hierhin normaler Entwickleralltag. Aber jetzt kommt die entscheidende Frage: Gibt es Tooling, das dieses Problem automatisch erkennen könnte?
Wenn ja, wird es integriert: vielleicht eine neue Lint Rule oder ein ArchUnit-Test. Ab sofort läuft der Agent beim nächsten Mal gegen dieses neue Tooling und bekommt das Feedback nicht erst im Review, sondern sofort. Wenn der Check fehlschlägt, fixt er das Problem selbst, bevor ein Mensch es je sieht.
Das ist ein inkrementeller Prozess, aber die Wirkung ist kumulativ: Jedes Problem, das einmal als Tooling kodifiziert wird, taucht nie wieder auf. Nach Wochen hat der Harness dutzende solcher Checks. Nach Monaten ist er ein dichtes Sicherheitsnetz, das genau die Qualitätsanforderungen des Projekts widerspiegelt.
Hier schließt sich der Kreis zu Boris Cherny. Er trackte wiederkehrende Review-Kommentare in einer Spreadsheet und machte daraus Lint Rules — genau dasselbe Prinzip. Nur dass es mit Agenten eine neue Qualität bekommt, denn der Agent produziert nicht nur den Code, er hilft auch beim Bauen des Toolings. Die Spreadsheet war manuell, der Feedback Loop mit Agenten ist ein sich selbst verstärkender Kreislauf. Mit genug Feedback und Zeit konvergieren Agenten auf die richtige Lösung, nicht durch Magie, sondern durch systematisches Feedback, konsequent angewendet.
Was der Mensch noch ownen muss
Tooling macht Code korrekt, aber es prüft nicht, ob der Code das Richtige tut. Linter fangen Style-Probleme ab, Typ-Checks verhindern Laufzeitfehler, Architektur-Tests sichern Boundaries. Ob die Geschäftslogik stimmt, kann aber kein Hook beantworten.
Das ist auch die subtilste Gefahr bei Agent-generiertem Code: Tests verifizieren die Annahmen des Agents. Wenn die Annahmen falsch sind, sind die Tests trotzdem grün. Ein konkretes Beispiel: Der Agent implementiert eine Rabattberechnung und schreibt Tests dafür, aber beides basiert auf demselben Missverständnis der fachlichen Anforderung. Der Feedback Loop greift hier nicht, weil es nichts gibt, wogegen er prüfen könnte.
Deshalb bleibt die Business Logic beim Menschen. Nicht jede Zeile und nicht jede Datei, aber die Stellen, an denen fachliche Entscheidungen getroffen werden. Das hat Konsequenzen für die Architektur: Wer will, dass dieser Review effizient funktioniert, muss dafür designen. Domain Layer isolieren, Fachlogik von Infrastruktur trennen. Nicht weil es theoretisch schön ist, sondern weil es den menschlichen Review auf das fokussiert, was nur ein Mensch prüfen kann. Den Rest sichert das Tooling ab.
Der Mindset Shift — vom Vibe Coder zum Agentic Engineer
Vibe Coder generieren Code auf Zuruf, ohne jegliche Qualitätssicherung, und hoffen, dass das Ergebnis passt. Agentic Engineers arbeiten genauso schnell mit Agenten, aber sie investieren in ihren Harness: Constraints, Feedback-Systeme, deterministische Checks. Sie können sich auf die Fachlichkeit konzentrieren, weil ihre Systeme den Rest absichern. Was die beiden unterscheidet, ist nicht Geschwindigkeit, sondern Kontrolle. Und wer diese Kontrolle hat, kann am Ende auch Ownership für seine Systeme übernehmen.