> Harness Engineering für Coding-Agenten: Guides und Sensors, wo jede Prüfung laufen soll, Rot/Grün-TDD und Mutationstests für die Tests des Agenten. > > Web page: https://balazscsorba.com/de/blog/harness-engineering-coding-agents · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/harness-engineering-coding-agents.md) · [Magyar](https://balazscsorba.com/hu/blog/harness-engineering-coding-agents.md) > Author: Balázs Csorba · Published: 2026-09-04 · Keywords: harness engineering erklärt, harness engineering coding-agenten, ki-codequalität, coding-agent leitplanken, mutation testing ki-generierte tests, red/green tdd mit ki-agenten, guides und sensors coding-agenten, ki-agent pull requests mergebar machen, kann man tests von ki vertrauen [Blog](https://balazscsorba.com/de/blog)/[KI-Agenten](https://balazscsorba.com/de/blog/category/agents) # Harness Engineering: Guides und Sensors, die Agent-PRs mergebar machen Harness Engineering für Coding-Agenten: Guides und Sensors, wo jede Prüfung laufen soll, Rot/Grün-TDD und Mutationstests für die Tests des Agenten. [Balázs Csorba](https://balazscsorba.com/de/about)·4\. September 2026·8 Min. Lesezeit - Harness engineering - [Coding agents](https://balazscsorba.com/de/blog/tag/coding-agents) - Code quality - Mutation testing - TDD ![Harness Engineering: Ein Roboter geht einen schmalen Weg mit Führungsschienen und Sensorpfosten zu einem offenen Tor.](https://balazscsorba.com/images/blog/harness-engineering-coding-agents/cover.webp?v=68ad6d9481) ## Das Wichtigste in Kürze - Harness Engineering baut alles rund um das Modell eines Coding-Agenten so, dass dessen Ausgabe geprüft und korrigiert wird, bevor ein Mensch sie reviewt. - Guides lenken den Agenten vor dem Handeln, Sensors prüfen das Ergebnis danach; beide können computational oder inferential sein. - Regeln in Markdown-Dateien sind Anleitung, keine Durchsetzung: Gates, die immer laufen müssen, gehören in Hooks oder CI. - Rot/Grün-TDD beweist, dass ein Test die Änderung wirklich ausübt; bei Bugfixes muss der Regressionstest scheitern, wenn nur der Fix zurückgenommen wird. - Mutationstests auf dem Diff zeigen, ob agentengeschriebene Tests einen Bug wirklich fangen würden – über ihre Coverage-Zahl hinaus. Auf dieser Seite 1. [Was ist Harness Engineering?](https://balazscsorba.com/#what-is-harness-engineering) 2. [Guides und Sensors: Feedforward und Feedback](https://balazscsorba.com/#guides-and-sensors) 3. [Wo sollten Sensors laufen?](https://balazscsorba.com/#where-sensors-run) 4. [Rot/Grün-TDD mit Coding-Agenten](https://balazscsorba.com/#red-green-tdd) 5. [Mutationstests: die Tests des Agenten prüfen](https://balazscsorba.com/#mutation-testing) 6. [Der Schwachpunkt: Verhaltens-Harnesses und wann man nicht überbaut](https://balazscsorba.com/#behaviour-harness) 7. [Checkliste für Harness Engineering](https://balazscsorba.com/#checklist) 8. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:00 **Harness Engineering** ist die Arbeit, alles rund um das Modell eines Coding-Agenten zu bauen (Anweisungen, Tools, Tests, Linter, Reviews), damit das, was der Agent produziert, korrekt und wartbar ist, bevor ein Mensch es ansieht. Das Modell schreibt den Code. Der Harness entscheidet, ob dieser Code etwas taugt, und sagt dem Agenten, wenn nicht. Dieser Artikel verwendet Birgitta Böckelers Rahmen aus **Guides** und **Sensors**, wird dann aber praktisch: welche Prüfungen wo laufen, wie Rot/Grün-TDD mit einem Agenten funktioniert, wie Mutationstests die vom Agenten geschriebenen Tests prüfen und warum Verhalten weiterhin der Schwachpunkt ist. Am Ende steht eine Checkliste dafür, wie agentische Pull Requests mergebar werden. ## Was ist Harness Engineering? Harness Engineering behandelt die Umgebung rund um das Modell als das, was man entwirft. Böckelers Artikel [„Harness engineering for coding agent users“](https://martinfowler.com/articles/harness-engineering.html) (April 2026) fasst es so zusammen: „Agent = Model + Harness“. Sie unterscheidet zwei Harnesses. Der eine wird mit dem Agenten ausgeliefert – in Claude Code, Codex oder opencode: System-Prompt, Tool-Schleife, Sandbox. Der andere entsteht bei dir rund um deine Codebasis: Regeln-Dateien, Skills, Testbefehle, Linter, Review-Schritte. Am ersten änderst du wenig. Der zweite gehört dir, und aus ihm kommt der größte Qualitätsunterschied zwischen Teams. Manche Codebasen nehmen einen Harness besser auf als andere. Böckeler nennt das **Harnessability**: Eine „stark typisierte Sprache hat von Natur aus das Type Checking als Sensor“, und klare Modulgrenzen machen Architekturregeln überhaupt erst möglich. Eine Codebasis ohne Tests und ohne Typen gibt einem Agenten nichts, wogegen er sich prüfen könnte – er muss raten. ## Guides und Sensors: Feedforward und Feedback Guides lenken den Agenten, bevor er handelt; Sensors prüfen das Ergebnis, nachdem er gehandelt hat, damit er sich selbst korrigieren kann. Beide gibt es in zwei Ausprägungen: computational (von der CPU ausgeführt, deterministisch) und inferential (von einem Modell ausgeführt, semantisch, aber probabilistisch). In Böckelers Worten „antizipieren die Guides das Verhalten des Agenten und zielen darauf ab, ihn _bevor_ sein Handeln zu lenken“, während Sensors „_nachdem_ der Agent gehandelt hat, beobachten und ihm helfen, sich selbst zu korrigieren“. Computational Controls sind „deterministisch und schnell, von der CPU ausgeführt“: Tests, Linter, Type Checker. Inferential Controls sind semantische Analyse und KI-Code-Review: langsamer, teurer und nicht deterministisch, aber sie können Dinge beurteilen, die ein Linter nicht kann. ![Vierfeldraster der Guides und Sensors, computational oder inferential, für den Harness eines Coding-Agenten.](https://balazscsorba.com/images/blog/harness-engineering-coding-agents/diagram-9.webp?v=1eacb14e54) Der Harness als 2x2-Raster: Guides lenken, bevor der Agent handelt, Sensors prüfen danach, und beides kann computational (deterministisch) oder inferential (modellbasiert) sein. Merkmal Computational Control Inferential Control Beispiele Tests, Type Checker, Linter, Abhängigkeitsregeln, Mutationstests KI-Code-Review, Review-Sub-Agent, Regeln in AGENTS.md oder Skills Ergebnis Gleiche Eingabe, gleiche Antwort Kann zwischen Läufen schwanken Geschwindigkeit und Kosten Schnell, günstig zu wiederholen Langsamer, kostet pro Lauf Tokens Fängt ab Strukturelle Probleme: Typen, Stil, Testabdeckung, verbotene Importe Semantische Probleme: Benennung, Design, fehlende Randfälle Kann einen Merge allein blockieren? Ja Besser als Rat an den Agenten oder einen Menschen Böckeler gruppiert Harnesses danach, was sie beschützen. **Wartbarkeit** ist am weitesten entwickelt: Computational Sensors fangen zuverlässig „doppelten Code, zyklomatische Komplexität, fehlende Testabdeckung, architektonisches Abdriften“. **Architekturtauglichkeit** umfasst Performance-Anforderungen und Konventionen, geprüft mit Fitness Functions. **Verhalten**, also ob die Software tut, was sie soll, ist die Lücke – es bekommt unten einen eigenen Abschnitt. ## Wo sollten Sensors laufen? Die schnellen Sensors laufen in der Schleife des Agenten nach jeder Änderung, das vollständige Gate vor jedem Commit, die langsamen in der CI. Je früher ein Sensor auslöst, desto billiger ist die Korrektur: Der Agent behebt sie in derselben Session, bevor ein Reviewer sie überhaupt sieht. Böckeler nennt das, Qualität links zu halten: schnelle Linter vor dem Commit, breiteres Review danach, teure Analysen wie Mutationstests nach der Integration. In ihrem Folgeartikel [„Maintainability sensors for coding agents“](https://martinfowler.com/articles/sensors-for-coding-agents.html) (Mai 2026) probierte sie ESLint, dependency-cruiser, Semgrep, Coverage, Stryker und GitLeaks als Sensors aus und fand, dass computistische Werkzeuge auf Dateiebene am besten funktionieren, ein modellbasiertes Review dagegen bei Fragen über Modulgrenzen hinweg. Sie schildert auch das praktische Problem: „Ich musste die Agenten viele, viele Male fragen, warum sie die Sensorenprüfung nicht ausgeführt haben.“ Genau dieser Satz ist das Argument für Durchsetzung. Eine Regel in einer Markdown-Datei ist ein Guide; der Agent hält sich womöglich daran, vielleicht auch nicht. Die [Memory-Dokumentation](https://code.claude.com/docs/en/memory) von Claude Code sagt dasselbe über die eigenen Regeln-Dateien: Claude behandelt sie „als Kontext, nicht als durchgesetzte Konfiguration“, und um eine Aktion unabhängig von der Modellentscheidung zu blockieren, brauchst du einen Hook. Mein eigenes Gate ist absichtlich langweilig: die komplette PHPUnit-Suite und PHPStan laufen vor jedem Commit, und ein übersprungener oder partieller Lauf wird genau so gemeldet, niemals als grün. ![Ablauf des Harness: Guides speisen den Agenten, Sensors prüfen, der Mensch gibt Absicht und Design frei.](https://balazscsorba.com/images/blog/harness-engineering-coding-agents/diagram-16.webp?v=25724e14fd) Sensors schließen den inneren Feedback-Kreis, damit der Agent strukturelle Probleme selbst behebt; der menschliche Review-Kreis bleibt für Absicht und Design. ## Rot/Grün-TDD mit Coding-Agenten Rot/Grün-TDD heißt: Der Agent schreibt einen Test, führt ihn aus und schaut, wie er scheitert, dann schreibt er den Code und schaut, wie der Test besteht. Der fehlschlagende Lauf ist der Punkt: Er beweist, dass der Test das neue Verhalten überhaupt ausübt. Simon Willison führt das in seinem Leitfaden [„Agentic Engineering Patterns“](https://simonwillison.net/guides/agentic-engineering-patterns/) als kurzen Prompt auf – „Use red/green TDD“ – und nennt den Grund: „Wenn du diesen Schritt überspringst, baust du möglicherweise einen Test, der schon besteht und deshalb deine neue Implementierung weder ausübt noch bestätigt.“ Das Gegenstück, [„First run the tests“](https://simonwillison.net/guides/agentic-engineering-patterns/first-run-the-tests/), lässt den Agenten zu Beginn einer Session herausfinden, wie die Suite läuft – das macht ihn deutlich eher geneigt, sie später noch einmal zu starten. Für Bugfixes benutze ich eine strengere Variante. Der Regressionstest muss mit dem Fix bestehen, scheitern, wenn _nur_ der Fix zurückgenommen wird, und wieder bestehen, wenn er zurückkommt. Den Revert macht der Agent selbst und berichtet beide Läufe. Das fängt Tests ab, die das Falsche prüfen, und ist billig: zwei zusätzliche Testläufe. Der Ablauf drumherum steht in [meinem Beitrag darüber, wie ich Skills für Bugfixes einsetze](https://balazscsorba.com/de/blog/coding-agent-skills-workflow). Anthropics [„Effective harnesses for long-running agents“](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) überträgt dieselbe Idee auf ganze Projekte: eine Feature-Liste, in der jedes Feature mit `"passes": false` startet, ein Feature pro Session und die Regel, es sei „inakzeptabel, Tests zu entfernen oder zu ändern“. Der rote Zustand steht fest, bevor es irgendeinen Code gibt. ## Mutationstests: die Tests des Agenten prüfen Mutationstests nehmen kleine Änderungen am Produktionscode vor und lassen die Tests erneut laufen. Bestehen die Tests weiterhin, haben sie die Änderung nicht bemerkt, und sie sind schwächer, als ihre Coverage-Zahl nahelegt. [Stryker](https://stryker-mutator.io/docs/) beschreibt es so: Mutanten werden „automatisch in deinen Produktionscode eingefügt. Für jeden Mutanten werden deine Tests ausgeführt. Wenn deine Tests scheitern, ist der Mutant getötet. Wenn deine Tests bestehen, hat der Mutant überlebt.“ Stryker deckt JavaScript und TypeScript, C# und Scala ab. Für PHP meldet [Infection](https://infection.github.io/guide/command-line-options.html) einen Mutation Score Indicator (MSI) und kann einen CI-Job unterhalb eines Schwellenwerts fehlschlagen lassen. Das wird wichtiger, sobald Agenten die meisten Tests schreiben. Ein Agent, der „Tests ergänzen“ soll, erreicht mühelos hohe Zeilenabdeckung; ob die Assertions einen echten Bug fangen würden, ist eine andere Frage. Böckeler kommt zur selben Beobachtung: Abdeckung allein kaschiert schwache Tests, also werden Mutationstests wichtiger, wenn KI sie schreibt. Mutantenläufe dauern in einer ganzen Codebasis lange, also grenzt man sie auf die Änderung ein: Shell ``` # CI step: mutate only the lines this PR touched (PHP, Infection) git fetch --depth=1 origin $GITHUB_BASE_REF infection --git-diff-lines --git-diff-base=origin/$GITHUB_BASE_REF --min-covered-msi=80 # 80 is an example threshold; start from your current score and raise it ``` Überlebende Mutanten sind zugleich gute Eingabe für den Agenten. Gib die Liste zurück mit „die folgenden haben überlebt; ergänze oder verschärfe die Assertions, damit sie getötet werden, ohne den Produktionscode zu ändern“, und der Sensor wird zu einer Rückkopplung, die der Agent selbst schließen kann. ## Der Schwachpunkt: Verhaltens-Harnesses und wann man nicht überbaut Verhalten ist der Bereich, in dem Harnesses am schwächsten sind, denn die übliche Verhaltensprüfung ist eine Testsuite, die der Agent aus einer Spezifikation geschrieben hat, die der Agent gelesen hat. Böckelers Urteil dazu: Das setzt „riesiges Vertrauen in KI-generierte Tests, und das reicht noch nicht“. Drei Dinge helfen, keines davon umsonst: - **Akzeptanztests unter menschlicher Verantwortung.** Ein kleiner Satz End-to-End-Tests, den ein Mensch geschrieben oder freigegeben hat; der Agent darf sie ausführen, aber nicht bearbeiten. - **Tests über die echte Schnittstelle.** Anthropics Harness für lange Läufe hielt Browser-Automatisierung für entscheidend, damit der Agent Features „wie ein menschlicher Benutzer“ verifiziert. Bei mir übernimmt das Playwright. - **Getrenntes Review des Test-Diffs.** Wenn Code und Tests zusammen geändert werden, liest ein Reviewer zuerst die Tests. Der Preis ist Zeit und Rauschen. Jeder Sensor verlängert die Schleife, und inferential Sensors kosten Tokens und erzeugen Fehlalarme. Ein Review-Sub-Agent, der pro PR zehn Stil-Nits meldet, trainiert alle – Mensch und Agent –, ihn zu übergehen. Baue keinen Harness für ein Wegwerf-Skript. Baue einen für Code, der gepflegt wird, und lass ihn an echten Fehlschlägen wachsen: Muss ein Agent-PR jedes Mal von einem Menschen korrigiert werden, frage, welcher Guide oder Sensor das gefangen hätte. Böckelers Vorbehalt gilt auch: Menschen bringen Urteilsvermögen und Verantwortung als „impliziten Harness“ mit, und ein dokumentierter Harness „kommt nur so weit“. Wie das menschliche Review nicht zum Engpass wird, steht in [meinem Beitrag über das Review KI-generierter Pull Requests](https://balazscsorba.com/de/blog/ai-generated-pr-review-bottleneck). **Tests sind die Abbruchbedingung der Schleife** In einer [Agentenschleife](https://balazscsorba.com/de/blog/agent-loop-explained) ist „Tests sind grün“ oft die Bedingung, die den Lauf beendet. Ein schwacher Test macht den Ausgang zu leicht erreichbar – deshalb ist Testqualität ein Harness-Problem und nicht nur ein QA-Problem. ## Checkliste für Harness Engineering 1. **Schreibe die Guides:** Build- und Testbefehle, Konventionen und verbotene Muster in AGENTS.md oder Skills. 2. **Lass die schnellen Sensors in der Schleife laufen:** Type Checker, Linter und die betroffenen Tests nach jeder Änderung. 3. **Erzwinge das Gate** mit Hooks oder CI, nicht mit einem Satz in einem Prompt: volle Suite und statische Analyse vor jedem Commit. 4. **Verlange Rot/Grün:** Der Agent zeigt den fehlschlagenden Lauf vor dem erfolgreichen; bei Bugfixes scheitert der Test, wenn der Fix zurückgenommen wird. 5. **Füge Mutationstests auf dem Diff hinzu** und gib überlebende Mutanten an den Agenten zurück. 6. **Schütze Akzeptanztests,** die einem Menschen gehören; der Agent darf sie ausführen, nicht bearbeiten. 7. **Lass inferential Reviews beratend bleiben** und stimme sie so ab, dass ihre Kommentare lesenswert sind. 8. **Mache aus jeder menschlichen Korrektur einen Guide oder Sensor,** damit derselbe Fehler zweimal nicht ins Review kommt. Wenn du so einen Harness für ein Team aufsetzt, schau dir [AI Engineering](https://balazscsorba.com/de/expertise/ai-engineer) an. ## Quellen 1. [Birgitta Böckeler: Harness engineering for coding agent users (April 2026)](https://martinfowler.com/articles/harness-engineering.html) 2. [Birgitta Böckeler: Maintainability sensors for coding agents (Mai 2026)](https://martinfowler.com/articles/sensors-for-coding-agents.html) 3. [Simon Willison: Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/) 4. [Simon Willison: First run the tests](https://simonwillison.net/guides/agentic-engineering-patterns/first-run-the-tests/) 5. [Anthropic: Effective harnesses for long-running agents (November 2025)](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) 6. [Claude Code-Dokumentation: How Claude remembers your project](https://code.claude.com/docs/en/memory) 7. [Stryker Mutator-Dokumentation](https://stryker-mutator.io/docs/) 8. [Infection: Optionen auf der Kommandozeile](https://infection.github.io/guide/command-line-options.html) ## Häufige Fragen Was ist der Unterschied zwischen einem Guide und einem Sensor im Harness eines Coding-Agenten? Ein Guide ist Feedforward: Er lenkt den Agenten, bevor dieser handelt, etwa eine AGENTS.md-Datei, ein Skill, Typdefinitionen oder ein Scaffolding-Skript. Ein Sensor ist Feedback: Er prüft das Ergebnis, nachdem der Agent gehandelt hat, etwa Tests, ein Type Checker, ein Linter oder ein KI-Review, und gibt die Befunde zurück, damit der Agent sich selbst korrigieren kann. Kann ich Tests vertrauen, die ein Coding-Agent geschrieben hat? Nicht allein anhand der Coverage. Agentengeschriebene Tests können hohe Abdeckung mit schwachen Assertions erreichen. Prüfe sie, indem du den Agenten zuerst einen fehlschlagenden Lauf zeigen lässt, indem du den Fix zurücknimmst und verifizierst, dass der Regressionstest scheitert, und indem du auf den geänderten Zeilen Mutationstests laufen lässt, um zu sehen, ob die Tests kleine, absichtlich eingebaute Bugs fangen. Wie bringe ich einen Coding-Agenten dazu, vor dem Commit immer die Tests zu starten? Verlasse dich nicht auf eine Anweisung allein, denn Agenten überspringen Schritte aus Regeln-Dateien gelegentlich. Erzwinge das Gate mit einem Pre-Commit-Hook, einem Agent-Hook, der den Commit-Befehl blockiert, bis die Prüfungen durch sind, oder einem verpflichtenden CI-Check. Lass die Anweisung zusätzlich stehen, damit der Agent die Prüfungen früh startet und Fehler selbst behebt. Ist Mutationstests für die CI zu langsam? Auf einer ganzen Codebasis oft, aber das brauchst du nicht bei jedem Pull Request. Werkzeuge wie Infection für PHP können nur die Zeilen mutieren, die ein Branch gegenüber dem Basisbranch geändert hat, das hält den Lauf kurz. Die vollständige Mutationsanalyse läuft stattdessen nach Zeitplan. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Claude in OpenCode: der Claude-Agent-Provider, API-Keys und die anderen Wege](https://balazscsorba.com/de/blog/claude-in-opencode) - [Legacy-Codebase mit Coding-Agenten migrieren: ein Strangler-Fig-Playbook](https://balazscsorba.com/de/blog/coding-agents-legacy-codebase-migration) - [Coding-Agenten im Hintergrund: Pull Requests, Queues und Review](https://balazscsorba.com/de/blog/background-agents-async-pr-workflow) - [Browser-Agenten für E2E-Tests: Agenten Playwright-Tests schreiben lassen, nicht ausführen](https://balazscsorba.com/de/blog/browser-agents-e2e-testing-playwright) ## Klingt nach dem, was Sie suchen? Erzählen Sie mir von Ihrem Projekt oder Ihrer Stelle – ich freue mich, von Ihnen zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)