From autocomplete to agentic harness

Four eras of engineering with AI, and how to build a good harness

In a handful of years, the way engineers work with AI has changed its centre of gravity four times. Each shift moved the real engineering effort one layer further away from the model itself.

First we accepted suggestions. Then we crafted instructions. Then we curated what the model could see. Today the craft is building the whole system the model runs inside: its tools, its boundaries, its feedback loops. That system has a name now, the harness.

This post walks through the four eras with an honest look at what each one taught us. It ends with the part I care most about: how to build a good harness, and how to choose the methods and tools that go into it.

Four eras at a glance

Each era widened the scope of what we engineer, and each one still lives inside the next. You still write prompts and curate context today; you just do it inside a harness.

Era 1 — Code assist: the smarter autocomplete

It started in the editor. A model watched the cursor and proposed the next line, then the next function. It felt like magic for about two weeks.

Then the limits showed. The assistant knew the language but not the system. It suggested code that compiled, looked idiomatic, and quietly ignored the module boundary, the error-handling convention or the reason that helper existed. In large organisations I saw adoption plateau quickly: local functions and unit tests, rewritten by the developer more often than accepted as is.

What it taught us: speed without understanding moves the cost to review. Acceptance rates were a vanity metric. The developer remained the only harness, and nobody had designed that harness on purpose.

Era 2 — Prompt engineering: the instruction as craft

Chat interfaces moved the conversation out of the editor. Suddenly the quality of the answer depended visibly on the quality of the question. We learned roles, examples, step-by-step reasoning, explicit output formats.

That discipline was genuinely useful, and it still is: a clear, well-structured instruction beats a vague one with any model. But prompts had three weaknesses that no amount of craft could fix. They were rarely versioned or tested. They were tuned to one model and decayed with the next. And however good the wording, the model still knew nothing about your system.

What it taught us: clarity is necessary, not sufficient. Teams built prompt libraries that became folklore. The ceiling was never the phrasing; it was what the model could not see.

Era 3 — Context engineering: curating what the model sees

By mid-2025 the vocabulary shifted. The question was no longer how to ask, but what to put in front of the model: which files, which documentation, which conventions, which tool results, in which order.

This era brought codebase indexing, retrieval, rules files loaded at every session, tools that pull context on demand, and techniques to compact long sessions. It also brought a counter-intuitive lesson: more context is not better context. A window stuffed with marginally relevant material degrades reasoning. Curation beats volume.

What context engineering could not do is close the loop. It raises the probability of a good first attempt, but nothing in it tells the agent whether the attempt succeeded. A perfectly informed agent can still be wrong, and nobody finds out until a human reviews the diff.

Era 4 — Harness engineering: designing the environment

The term took hold in early 2026. OpenAI described how one of its teams built software with agents writing the code, and concluded that its hardest problems had moved to environments, feedback loops and control systems. A shorthand spread with it: Agent = Model + Harness. The harness is everything except the model.

The most useful mental model I have found comes from Birgitta Böckeler. It separates two things:

• The builder harness is what ships inside the coding agent: its system prompt, its loop, its context management. You choose it; you rarely change it.
• The user harness is what your team builds around it, specific to your codebase and conventions. That is where harness engineering happens.

She then sorts every control along two axes. Guides act before the agent does and raise the odds of a good first attempt. Sensors act after and let the agent correct itself. Each can be computational (deterministic, fast, cheap: types, linters, tests) or inferential (semantic, slower, probabilistic: an AI reviewer). Guides alone give you an agent that never learns whether it complied. Sensors alone give you one that repeats the same mistake forever.

The real shift is in posture. Context engineering informs the agent. Harness engineering regulates it, and treats every recurring mistake as a defect of the harness rather than of the model.

Anatomy of a harness

The agent sits in the middle, fed by guides on the left and corrected by sensors on the right, inside an environment that limits what it can touch. Above it, the human does not review every line: they improve the guides and sensors whenever the same failure shows up twice.

Building a good harness

A harness is not a configuration you write once. It is a product you grow from evidence. This is the method I would follow on any codebase.

1. Start from failures, not features. For two weeks, log every way the agent goes wrong in your codebase: wrong layer, invented API, skipped test, over-engineered fix. That backlog is your harness roadmap.
2. Fix harnessability first. Strong typing, clear module boundaries, a fast test suite the agent can run, and a reproducible environment are what make controls possible. On a legacy codebase this step is the hardest, and the most valuable.
3. Keep guides thin. A short AGENTS.md with the build and test commands, the boundaries that must not be crossed, and where things live. Push detailed procedures into skills loaded on demand. Long instruction files get ignored from the bottom up.
4. Make computational sensors the backbone. Type checks, linters, structural tests and fast unit tests, wired into hooks so they run on every edit. Write their error messages for the agent: say what is wrong and how to fix it.
5. Add inferential sensors where computation cannot reach. A review agent with a narrow brief (security, API design, test quality) and, for long tasks, a separate evaluator rather than letting the author grade its own work.
6. Place each control by cost. Fast checks before the commit, expensive ones such as mutation testing and wide-context review in the pipeline, drift detection on a schedule. Quality stays left; nothing waits for a human that a machine could have caught.
7. Make long work resumable. Progress notes, a feature checklist and frequent commits let a fresh session pick up where the last one stopped, instead of trusting a compacted memory.
8. Contain the blast radius. A disposable sandbox, explicit allow-lists for commands and network, and approval for anything irreversible.
9. Run the steering loop. Any failure seen twice becomes a new guide or sensor. Version the harness like code, review its changes, and audit it regularly for rules that contradict each other.
10. Measure the harness itself. First-pass acceptance, rework rate, human review time per change, how often each sensor fires. A sensor that never fires proves nothing until you have shown it can.

Once this works for one service, package it. Most organisations have a few recurring service shapes; a harness template per shape is how this scales beyond one enthusiastic team.

Selecting the methods and tools

Choose tools by the harness layer they serve, and judge them on how well they plug into the loop rather than on their feature list. The options below are the ones I would evaluate first; the market moves fast, so treat names as a starting shortlist.

Three selection rules matter more than any single tool. Prefer open formats (AGENTS.md, SKILL.md, MCP) so the harness survives a change of agent. Prefer deterministic controls, and add inferential ones only where nothing computational can do the job. Count the maintenance cost: every guide and sensor is code someone must keep coherent.

What changes

The craft moved, the responsibility did not

Every era pushed the engineering one layer outward, from the line of code to the environment around the agent. What never moved is accountability. A harness does not remove the human; it directs human attention to the places where judgement matters most: intent, trade-offs, and the behaviour nobody has yet learned to test automatically.

The good news is that harness engineering is mostly engineering we already know. Types, tests, linters, fitness functions, sandboxes, observability. What is new is that we now build them for a colleague who works fast, never gets tired, and has no memory of yesterday.