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

## Veille

Harness engineering: a mental model for building trust in coding agents through feedforward guides and feedback sensors

## 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, sensors, guides, cybernetics, software quality, context engineering, computational controls, inferential controls, maintainability harness, architecture harness, behavior harness, harnessability, harness templates, steering loop, shift left, linters, structural tests, AI code review

## Authors

Birgitta Böckeler

## Ton

**Profile**: Analytical and pedagogical perspective, accessible technical register, expert level but made approachable. Birgitta writes like a senior software architect structuring an emerging domain.

**Description**: The tone is that of a distinguished engineer proposing a rigorous yet pragmatic conceptual framework. The writing is structured and progressive, with precise definitions and clear taxonomies (feedforward/feedback, computational/inferential). The author uses metaphors from cybernetics (governor, regulator, Ashby's law) to anchor the argument in existing theory, while remaining aware of their limits ("metaphors only go so far"). The style alternates between theoretical exposition and concrete examples drawn from practice at Thoughtworks, OpenAI, and Stripe. The article addresses senior developers and architects who already use coding agents and are looking for a mental model to structure their approach. The tone is honest about current limitations, particularly for the behavioral harness, and ends with open questions rather than certainties.

## Pense-betes

- **Key definition**: the "harness" of a coding agent = everything surrounding the model. Distinction between the internal harness (built by the agent's creator) and the external harness (built by the user for their context)
- **Two fundamental axes**: guides (feedforward, before the action) and sensors (feedback, after the action); each can be computational (deterministic, fast, CPU) or inferential (semantic, non-deterministic, GPU)
- **Steering loop**: the human's role is to iterate on the harness when a problem recurs, not to manually fix each error
- **Shift left**: distribute controls as early as possible in the lifecycle (pre-commit, pre-integration, pipeline, continuous monitoring)
- **Three regulation categories**: maintainability (the easiest, existing tooling), architectural fitness (fitness functions), behavior (the hardest, the "elephant in the room")
- **Harnessability**: not all codebases are equally harnessable. Strongly typed languages, abstract frameworks (Spring), and clear modular boundaries increase harnessability. Heavily debt-laden legacy code is the hardest to harness but needs it the most
- **"Ambient affordances"** (Ned Letcher): structural properties of the environment that make it legible and navigable by agents
- **Ashby's law**: a regulator must have at least as much variety as the system it governs. Defining service topologies reduces variety, making a complete harness more attainable
- **Harness templates**: evolution of existing service templates into bundles of guides+sensors per topology (dashboard, CRUD, event processor)
- **Important limitation**: harnesses do not reliably capture high-level problems (misdiagnosis, over-engineering, misunderstood instructions). Human experience remains an irreplaceable "implicit harness"
- **Relation to context engineering**: harness engineering is a specific form of context engineering applied to coding agents
- **Concrete examples**: OpenAI uses custom linters + structural tests + "garbage collection"; Stripe uses pre-push hooks + heuristics + blueprints
- **Positive prompt injection**: customized linter messages that include correction instructions are a beneficial form of prompt injection

## RésuméDe400mots

The term "harness" designates everything surrounding an AI model within an agent. Birgitta Böckeler proposes a conceptual framework specific to coding agent users, distinguishing the internal harness (built by the agent's creator) from the external harness (that users build for their own context).

The model is organized around two complementary mechanisms. **Guides** (feedforward controls) anticipate the agent's behavior and steer it before it acts: coding conventions, specifications, skills, MCP servers. **Sensors** (feedback controls) observe after the action and allow the agent to self-correct: linters, tests, static analysis, AI code reviews. Each mechanism can be **computational** (deterministic, fast, reliable) or **inferential** (semantic, more costly, non-deterministic). Both are necessary: without feedback, the agent repeats its mistakes; without feedforward, it encodes rules without knowing whether they work.

The article applies the **shift left** principle: distributing controls as early as possible in the development cycle. Fast controls (linters, unit tests) run before the commit, while costlier ones (mutation testing, architectural review) run in the integration pipeline. Continuous sensors monitor code drift and production metrics.

Three **regulation categories** are identified. The **maintainability** harness is the most mature, relying on existing tooling (linters, complexity analyzers, test coverage). The **architectural fitness** harness reuses the concept of fitness functions for non-functional characteristics. The **behavior** harness remains the major challenge: how to verify that the application does what it is supposed to do? AI-generated test suites are not yet sufficiently reliable.

The concept of **harnessability** underscores that not all codebases are equally amenable to harnessing. Typed languages, abstract frameworks, and modular architectures offer more purchase. Ashby's law of cybernetics justifies **harness templates**: by reducing the variety of possible topologies (dashboard, CRUD, event processor), a complete harness becomes more attainable.

The author concludes that human experience remains an irreplaceable "implicit harness." The goal is not to eliminate the human but to direct their attention to what matters most. Harness engineering is a continuous engineering practice, not a one-time configuration, and many questions remain open regarding harness consistency, evaluation, and orchestration.

## 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/en/fiches/boeckeler-harness-engineering-coding-agents-2026-04-02/