Harness Engineering: Coding-Agenten systematisch steuern
Martin Fowler hat einen ausfuehrlichen Artikel veroeffentlicht, der ein neues mentales Modell fuer die Arbeit mit Coding-Agenten vorstellt: Harness Engineering. Das Konzept stammt von Birgitta Boeckeler und beschreibt eine eigene Disziplin jenseits von Prompt Engineering.
Die Kernidee: Geschirr statt Zuegel
Der Begriff "Harness" (Geschirr) ist bewusst gewaehlt. Es geht nicht darum, Agenten mit einzelnen Anweisungen zu lenken -- das waere Prompt Engineering. Harness Engineering baut stattdessen die Infrastruktur, die Agenten strukturell in die richtige Richtung zwingt, unabhaengig vom einzelnen Prompt.
Konkrete Beispiele fuer solche Strukturen:
- Tests als Leitplanken: Eine umfassende Testsuite gibt dem Agenten ein objektives Erfolgskriterium. Ohne Tests fehlt dem Agenten jedes Feedback, ob sein Output funktioniert.
- CLAUDE.md und Projektdokumentation: Kontextdateien, die dem Agenten Architekturentscheidungen, Konventionen und Einschraenkungen mitgeben.
- CI/CD-Pipelines: Automatisierte Pruefungen, die fehlerhaften Agent-Output abfangen, bevor er in die Codebasis gelangt.
- Linting-Regeln und Formatierung: Stilistische Constraints, die der Agent einhalten muss.
- Architektur-Constraints: Klare Modul- und Schichtentrennung, die der Agent nicht verletzen kann, wenn die Struktur explizit dokumentiert ist.
Der zentrale Gedanke: Je besser das Geschirr, desto autonomer kann der Agent arbeiten. Die Investition in Harness Engineering zahlt sich mit jeder Agent-Interaktion aus.
Fowlers Fragments: Drei Denkmodelle
Am gleichen Tag veroeffentlicht Fowler seine "Fragments" mit drei Konzepten, die das Bild vervollstaendigen.
Drei Ebenen der System-Gesundheit (Margaret-Anne Storey)
Margaret-Anne Storey erweitert den klassischen Begriff "Technical Debt" um zwei weitere Ebenen:
| Ebene | Bezug | Schuldenart |
|---|---|---|
| Technical Debt | Code | Kurzfristige Kompromisse in der Implementierung |
| Cognitive Debt | Menschen | Verlust des mentalen Modells ueber die Codebasis |
| Intent Debt | Artefakte | Veraltete oder fehlende Dokumentation von Absichten (Tests, Specs, ADRs) |
Cognitive Debt ist bereits ein aktiv diskutiertes Thema in der Community -- die Debatte um Agent-generierten Code und den Kontrollverlust ueber die eigene Codebasis laeuft seit Wochen (siehe Cognitive Debt: Die Slow-Down-Debatte). Storeys Modell ordnet diese Diskussion in einen groesseren Rahmen ein: Cognitive Debt ist nicht das einzige Problem. Intent Debt -- wenn die Absicht hinter Code nirgends festgehalten ist -- wird durch Agenten ebenfalls verschaerft, weil Agenten Code erzeugen koennen, dessen Zweck weder dokumentiert noch durch Tests abgesichert ist.
System 3: LLMs als dritte Denkinstanz (Shaw und Nave)
Shaw und Nave schlagen vor, Kahnemans bekanntes Zwei-Systeme-Modell um ein drittes System zu erweitern:
- System 1: Schnelles, intuitives Denken
- System 2: Langsames, analytisches Denken
- System 3: LLM-gestuetztes Denken -- ausgelagerte Kognition
Das Risiko dabei ist "Cognitive Surrender": die unkritische Uebernahme von AI-Output, weil die Pruefung muehsam ist und der Output plausibel klingt. Entwickler delegieren nicht nur das Schreiben von Code, sondern auch das Nachdenken darueber.
Fuer Harness Engineering ist das ein direktes Argument: Wenn die Gefahr besteht, dass Menschen AI-Output unkritisch uebernehmen, muessen die Pruefmechanismen automatisiert sein. Man kann sich nicht darauf verlassen, dass ein Entwickler jeden Agent-Output gruendlich reviewt.
Verifikation wird teuer (Ajey Gore)
Ajey Gores These bringt es auf den Punkt: Wenn Coding-Agenten das Schreiben von Code kostenlos machen, verschiebt sich der Engpass vollstaendig auf die Verifikation. Code zu erzeugen ist billig. Zu pruefen, ob der Code korrekt, sicher und wartbar ist, wird zum teuren Teil der Softwareentwicklung.
Das ist die oekonomische Begruendung fuer Harness Engineering. Automatisierte Verifikation -- Tests, Linting, statische Analyse, CI/CD -- ist die Antwort auf steigende Verifikationskosten. Wer heute in Harness investiert, reduziert die Kosten jeder zukuenftigen Agent-Interaktion.
Praktische Konsequenz
Harness Engineering ist kein abstraktes Konzept. Es ist die systematische Antwort auf die Cognitive-Debt-Debatte. Statt sich auf menschliche Disziplin zu verlassen (Zechners "slow down"), baut man die Strukturen, die schlechten Agent-Output strukturell verhindern oder zumindest sichtbar machen.
Die Investitionsreihenfolge fuer Teams:
- Testsuite ausbauen -- der wichtigste einzelne Hebel
- CI/CD-Pipeline mit Quality Gates -- automatisiertes Feedback
- Projektkontext dokumentieren (CLAUDE.md, ADRs, Architektur-Constraints)
- Linting und Formatierung erzwingen -- nicht optional, sondern verpflichtend
- Review-Prozesse anpassen -- Agent-generierte PRs brauchen andere Review-Kriterien als menschliche
Quellen
- Harness Engineering | Martin Fowler / Birgitta Boeckeler (April 2026)
- Fragments, 2. April 2026 | Martin Fowler (April 2026)