This blog post is also available in English
KI-Agenten schreiben Code. Viel Code. Schnell. Wer mehrere Agenten parallel laufen lässt, bekommt in wenigen Stunden tausende Zeilen neuen Code. Letzte Woche hat einer meiner Agenten in anderthalb Stunden ein komplettes Feature umgesetzt – 4.500 Zeilen, sauber strukturiert, Merge Request erstellt. Hat einfach funktioniert. Dann habe ich kurz nachgerechnet: Ein gründliches Review hätte mich zwei, vielleicht drei Tage gekostet.
Das ist die Realität, über die niemand gerne spricht: Während ich den ersten Merge Request durchgehe, produziert der Agent längst die nächsten 10.000 Zeilen. Wer alles lesen will, wird zum Flaschenhals. Man bremst genau die Produktivität aus, die man sich von den Agenten erhofft hat.
OpenAI hat in einem internen Experiment gezeigt, was bereits möglich ist: Ein Team von drei Ingenieuren baute in fünf Monaten rund eine Million Zeilen Code – ohne eine einzige manuell geschriebene Zeile. 3,5 Pull Requests pro Ingenieur pro Tag.[1] Wer glaubt, diesen Output mit klassischem Code-Review beherrschen zu können, hat die Rechnung ohne die Agenten gemacht.
Ich lese nicht mehr alles. Ich schaue mir nur noch die wichtigen Dinge an. Aber wie entscheide ich, was wichtig ist? Und vor allem: Wie übernehme ich Verantwortung für Code, den ich nicht vollständig gelesen habe?
Das kennen wir doch schon
Aber ist das wirklich ein neues Problem? Ich behaupte: nein.
Ein neues Teammitglied steigt in ein Projekt ein, die ursprünglichen Autoren sind längst weg – und trotzdem wird produktiv weitergearbeitet. Für neue Features wird Verantwortung übernommen, obwohl das neue Teammitglied nicht jede Zeile der Codebasis kennt. Was ermöglicht das? Nicht die Hoffnung, dass der Code schon funktionieren wird. Sondern handfeste Dinge: eine verständliche Architektur, eine Test-Suite, die sofort anschlägt, wenn eine Änderung etwas anderes kaputt macht, brauchbare Dokumentation, eine CI-Pipeline die Fehler fängt. Nur so ist Brownfield-Entwicklung überhaupt möglich.
Agenten sind wie diese neuen Teammitglieder – nur dass jede neue Session ein frisches Onboarding braucht. Das geht am besten, wenn sie nur kleine Teile der Anwendung verstehen müssen, um Änderungen machen zu können. Was dabei hilft, sind dieselben Dinge wie im Brownfield: eine klare Struktur, gute Tests und verständliche Dokumentation.
Genau diese Umgebung – Tests, Architektur-Checks, Dokumentation, CI-Pipelines – ist das, was den Unterschied macht. In der Agentenwelt hat sich dafür ein Begriff etabliert: der Agent Harness.
Was ist ein Agent Harness?
Charlie Guo bringt es auf den Punkt: Ein Agent Harness ist «the set of constraints, tools, documentation, and feedback loops that keep an agent productive and on track».[2] Die Formel dahinter: Model + Harness = Agent.[3] Ein gutes Modell allein reicht nicht – was den Unterschied in der Codequalität macht, ist der Harness.
Die Kernphilosophie dahinter ist radikal praktisch: Mechanische Durchsetzung statt Hoffnung. Mitchell Hashimoto, der den Begriff «Harness Engineering» geprägt hat, formuliert das Prinzip so: «Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.»[4] Nicht darauf vertrauen, dass der Agent es beim nächsten Mal besser macht – sondern Feedback-Loops und deterministische Checks bauen, die den Fehler beim nächsten Mal automatisch abfangen.
Meine Überzeugung, die sich mit jeder Woche Praxis verstärkt: Der Harness ist das Wichtigste an der ganzen Gleichung. Aus meiner Erfahrung liefert ein solides Modell mit einem durchdachten Harness bessere Ergebnisse als ein Spitzenmodell ohne Leitplanken. Deshalb investiere ich den Großteil meiner Zeit nicht in bessere Prompts, sondern in einen besseren Harness.
Aber wie sieht so ein Harness konkret aus?
Wie ein Harness in der Praxis aussieht
In meinen Projekten hat sich der Harness als mehrschichtiges Sicherheitsnetz entwickelt. Vier Schichten, die aufeinander aufbauen – jede fängt ab, was die vorherige durchlässt.
Deterministische Guardrails – die erste Verteidigungslinie
Alles, was sich automatisiert prüfen lässt, prüfe ich automatisiert. Und zwar auf zwei Ebenen: In Pre-Commit-Hooks laufen die schnellen Checks – Unit-Tests, Integrationstests, Architektur-Tests mit ArchUnit, Linting und Formatting. In der CI-Pipeline folgen die schwereren Geschütze: E2E-Tests, Security-Scans, statische Code-Analyse. Die Liste wächst mit jedem Fehler, den ein Agent macht – ganz im Sinne von Hashimotos Prinzip.
Die Pre-Commit-Hooks sind der entscheidende Mechanismus. Sie sind das Tor: Solange diese Checks nicht grün sind, darf der Agent nicht committen. Keine Ausnahmen, keine Warnings – Zero-Warning-Tolerance. Der Agent läuft gegen die Wand, bekommt die Fehlermeldung und korrigiert sich selbst.
KI-Reviews – der zweite Blick
Ein zweiter Agent reviewt den Code des ersten. Das klingt erstmal redundant, aber in der Praxis ist es überraschend effektiv – gerade weil der Review-Agent einen eigenen, unabhängigen Kontext hat. Er kennt nicht den Entstehungsprozess, sondern nur die Änderungen, das Ticket und die Akzeptanzkriterien. Auf dieser Basis prüft er, ob der Merge Request das Geforderte erfüllt, sucht nach Architektur-Verletzungen und findet Code Smells, die statische Analyse nicht erkennt.
Wenn sowohl die deterministischen Checks als auch ein KI-Review grün zeigen, steigt mein Vertrauen deutlich. Das ersetzt kein menschliches Review komplett. Aber es ergänzt es um eine Schicht, die schnell und konsistent arbeitet.
Selektives menschliches Review – die wichtigen Stellen
Hier passiert der eigentliche Shift: Ich lese nicht mehr alles. Ich schaue mir gezielt die Core-Business-Logik an. Macht der Agent wirklich das, was ich erwarte? Stimmt die fachliche Entscheidung? Bildet der Code die Domäne korrekt ab?
Boilerplate, Mapping-Code, Standard-Patterns – das überlasse ich dem Harness. Wenn die ersten beiden Schichten grün zeigen, muss ich mich hier nicht mehr eingraben. Man lernt mit der Zeit, wo man reinschauen muss und wo nicht. Dieses Gespür entwickelt sich mit jedem Feature, das man mit Agenten baut.
Produkttest – funktioniert es wirklich?
Am Ende zählt nur eins: Tut die Software, was sie soll? Ich teste das Feature, prüfe das Verhalten, klicke mich durch die Anwendung. Preview-Umgebungen, die automatisch pro Merge Request hochgefahren werden, machen das einfach – ein schneller Weg, das Ergebnis zu prüfen, bevor es in Produktion geht. Alle Qualitätsmetriken können perfekt sein – wenn das Feature nicht das tut, was der Nutzer braucht, ist alles wertlos.
Wenn der Harness grün zeigt, die KI-Reviews passen, das selektive Review keine Überraschungen bringt und das Feature funktioniert – dann kann ich ausliefern. Nicht blind, nicht naiv, sondern mit einem Vertrauen, das auf mehreren unabhängigen Prüfschichten basiert.
Aber dieser Harness ist kein Selbstläufer.
Was der Harness nicht ist: eine Lizenz zum Wegschauen
Einfach Agenten in ein Legacy-Projekt schmeißen und einen 10x Boost erwarten – das ist Utopie. Wer allerdings schon vorher gute Softwareentwicklung gemacht hat – Tests, saubere Architektur, Dokumentation, isoliert testbare Komponenten – der hat den Großteil des Harness bereits und kann KI-Agenten relativ einfach integrieren. Wer hingegen einen Big Ball of Mud geerbt hat, muss erstmal investieren: Dokumentation aufbauen, Testbarkeit herstellen, Strukturen schaffen. Das ist kein Wochenendprojekt.
Meine Erfahrung zeigt: Mit einem durchdachten Harness verschiebt sich die Art der Kontrolle. Es geht nicht mehr darum, jede Zeile zu lesen. Es geht darum, die richtigen Stellen zu lesen – die Core-Business-Logik, die fachlichen Entscheidungen. Den Rest überlässt man dem Harness. Entscheidend ist gezieltes Hinschauen: Wie wahrscheinlich ist ein Fehler? Wie schwer wiegt er? Wie leicht entdeckt ihn der Harness?[5] Je mehr der Harness automatisch erkennt, desto weniger muss ich manuell prüfen.
Ein gut aufgebauter Harness erkennt vor allem strukturelle Probleme und sorgt dafür, dass der Code lesbar und beherrschbar bleibt – auch für Menschen. Weil alles in Isolation testbar sein muss, kann ich jederzeit in einzelne Teile reinschauen, ohne das große Ganze verstehen zu müssen. Was der Harness nicht zuverlässig erkennt: ob das Feature am Ende tut, was es soll. Diese funktionale Verifikation bleibt beim Menschen.
Der beste Praxistest: Would you ship this if you were on call tonight?[6] Wenn die Antwort nein ist, ist der Harness nicht stark genug – egal wie grün die Pipeline leuchtet.
Wer heute in seinen Harness investiert, kann morgen mit einer Geschwindigkeit arbeiten, die vorher nicht möglich war – und trotzdem Verantwortung für jedes ausgelieferte Feature übernehmen.
Referenzen
[1] OpenAI, «Harness engineering: leveraging Codex in an agent-first world», 11. Februar 2026.
[2] Charlie Guo, «The Emerging 'Harness Engineering’ Playbook», Artificial Ignorance, 22. Februar 2026.
[3] Simon Willison, «How I think about Codex», 22. Februar 2026.
[4] Mitchell Hashimoto, «My AI Adoption Journey», 5. Februar 2026.
[5] Birgitta Böckeler, «To Vibe or Not to Vibe», martinfowler.com, 23. September 2025.
[6] Birgitta Böckeler, «I Still Care About the Code», martinfowler.com, 9. Juli 2025.