Coding Agents produktiv: was ein Agentic Harness leistet

So arbeitet ein Agent mit Rahmen

Ein Entwickler übergibt ein Ticket: ein neuer Export im CSV-Format. Der Agent liest zuerst die Projektregeln im Repository. Er findet den bestehenden Export-Dienst und erweitert ihn, statt einen zweiten zu bauen. Er schreibt die Tests dazu, lässt Build, Linter und Testsuite laufen, behebt zwei Fehler selbst und legt die Änderung zum Review vor.

Der Reviewer prüft dann nur noch, was Maschinen nicht beurteilen: Löst die Änderung das richtige Problem, und passt sie zur Richtung des Produkts? Das ist das Ziel. Ob ein Team es erreicht, entscheidet nicht das Modell, sondern der Rahmen, in dem der Agent arbeitet.

Warum viele Teams diesen Effekt nicht sehen

Derselbe Agent ohne Rahmen arbeitet mit dem, was er gerade sieht: der Aufgabe, den offenen Dateien und seinem allgemeinen Wissen. Die Konventionen des Projekts, die Architekturentscheidungen der letzten Jahre und ihre Gründe kennt er nicht. Das Ergebnis ist Code, der kompiliert und plausibel aussieht, aber neben der bestehenden Struktur steht.

Solcher Code landet im Review, und dort kostet er mehr Zeit als offensichtlich fehlerhafter. Wenn der Agent in zehn Minuten erzeugt, was zwei Stunden Review braucht, hat sich der Engpass nur verschoben.

Zwei Untersuchungen belegen dieses Muster. METR beobachtete 2025 erfahrene Open-Source-Entwickler in ihren eigenen Repositories: Mit KI-Werkzeugen brauchten sie 19 % länger, hielten sich aber für schneller. Der DORA-Report 2024 fand in Organisationen mit höherer KI-Nutzung weniger Lieferstabilität und Durchsatz, bei höherer gefühlter Produktivität. In beiden Fällen nutzten Entwickler die Werkzeuge für sich, ohne gemeinsame Regeln und ohne Messung.

Die Studien sagen also nicht, dass Coding Agents nichts bringen. Sie sagen, dass der Nutzen kein Automatismus ist. Wer ihn haben will, baut den Rahmen und weist ihn nach.

Die fünf Teile des Harness

Der Begriff kommt aus der Testautomatisierung: Ein Harness spannt den Prüfling ein, gibt ihm Eingaben und beobachtet sein Verhalten. Anthropic beschreibt in seinem Leitfaden zum Bau von Agents dieselbe Erfahrung: Die erfolgreichsten Umsetzungen beruhten auf einfachen, nachvollziehbaren Mustern und sorgfältig gestalteten Werkzeugschnittstellen, nicht auf komplexen Frameworks. Der Aufwand steckt im Rahmen, nicht im Modell.

Übertragen auf Coding Agents besteht dieser Rahmen aus fünf Teilen:

• Projektregeln: Instruktionsdateien im Repository beschreiben Architektur, Konventionen, bevorzugte Bibliotheken und unerwünschte Muster. Der Agent liest sie zu Beginn jeder Aufgabe, wie ein neuer Kollege die Entwicklerdokumentation.
• Werkzeugzugriff: Der Agent führt Build, Tests und Linter selbst aus und bekommt die Ausgabe zurück. Ohne diesen Zugriff rät er, ob sein Code funktioniert.
• Leitplanken: Sie legen fest, welche Dateien der Agent ändern und welche Kommandos er ausführen darf. Vor Migrationen oder Änderungen an Schnittstellen gibt ein Mensch frei.
• Rückkopplung: Tests und CI liefern ein Urteil, das nicht von der Selbsteinschätzung des Agenten abhängt. Ein roter Test heißt: noch einmal, bevor ein Mensch die Änderung sieht.
• Messkriterien: Vorab ist vereinbart, woran sich der Erfolg zeigt. So hängt die Bewertung am Ende nicht von Eindrücken ab.

Tests und CI: der stärkste Hebel

Ein Agent, der seine Änderung gegen die Testsuite laufen lässt, behebt einen großen Teil seiner Fehler selbst. Dafür müssen die Tests schnell genug sein, um mehrfach pro Aufgabe zu laufen, und aussagekräftig genug, um echte Fehler zu finden. Eine Codebasis mit wenigen oder langsamen Tests ist deshalb ein schwieriger Startpunkt. Es sei denn, das Schreiben von Tests ist der erste Use-Case.

Die CI ist die zweite Instanz, die der Agent nicht umgehen kann. Was er lokal übersieht, fängt die Pipeline. Erst wenn beide Stufen grün sind, lohnt sich der Blick eines Menschen.

Messen, was zählt

Erzeugte Codezeilen sagen nichts über den Nutzen. Mehr Code heißt mehr Wartung, und ein Agent produziert Code mühelos. Auch die Zufriedenheit der Entwickler ist ein schwacher Indikator, wie beide Studien zeigen.

Brauchbare Kriterien beziehen sich auf den Lieferprozess. Die meisten Teams können sie aus Git und dem Ticketsystem ableiten. Wichtig ist, sie vorab festzulegen: Wer erst am Ende entscheidet, was Erfolg bedeutet, findet immer eine Zahl, die passt.

• Durchlaufzeit: Wie lange dauert eine Aufgabe vom Start bis zum Merge, verglichen mit ähnlichen Aufgaben ohne Agent?
• Review-Dauer: Wie viel Zeit verbringen Reviewer mit agentengenerierten Änderungen, und wie viele Korrekturschleifen sind nötig?
• Fehlerrate: Wie oft führen diese Änderungen zu Nacharbeit, zurückgenommenen Merges oder Fehlern in Produktion?
• Anteil eigenständig erledigter Aufgaben: Welche Aufgaben schließt der Agent ohne manuelle Korrektur in der vereinbarten Qualität ab?

Code-Schutz und Datenschutz

Ein Coding Agent sendet Teile des Quellcodes an ein Modell. Ob und wohin das zulässig ist, klären Verträge und Ihr Datenschutz. Die technische Seite regelt das Harness: Ein Gateway wie LiteLLM bündelt alle Modellaufrufe an einer Stelle und legt fest, welche Modelle erlaubt sind, welcher Anbieter welche Aufgabe bekommt und was protokolliert wird.

Darf der Code das eigene Netz nicht verlassen, sind offene Modelle auf eigener Infrastruktur eine Option, etwa mit Ollama oder vLLM. Sie sind meist weniger leistungsfähig als die großen Cloud-Modelle, für klar umrissene Aufgaben in einem guten Harness aber oft ausreichend.

So fangen Sie an

Lizenzen für das ganze Team sind der falsche erste Schritt. Sie erzeugen Nutzung, aber keinen Rahmen, und am Ende arbeitet jeder anders. Belastbarer ist ein Use-Case in der echten Codebasis: eine Aufgabe mit wiederkehrendem Aufwand, prüfbarem Ergebnis und überschaubarem Risiko.

Für diesen Use-Case bauen Sie das Harness, der Agent arbeitet im Repository, und das Team bewertet die Ergebnisse nach den vereinbarten Kriterien. Danach wissen Sie, ob sich ein Rollout lohnt, mit welchen Leitplanken und welchem Tooling. Falls nicht, ist auch das ein Ergebnis, und ein günstigeres als ein gescheiterter Rollout.