Die Softwareentwicklung mit KI hat sich in den letzten Jahren rasant weiterentwickelt. Lange stand die klassische Entwicklung im Vordergrund: Menschen strukturierten Aufgaben, entschieden über Architektur, schrieben Code und prüften die Ergebnisse mit etablierten Tools und Prozessen. Mit dem Aufkommen von KI-Assistenten kamen neue Hilfsmittel hinzu. Sie unterstützten vor allem dort, wo ein Entwickler ohnehin gerade arbeitete: als Code Completion, beim Ausformulieren einzelner Funktionen, beim Erzeugen kleiner Tests oder als Hilfe innerhalb einer Datei.
Der grundlegende Ablauf der Entwicklung änderte sich dadurch jedoch kaum. Entwickler integrieren die Tools in ihren Ablauf und nicht umgekehrt. Mit Coding Agenten könnte sich dies verschieben. Sie liefern nicht nur Vorschläge im Editor, sondern können eine Aufgabe über mehrere Schritte verfolgen: Codebasen analysieren, Dateien ändern, Tests starten, Terminal-Kommandos ausführen, Browser- oder UI-Checks nutzen und auf Fehlermeldungen reagieren. Anders gesagt: Früher schrieb der Mensch den Code und nutzte Tools selbst. Mit KI-Assistenz bekam er währenddessen Vorschläge. Mit Agent Support kann ein Teil des Arbeitsablaufs selbst an den Agenten übergeben werden.
Damit stellt sich eine neue Frage: Welche Umgebung brauchen Coding Agenten, damit ihre Ergebnisse schnell, überprüfbar und zuverlässig entstehen? Genau hier wird Harness Engineering wichtig: Es hilft, typische Schwächen Large Language Model (LLM) basierter Systeme wie Halluzinationen oder nicht-deterministisches Verhalten abzufedern.
Abbildung 1: Die Entwicklung bewegt sich von klassischer Softwareentwicklung über KI-Assistenz hin zu agentischen Entwicklungsworkflows.
Abbildung 1 macht diesen Wandel sichtbar: KI-Assistenz ergänzt vor allem bestehende Workflows. Agentische Entwicklung geht einen Schritt weiter und verändert diese Workflows stärker, weil der Agent Aufgaben nicht nur kommentiert oder ergänzt, sondern aktiv ausführt. Dadurch entstehen neue Rollen, neue Kontrollpunkte und neue Anforderungen an Architektur, Qualitätssicherung und Governance. Kontrollpunkte sind dabei bewusst gesetzte Stellen im Ablauf: Welche Tests müssen laufen, wann braucht es ein Review, welche Änderungen dürfen automatisch vorbereitet werden und wo ist eine menschliche Freigabe nötig? Der Agent bleibt ein Tool, aber eines, das deutlich näher am eigentlichen Entwicklungsprozess arbeitet als klassische Assistenzfunktionen in der IDE. Hier setzt Harness Engineering an. Wenn ein Agent in einer Codebasis arbeiten soll, braucht er klare Leitplanken:
Der Begriff Harness lässt sich im Software-Engineering (aber auch allgemeingültiger für beliebige agentische Systeme) am besten als Arbeits- und Ausführungsumgebung rund um ein Large Language Model verstehen. Ein LLM kann Sprache und Code analysieren, Muster erkennen und neue Inhalte erzeugen. Zu einem Agenten wird es, wenn es mit Kontext, Tools, Zustand, Regeln und Feedback-Schleifen verbunden wird. Eine einfache Formel bringt diese Idee auf den Punkt:
Agent = LLM + Harness
LangChain, ein Framework für LLM-Anwendungen und Agenten, beschreibt einen Agent Harness als den Teil außerhalb des Modells, der Zustand verwaltet, Tools ausführt, Feedback-Schleifen ermöglicht und Grenzen vorgibt.1 Ganz konkret werden System Prompt, Tools, Skills, MCP Server, Zugriff auf Infrastrukturkomponenten wie das Filesystem, die Orchestrationslogik, sowie Hooks für deterministische Ausführung, als Komponenten eines Harness genannt. Wichtig ist dabei die Unterscheidung zwischen Harness und Harness Engineering. Das Harness ist die konkrete Umgebung, in der ein Agent arbeitet. Harness Engineering beschreibt die Arbeit an dieser Umgebung: Sie wird entworfen, an ein Projekt angepasst, mit Tools und Tests verbunden, durch klare Grenzen abgesichert und im laufenden Einsatz weiter verbessert. ³
Aus Sicht von Softwareentwicklern ist dieses Prinzip nicht neu. Gute Softwareentwicklung bestand nie nur aus dem Schreiben von Code. Sie umfasste schon immer Build-Systeme, Tests, CI/CD, Architekturregeln, Monitoring und Reviews. Harness Engineering überträgt genau diese Engineering-Disziplin auf die Arbeit mit KI-Coding-Agenten.
Abbildung 2: Ein Coding Agent Harness verbindet Guidance, Validation und eine Self-Correction-Schleife um das Modell herum.
Abbildung 2 zeigt, wie eine Harness um ein Coding Model herum aufgebaut sein kann. Im Zentrum steht das Coding Model, also das LLM. Entscheidend ist jedoch, was um dieses Modell herum aufgebaut wird: der Harness. Auf der linken Seite der Abbildung steht die Guidance. Sie gibt dem Agenten vor oder während seiner Arbeit Orientierung. Dazu gehören Instructions & Rules, Docs & Context sowie Tools & Scripts. Sie klärt Fragen wie: Was soll erledigt werden? Welche Projektregeln gelten? Welche Architekturentscheidungen spielen eine Rolle? Und welche Tools darf der Agent nutzen, etwa Testkommandos, Suchskripte, Browser-Prüfungen oder projektspezifische CLI-Befehle? Auf der rechten Seite steht die Validation. Sie liefert Rückmeldung zur Qualität der erzeugten Artefakte. Dazu zählen Tests & Linters, Review Agents, Logs & Metrics sowie Browser- oder UI-Checks. Validation liefert somit dem Agenten verwertbares Feedback. Sie schafft die Grundlage dafür, dass ein Agent Fehler selbstständig erkennen und seine Lösung verbessern kann. Birgitta Böckeler nutzt in ihrem Blogbeitrag die Begriffe “Guides” und “Sensors” als grundlegende Abstraktionen eines Harness. Guides sollen das Verhalten des Agenten steuern, während Sensors dazu dienen, ihm Feedback zu seinem Verhalten und damit eine Möglichkeit zur Selbstverbesserung geben.²
Der untere Teil der Abbildung zeigt die Self-Correction Loop. Dort entsteht ein großer Teil des eigentlichen Mehrwerts: Der Agent führt eine Aktion aus, erhält Feedback, bewertet dieses Feedback und passt sein Ergebnis an. Harness Engineering bedeutet daher nicht, dem Agenten jeden einzelnen Schritt fest vorzuschreiben. Im Kern geht es darum, die Umgebung so aufzubauen, dass genau diese Feedback-Schleife zuverlässig unterstützt wird. Die Abbildung zeigt außerdem die praktische Umsetzungsebene. Unternehmen starten selten bei Null. Oft gibt es bereits einen generischen Harness, etwa durch GitHub Copilot, Claude Code oder eine agentische Entwicklungsumgebung.
Harness Engineering beginnt dort, wo dieser allgemeine Harness auf das konkrete Projekt zugeschnitten wird: durch projektspezifische Regeln, passende Tools, aussagekräftige Tests, klare Berechtigungen und funktionierende Feedbackmechanismen. Danach wird der Harness im Alltag weiter geschärft und verbessert.
1 https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
2 https://martinfowler.com/articles/sensors-for-coding-agents.html
3 https://martinfowler.com/articles/harness-engineering.html
Mit „Harness“ ist nicht immer dieselbe Ebene gemeint. Je nach Kontext kann der Begriff ein SDK oder Toolkit beschreiben, die konkrete Einrichtung in einem Projekt, einen domänenspezifischen Rahmen oder sogar das gesamte agentische Entwicklungssystem. Hilfreich ist deshalb, den Begriff auf mehreren Ebenen zu betrachten: Tabelle 1: Ebenen eines Harness
| Ebene | Bedeutung |
|---|---|
| Generic Harness | Die technische Grundlage, die ein Agent benötigt, um überhaupt arbeiten zu können. Dazu gehören Tool-Calling-Schnittstellen, konkrete Werkzeuge (z. B. Dateizugriff, Terminal oder Browser), eine Sandbox, der Ausführungsloop, Berechtigungen sowie die Interaktionsoberfläche. Agentische Coding-Tools bauen darauf auf und bündeln Modell, Benutzeroberfläche, Toolzugriff und Arbeitsloop für Codeänderungen. |
| Project Harness | Die Anpassung des Agenten an eine konkrete Codebasis. Dazu zählen Projektregeln, Architekturkontext, Build- und Testskripte, lokale Dokumentation, CI-Signale, Review-Richtlinien sowie projektspezifische Einschränkungen. |
| Domain Harness | Wiederverwendbares Wissen für eine fachliche Domäne. Dazu gehören Standards, Fachbegriffe, regulatorische Anforderungen, typische Datenmodelle, Qualitätsrichtlinien und branchenspezifische Best Practices. |
| Delivery Harness | Der organisatorische und technische Rahmen für die Softwarebereitstellung. Er umfasst das Zusammenspiel von Menschen, Agenten, Workflows, CI/CD-Pipelines, Qualitätstoren, Governance, Observability und Freigabeprozessen. Ein Agent kann dabei nicht nur Code ändern, sondern beispielsweise auch Reviews vorbereiten, Testergebnisse auswerten und Deployment-Prozesse anstoßen. |
Dieser Beitrag verortet sich vor allem auf der Ebene des Project Harness. Es geht um die praktische Frage: Wie machen wir einen Agenten in einer konkreten Codebasis steuerbar, nützlich und überprüfbar? Die anderen Ebenen bleiben wichtig, aber der direkteste Einstieg für Softwareentwickler liegt meistens im Projekt selbst.
Um das Modell aus Abbildung 2 greifbarer zu machen, betrachten wir einen typischen Fall aus einer bestehenden Codebasis. Ein Team betreibt eine Anwendung, die fachliche Daten importiert und validiert. Ein Ticket beschreibt einen Fehler: Bestimmte ungültige Datumswerte werden beim Import nicht zuverlässig abgelehnt. Gleichzeitig gibt es eine fachliche Sonderregel. Einige historische Daten aus einem Altsystem dürfen weiterhin importiert werden, obwohl sie nach den heutigen Regeln eigentlich ungültig wären. Diese Ausnahme ist an der betreffenden Validierungsstelle nicht direkt erkennbar. Hinweise darauf finden sich verteilt in der Projektdokumentation, in Testdaten, alten Migrationen und einer fachlichen Konstante. Gemeint ist ein benannter Wert im Code, etwa ALTDATEN_STICHTAG, der die Ausnahme zentral beschreibt, statt dasselbe Datum an mehreren Stellen zu wiederholen.
Ein Entwickler möchte einen Coding Agenten einsetzen, um den Fehler zu untersuchen und einen Fix vorzubereiten. Auch ohne projektspezifischen Harness wird ein moderner Coding Agent in diesem Fall wahrscheinlich vieles richtig machen. Er kann relevante Dateien finden, bestehende Tests ausführen, die Validierungslogik nachvollziehen und einen plausiblen Änderungsvorschlag erstellen. Genau deshalb eignet sich das Beispiel:
Es geht nicht darum, ob der Agent grundsätzlich Code ändern kann. Entscheidend ist, ob seine Änderung den fachlichen und technischen Maßstäben des Projekts entspricht. Ohne projektspezifischen Harness fehlen ihm vor allem explizite Projektregeln, ein fokussierter Review und klare Hinweise darauf, welche Grenzfälle für das Team tatsächlich wichtig sind.
Mit Harness läuft derselbe Fall anders ab. Die Guidance gibt dem Implementierungs-Agenten zunächst Orientierung. In den Projektregeln steht beispielsweise, dass Validierungen nicht direkt im Importprozess umgesetzt werden, sondern in einer zentralen Validierungsschicht. In der Dokumentation findet der Agent die fachliche Regel zu erlaubten Datumsformaten und zu den bewusst tolerierten Altdaten. Ein verlinktes Suchskript führt ihn zu den relevanten Validierungsklassen und Testdaten.
Ein weiteres Projektkommando startet gezielt die Import-Regressionstests, die für diesen Bereich aussagekräftig sind. So kann der Agent seine Codeanalyse mit dem Projektwissen verbinden, das für diesen Fix relevant ist. Er arbeitet innerhalb der vorgesehenen Architektur, berücksichtigt die fachliche Ausnahme für Altdaten und ergänzt den Test dort, wo das Team solche Regeln üblicherweise absichert. Anschließend kommt die Validierung ins Spiel. Die Import-Regressionstests zeigen, welche Kombination aus ungültigem Datum und historischer Datenquelle relevant ist. Die Logs des lokalen Testlaufs geben Auskunft, welcher Datensatz den Grenzfall auslöst. Zusätzlich prüft ein Review-Sub-Agent die Änderung unabhängig anhand der Projektregeln und Architekturvorgaben:
Damit ergänzt der Review-Sub-Agent eine zweite Perspektive. Er prüft nicht nur, ob der Code läuft, sondern auch, ob die Änderung fachlich und architektonisch zum Projekt passt. Die Self-Correction Loop schließt den Kreis. Der Implementierungs-Agent überarbeitet seine Änderung auf Basis des Reviews. Er verwendet die vorhandene Konstante für den Altdaten-Stichtag, ergänzt den fehlenden Testfall und führt die relevanten Checks erneut aus. Erst wenn Regressionstests und Review-Ergebnisse passen, stellt er die Änderung als Vorschlag oder Pull Request bereit. Abbildung 2 enthält außerdem eine Optimizing Loop. Sie beschreibt einen übergeordneten Schritt: Erkenntnisse aus Reviews, Testläufen oder menschlichen Freigaben können zurück in den Harness fließen. Aus dem konkreten Fall entsteht beispielsweise eine klarere Projektregel, ein zusätzlicher Regressionstest oder eine präzisere Toolbeschreibung. Auf diese Weise verbessert ein einzelner Fall den Harness für ähnliche Aufgaben in der Zukunft. Der Unterschied besteht also nicht darin, dass der Agent mit Harness plötzlich intelligenter wird. Er wird gezielter geführt und systematischer überprüft.
Die Guidance verringert die Gefahr, dass er in die falsche Richtung arbeitet. Die Validierung macht Fehler und relevante Grenzfälle sichtbar. Die Feedback-Schleife sorgt dafür, dass der Agent erkannte Probleme selbst korrigieren kann. Ein Harness verhindert nicht jede falsche Entscheidung. Er macht den Entwicklungsprozess mit Coding Agents aber zuverlässiger und verringert das Risiko, dass Änderungen zwar technisch funktionieren, aber fachliche Regeln oder Architekturvorgaben verletzen. Der Mensch bleibt eingebunden, wo Verantwortung, Architekturentscheidungen oder fachliche Bewertungen erforderlich sind.
Für Entwickler verschiebt sich damit ein Teil der Arbeit. Softwareentwicklung bestand schon immer aus mehr als dem Schreiben von Code: Architektur, Tests, Build-Systeme, Reviews und Betrieb gehörten dazu. Mit Coding Agenten wird es zusätzlich wichtig, die Umgebung zu gestalten, in der ein Agent sinnvoll arbeiten kann. Dazu gehört, implizites Projektwissen sichtbar zu machen. Viele Regeln leben in Teams nur in den Köpfen einzelner Personen, in alten Pull Requests oder in mündlichen Absprachen. Für Menschen kann das ausreichen. Für Agentens ist es schwierig. Ein wichtiger Teil von Harness Engineering besteht deshalb darin, Architekturprinzipien, Qualitätsziele und typische Arbeitsweisen so festzuhalten, dass sie als Guidance nutzbar werden. Dieser Schritt hilft nicht nur Agenten. Wenn Projektwissen klarer dokumentiert und an einer Stelle auffindbar ist, profitieren auch neue Teammitglieder, Reviews und spätere Wartung davon. Harness Engineering macht damit sichtbar, was im Projekt ohnehin wichtig ist, aber bisher oft nur informell weitergegeben wurde.
Gleichzeitig müssen Entwickler dafür sorgen, dass der Agent verlässliches Feedback bekommt. Gute Tests, klare Build-Skripte, verständliche Fehlermeldungen, Logs, Metriken und automatisierte Reviews sind dabei keine Randthemen. Sie entscheiden maßgeblich darüber, ob ein Agent seine Arbeit prüfen und verbessern kann. Ebenso wichtig ist die Kontrolle seiner Handlungsspielräume. Nicht jeder Agent sollte jede Datei ändern, jedes Tool ausführen oder jede Pipeline starten dürfen. Harness Engineering bedeutet daher auch, Rechte, Sandboxes, Freigaben und Eskalationspunkte sauber zu definieren. Der Agent soll produktiv arbeiten können, aber nicht unkontrolliert. Es wird deutlich: Harness Engineering ersetzt Softwaree Entwicklung nicht.
Viele Praktiken gibt es längst. Im agentischen Kontext werden sie allerdings wichtiger und sichtbarer. Teams mit Architekturgrenzen, guten Tests, verständlicher Dokumentation und funktionierenden Toolchains können Agenten deutlich besser einsetzen als Teams, bei denen wichtiges Projektwissen vor allem informell verteilt ist.
Harness Engineering ist nicht nur eine Frage der Produktivität. Es geht genauso um Qualität, Sicherheit und Governance.
Sobald ein Agent Code ändern, Tools ausführen oder externe Systeme ansprechen kann, entstehen neue Risiken. Auch ein sehr leistungsfähiger Coding Agent kann eine Änderung vorschlagen, die lokal sinnvoll wirkt, aber nicht sauber zu Architektur, Domänenmodell oder Freigabeprozess passt. Er kann zum Beispiel eine Validierungsregel technisch korrekt erweitern, dabei aber eine fachliche Ausnahme an der falschen Stelle modellieren oder bestehende Review-Konventionen umgehen. Er kann zu viele Dateien verändern oder versehentlich Informationen in einen Kontext bringen, in den sie nicht gehören. Solche Risiken lassen sich nicht allein mit besseren Prompts kontrollieren.
Wo immer möglich, sollten deterministische Checks Vorrang haben. Tests, Linters, Typechecker, Architekturprüfungen und Security-Scanner liefern oft verlässlichere Ergebnisse als eine rein sprachliche Bewertung. LLM-basierte Reviews können sinnvoll ergänzen, sollten aber nicht die einzige Qualitätsinstanz sein.
OpenAI beschreibt im Codex-Kontext, dass Coding Agenten durch Zugriff auf Logs, Metriken und Traces besser prüfen können, ob Änderungen tatsächlich funktionieren.⁴ Anthropic beschreibt für langlaufende Entwicklungsaufgaben unter anderem Harness-Designs mit Planner-, Generator- und Evaluator-Rollen.⁵ Beide Beispiele zeigen denselben Grundgedanken: Je autonomer ein Agent arbeitet, desto wichtiger wird die technische Umgebung, die ihn führt, prüft und begrenzt.
Ein Harness ist kein Setup, das man einmal einrichtet und dann vergisst. Es wächst mit dem Projekt, dem Team und den eingesetzten Agenten weiter. In der Praxis beginnt Harness Engineering oft mit konkreten Fehlern.
Ein Agent ignoriert eine Architekturregel? Dann fehlt diese Regel vielleicht oder sie ist zu ungenau formuliert. Ein Agent baut einen Fix, der bestehende Grenzfälle verletzt? Dann fehlt möglicherweise ein passender Test als Rückkopplung.
Ein Agent nutzt ein Tool falsch? Dann ist die Toolbeschreibung vielleicht unklar oder die Berechtigung zu weit gefasst. Das Ziel ist nicht, jeden Fehler einzeln von Hand zu korrigieren.
Wichtiger ist, wiederkehrende Fehler in den Harness zurückzuführen. Aus einer manuellen Korrektur wird dann zum Beispiel eine klarere Regel, ein neuer Test, ein Skript, ein besserer Logs, eine verständlichere Toolbeschreibung oder ein zusätzlicher Freigabepunkt. Mit der Zeit wird der Harness dadurch konkreter. Wiederkehrende Fehler werden nicht nur einzeln korrigiert, sondern in Regeln, Tests, Toolbeschreibungen oder Freigabepunkte übersetzt. Ein guter Harness besteht deshalb nicht aus möglichst viel Text. Entscheidend ist, ob Kontext, Tools, Validation und Grenzen so zusammenspielen, dass der Agent verlässlich arbeiten kann.
4 https://openai.com/index/harness-engineering/
5 https://www.anthropic.com/engineering/harness-design-long-running-apps
KI-Coding-Agenten eröffnen neue Möglichkeiten in der Softwareentwicklung. Sie können Aufgaben vorbereiten, Code ändern, Tests ergänzen, Dokumentation aktualisieren und auf Feedback reagieren. Wie gut das funktioniert, hängt aber nicht allein vom zugrunde liegenden Modell ab. Harness Engineering wird für Entwickler und Teams relevant, sobald Agenten nachvollziehbar und verlässlich im Kontext eines konkreten Projekts arbeiten sollen. Geschwindigkeit allein reicht dafür nicht aus. Teams müssen festlegen, welchen Kontext ein Agent erhält, welche Tools er verwenden darf, wie seine Ergebnisse geprüft werden und an welchen Stellen ein Mensch entscheiden muss. Ein Harness verbindet die Arbeit des Agenten mit Projektwissen, technischen Prüfungen und Verantwortlichkeiten. Dadurch wird kontrollierbarer, auf welcher Grundlage der Agent arbeitet, welche Regeln er berücksichtigt und wie Fehler erkannt und korrigiert werden. Für Unternehmen ist deshalb nicht nur entscheidend, welches Modell oder Tool sie einsetzen. Genauso wichtig ist die Arbeitsumgebung, in der dieses Modell eingesetzt wird. Erst sie entscheidet darüber, ob ein Agent lediglich schnell Code erzeugt oder Änderungen liefert, die fachlich und technisch sauber umgesetzt sind und sich in bestehende Entwicklungsprozesse einfügen.
Aus HMS-Sicht liegt darin der praktische Kern von Harness Engineering. KI wird in der Softwareentwicklung wertvoll, wenn Geschwindigkeit, Qualität, Nachvollziehbarkeit und Kontrolle gemeinsam betrachtet werden.