# From autocomplete to agentic harness

> Four eras of engineering with AI, from autocomplete to agentic harnesses: what each one taught us, and how to build a good harness and choose its tools.

Source: https://www.bluewise.fr/from-autocomplete-to-agentic-harness  
Author: Marc Morel  
Published: 2026-07-12  
Category: Engineering

## 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 | Roughly | What you engineer | Unit of work | Where feedback comes from | Typical failure |
| --- | --- | --- | --- | --- | --- |
| Code assist | 2021–2023 | Almost nothing: you accept or reject | A line, a function | Your own eyes, in the editor | Plausible code that is subtly wrong |
| Prompt engineering | 2023–2024 | The instruction | A single exchange | You re-read and re-prompt | Brittle prompts that break with the next model |
| Context engineering | 2025 | What the model sees | A session, one context window | Retrieval quality, then human review | Stale, contradictory or overloaded context |
| Harness engineering | 2026 onwards | The environment the agent acts in | A task carried end to end | Tests, linters, structural checks, review agents, runtime signals | A harness that drifts, or sensors that stay silent for the wrong reason |

## 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](https://openai.com/index/harness-engineering/) 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](https://martinfowler.com/articles/harness-engineering.html). 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.

| Harness layer | Method | Tools to evaluate | What to check before choosing |
| --- | --- | --- | --- |
| Coding agent (builder harness) | Pick one primary agent per team, keep a second for comparison | Claude Code, OpenAI Codex CLI, Gemini CLI, Cursor, OpenCode | Hooks, permission model, sub-agents, headless mode for CI, choice of model |
| Guides: conventions and procedures | Thin always-on file, detailed skills on demand | `AGENTS.md`, Agent Skills (`SKILL.md`) | Supported natively by your agent, versioned in the repo |
| Guides: intent | Spec-driven development: the spec is the feedforward for behaviour | GitHub Spec Kit, OpenSpec, Kiro | Specs readable by humans, diffable, linked to tests |
| Guides: code intelligence | Give the agent the compiler's view, not just text | Language servers, OpenRewrite recipes, codemods | Works headless, deterministic output |
| Sensors: fast and computational | Run on every edit through hooks | Strict type checkers, ESLint, Ruff, Semgrep | Runs in seconds, messages actionable by an agent |
| Sensors: architecture fitness | Encode boundaries as tests | ArchUnit, dependency-cruiser | Rules live in code, fail with a clear explanation |
| Sensors: test quality | Check that the tests the agent wrote can actually fail | Stryker, PIT (mutation testing) | Affordable in the pipeline, incremental mode |
| Sensors: inferential | Narrow review agents, separate evaluator for long tasks | Review skills or sub-agents in your coding agent | One concern per reviewer, findings traceable |
| Harness evaluation | Regression-test the harness when guides, skills or models change | promptfoo, Inspect AI | Reproducible task sets from your own codebase |
| Environment | Disposable, least-privilege workspaces | Dev containers, container or microVM sandboxes | Network allow-lists, fast reset, no production credentials |
| Observability | Trace every agent run end to end | OpenTelemetry GenAI conventions, Langfuse | Cost, tokens, tool calls and sensor results in one trace |

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.