# boeckeler-harness-engineering-coding-agents-2026-04-02

## Veille

Harness Engineering: ein mentales Modell für den Aufbau von Vertrauen in Coding-Agenten durch Feedforward-Guides und Feedback-Sensoren

## Titre Article

Harness engineering for coding agent users

## Date

2026-04-02

## URL

https://martinfowler.com/articles/harness-engineering.html

## Keywords

harness engineering, coding agents, feedforward, feedback, sensoren, guides, kybernetik, softwarequalität, context engineering, computational controls, inferentielle controls, wartbarkeits-harness, architektur-harness, verhaltens-harness, harnessability, harness templates, steering loop, shift left, linter, strukturelle tests, KI-code-review

## Authors

Birgitta Böckeler

## Ton

**Profil**: Analytische und pädagogische Perspektive, zugängliches technisches Register, Expertenniveau, aber leicht verständlich gemacht. Birgitta schreibt wie eine Distinguished Engineer, die ein aufkommendes Feld strukturiert.

**Beschreibung**: Der Ton entspricht dem einer Distinguished Engineer, die ein rigoroses, aber pragmatisches konzeptuelles Rahmenwerk vorschlägt. Der Schreibstil ist strukturiert und progressiv, mit präzisen Definitionen und klaren Taxonomien (Feedforward/Feedback, computational/inferentiell). Die Autorin verwendet Metaphern aus der Kybernetik (Governor, Regulator, Ashbys Gesetz), um die Argumentation in bestehender Theorie zu verankern, bleibt sich dabei aber deren Grenzen bewusst („Metaphern tragen nur bis zu einem gewissen Punkt“). Der Stil wechselt zwischen theoretischer Darlegung und konkreten Beispielen aus der Praxis bei Thoughtworks, OpenAI und Stripe. Der Artikel richtet sich an erfahrene Entwickler und Architekten, die bereits Coding-Agenten nutzen und ein mentales Modell suchen, um ihren Ansatz zu strukturieren. Der Ton ist ehrlich hinsichtlich der aktuellen Grenzen, insbesondere beim Verhaltens-Harness, und endet mit offenen Fragen statt mit Gewissheiten.

## Pense-betes

- **Kerndefinition**: das „Harness“ eines Coding-Agenten = alles, was das Modell umgibt. Unterscheidung zwischen dem internen Harness (vom Ersteller des Agenten gebaut) und dem externen Harness (vom Nutzer für seinen Kontext gebaut)
- **Zwei grundlegende Achsen**: Guides (Feedforward, vor der Handlung) und Sensoren (Feedback, nach der Handlung); jeder kann computational (deterministisch, schnell, CPU) oder inferentiell (semantisch, nicht-deterministisch, GPU) sein
- **Steering Loop**: die Rolle des Menschen besteht darin, das Harness zu iterieren, wenn ein Problem wiederkehrt, nicht jeden Fehler manuell zu beheben
- **Shift Left**: Kontrollen so früh wie möglich im Lebenszyklus verteilen (Pre-Commit, Pre-Integration, Pipeline, kontinuierliches Monitoring)
- **Drei Regulierungskategorien**: Wartbarkeit (die einfachste, bestehendes Tooling), architektonische Eignung (Fitness-Funktionen), Verhalten (die schwierigste, der „Elefant im Raum“)
- **Harnessability**: nicht alle Codebasen sind gleichermaßen harnessfähig. Stark typisierte Sprachen, abstrakte Frameworks (Spring) und klare modulare Grenzen erhöhen die Harnessability. Stark technisch verschuldeter Legacy-Code ist am schwersten zu harnessen, braucht es aber am meisten
- **„Ambient Affordances“** (Ned Letcher): strukturelle Eigenschaften der Umgebung, die sie für Agenten lesbar und navigierbar machen
- **Ashbys Gesetz**: ein Regulator muss mindestens so viel Vielfalt besitzen wie das System, das er steuert. Die Definition von Service-Topologien reduziert die Vielfalt und macht ein vollständiges Harness erreichbarer
- **Harness-Templates**: Weiterentwicklung bestehender Service-Templates zu Bündeln aus Guides+Sensoren pro Topologie (Dashboard, CRUD, Event-Prozessor)
- **Wichtige Einschränkung**: Harnesse erfassen übergeordnete Probleme (Fehldiagnosen, Over-Engineering, missverstandene Anweisungen) nicht zuverlässig. Menschliche Erfahrung bleibt ein unersetzliches „implizites Harness“
- **Bezug zu Context Engineering**: Harness Engineering ist eine spezifische Form des Context Engineering, angewandt auf Coding-Agenten
- **Konkrete Beispiele**: OpenAI verwendet benutzerdefinierte Linter + strukturelle Tests + „Garbage Collection“; Stripe verwendet Pre-Push-Hooks + Heuristiken + Blueprints
- **Positive Prompt-Injection**: angepasste Linter-Meldungen, die Korrekturanweisungen enthalten, sind eine nützliche Form der Prompt-Injection

## RésuméDe400mots

Der Begriff „Harness“ bezeichnet alles, was ein KI-Modell innerhalb eines Agenten umgibt. Birgitta Böckeler schlägt ein konzeptuelles Rahmenwerk vor, das speziell für Nutzer von Coding-Agenten gilt, und unterscheidet zwischen dem internen Harness (vom Ersteller des Agenten gebaut) und dem externen Harness (das Nutzer für ihren eigenen Kontext bauen).

Das Modell ist um zwei komplementäre Mechanismen organisiert. **Guides** (Feedforward-Kontrollen) antizipieren das Verhalten des Agenten und lenken es, bevor er handelt: Coding-Konventionen, Spezifikationen, Skills, MCP-Server. **Sensoren** (Feedback-Kontrollen) beobachten nach der Handlung und ermöglichen dem Agenten eine Selbstkorrektur: Linter, Tests, statische Analyse, KI-Code-Reviews. Jeder Mechanismus kann **computational** (deterministisch, schnell, zuverlässig) oder **inferentiell** (semantisch, kostspieliger, nicht-deterministisch) sein. Beide sind notwendig: ohne Feedback wiederholt der Agent seine Fehler, ohne Feedforward kodiert er Regeln, ohne zu wissen, ob sie funktionieren.

Der Artikel wendet das **Shift-Left**-Prinzip an: Kontrollen so früh wie möglich im Entwicklungszyklus verteilen. Schnelle Kontrollen (Linter, Unit-Tests) laufen vor dem Commit, während kostspieligere (Mutation Testing, architektonisches Review) in der Integrationspipeline laufen. Kontinuierliche Sensoren überwachen Code-Drift und Produktionsmetriken.

Es werden drei **Regulierungskategorien** identifiziert. Das Harness für **Wartbarkeit** ist am ausgereiftesten und stützt sich auf bestehendes Tooling (Linter, Komplexitätsanalysatoren, Testabdeckung). Das Harness für **architektonische Eignung** greift auf das Konzept der Fitness-Funktionen für nicht-funktionale Eigenschaften zurück. Das Harness für **Verhalten** bleibt die größte Herausforderung: Wie lässt sich verifizieren, dass die Anwendung das tut, was sie tun soll? KI-generierte Testsuiten sind noch nicht zuverlässig genug.

Das Konzept der **Harnessability** unterstreicht, dass nicht alle Codebasen gleichermaßen für ein Harness geeignet sind. Typisierte Sprachen, abstrakte Frameworks und modulare Architekturen bieten mehr Ansatzpunkte. Ashbys Gesetz der Kybernetik rechtfertigt **Harness-Templates**: Durch Reduzierung der Vielfalt möglicher Topologien (Dashboard, CRUD, Event-Prozessor) wird ein vollständiges Harness erreichbarer.

Die Autorin kommt zu dem Schluss, dass menschliche Erfahrung ein unersetzliches „implizites Harness“ bleibt. Das Ziel ist nicht, den Menschen zu eliminieren, sondern seine Aufmerksamkeit auf das Wesentliche zu lenken. Harness Engineering ist eine kontinuierliche Engineering-Praxis, keine einmalige Konfiguration, und viele Fragen zu Konsistenz, Bewertung und Orchestrierung des Harness bleiben offen.

## GrapheDeConnaissance

- Birgitta Böckeler —publie→ Harness engineering for coding agent users (DOCUMENT, 0.99)
- Birgitta Böckeler —travaille_chez→ Thoughtworks (ORGANISATION, 0.98)
- Harness engineering —est_variante_de→ Context engineering (METHODOLOGIE, 0.95)
- Harness engineering —utilise→ Guides feedforward (CONCEPT, 0.98)
- Harness engineering —utilise→ Capteurs feedback (CONCEPT, 0.98)
- Guides feedforward —améliore→ Probabilité de bons résultats (CONCEPT, 0.9)
- Capteurs feedback —permet→ Auto-correction de l'agent (CONCEPT, 0.9)
- Harnais de comportement —est_instance_de→ Défi majeur non résolu (CONCEPT, 0.92)
- Loi d'Ashby —soutient→ Templates de harnais (CONCEPT, 0.88)
- Ned Letcher —a_créé→ Ambient affordances (CONCEPT, 0.9)
- OpenAI —utilise→ Linters custom et tests structurels (METHODOLOGIE, 0.92)
- Stripe —utilise→ Pre-push hooks et blueprints (METHODOLOGIE, 0.92)
- Harnachabilité —est_basé_sur→ Typage fort et modularité (CONCEPT, 0.88)
- Expérience humaine —est_instance_de→ Harnais implicite irremplaçable (CONCEPT, 0.85)

---
Canonical: https://www.thekb.eu/de/fiches/boeckeler-harness-engineering-coding-agents-2026-04-02/