Martin Fowler Just Gave Harness Engineering a Name, and the Numbers Back Him Up

Martin Fowler published a full article on April 2 formalizing something I've been feeling for months: the thing that separates a good coding agent from a bad one isn't the model. It's everything around the model. He calls it harness engineering.

The framework is clean. Agent = Model + Harness. The harness is every piece of scaffolding you build around the LLM: the system prompts, the file selection logic, the retry strategy, the output validators, the context window management. Fowler breaks it into two control types. Guides are feedforward controls that steer the agent before it acts (think CLAUDE.md files, system prompts, structured output schemas). Sensors are feedback controls that observe and correct after the agent acts (think linters, test suites, diff reviews, approval gates).

The proof point is what makes this more than theory. LangChain's coding agent improved from 52.8% to 66.5% on TerminalBench 2.0, jumping from somewhere in the Top 30 to Top 5. They changed zero model code. Zero. Every point of improvement came from harness changes: better context selection, smarter retry logic, improved output parsing.

This matches my experience exactly. I've spent the last year building MindPattern, and I'd estimate 80% of my engineering time goes into harness work, not prompt engineering. The CLAUDE.md files, the agent dispatch logic, the quality gates, the synthesis passes. The model is the engine, but the harness is the car.

For builders, this gives us a shared vocabulary that's been missing. When someone asks "how do I make my coding agent better?" the answer is almost never "use a better model." It's "improve your harness." Specifically: audit your guides (are you giving the agent enough context before it acts?) and your sensors (are you catching failures quickly enough to correct course?). If you're running Claude Code, your CLAUDE.md file IS your primary guide. Your test suite IS your primary sensor. Invest there.

I think Fowler naming this is going to accelerate the field. The same way "DevOps" gave infrastructure engineers a professional identity, "harness engineering" gives agent builders one. We're not prompt engineers. We're harness engineers.