Harness engineering: the discipline that makes AI code shippable

When an AI agent writes bad code, the instinct is to blame the model. In our experience the cause is more often the harness: everything around the model that determines what it sees, what it can do, and how its work is checked. Harness engineering is the practice of designing that system on purpose.

The five parts of a harness

1. Context

What the agent knows when it starts: the architecture, the conventions, the relevant files, the definition of done. Too little context and it invents patterns; too much and it loses the thread. Good harnesses curate context per task — project instructions, focused file sets, and short, current documentation rather than everything at once.

2. Tools

What the agent can do: run tests, query a schema, read logs, call an internal API through MCP. Every tool is a capability and a risk. We give agents the smallest set of tools that lets them verify their own work, because an agent that can run the tests writes code that passes them.

3. Guardrails

What the agent must never do: push to main, touch production data, print secrets, bypass review. Guardrails live in permissions, hooks and CI rules — not in a polite request inside a prompt. If a rule matters, enforce it mechanically.

4. Checks

How work is judged: the regression suite, type checks, linters, security scanners, contract tests, visual diffs. Checks turn "seems fine" into pass or fail. They are also the fastest feedback loop an agent can have; we route their output straight back into the agent's next attempt.

5. Evaluation

How the harness itself improves: tracking which tasks agents complete first time, which fail review, and why. When the same mistake repeats, we fix the harness — a missing convention, an absent test, a tool the agent needed — rather than re-prompting forever.

Why this is engineering, not prompting

Prompts matter, but they are the smallest part. A harness is versioned, tested and reviewed like any other code. It has owners. It regresses when people change it carelessly. Treating it as infrastructure is what separates teams whose AI output improves every month from teams stuck at "it's impressive, but we can't trust it".

A simple maturity test

1. Can an agent run your full test suite locally, quickly, without a human?
2. Are your conventions written down where an agent will read them?
3. Are your most important rules enforced by tooling rather than by trust?
4. Do you know which kinds of task your agents fail at?

Four yeses and you have a harness. Fewer, and that is where your next sprint should go — before you add another model, agent or subscription.