Harness Engineering 101

&larr; Back<br>“Done.”

You handed the agent a big task, watched it disappear for an hour, and it came back with the most dangerous word in modern software engineering: Done.

“Done, you can now verify it’s running.”, “Done: the form now matches the reference.”, “Done. The PR now contains only the production fix.”

I pulled those from my own session transcripts, and you have identical ones in yours.

It is not done. Either it built something that isn’t what you asked for, or what it built doesn’t actually work. And now you are digging through code you didn’t write, spending more time verifying “done” work than the work took to produce.

That gap between “done” and done has a name: trust. You didn’t trust the agent, and you were right not to. Every hour you spend re-checking its output is an hour paid to that missing trust.

Trust also decides how far you can climb, because code generation moves in stages, and each stage renames your job. Pre-AI, you wrote code. With AI-assisted generation, the Copilot and Cursor era, you review code. With human-supervised generation, the stage we are in now, you review features. And in the end state, what I call the software factory, where a Linear ticket turns into written, tested, verified code without anyone prompting anything, you review the system itself.

we are here PRE-AI you write code AI-ASSISTED you review code HUMAN-SUPERVISED you review features SOFTWARE FACTORY you review the system 202120252026

The stages compound, but they also gate. Switching from Copilot to Codex does not move you up a stage. Each level opens only once you have earned enough trust in the one below. Today, most of the industry sits mid-transition between the second and third stage. Only a handful of companies (OpenAI, Anthropic, Cursor, maybe a few more) are genuinely at the frontier, and even they are figuring it out by failing. The rest of us, Delphi where I work included, should have the modesty to admit we are students.

And we are students of a new job. Now that everyone can code through an agent, code itself is cheap. If your value is translating product requirements into prompts, you are a translator, and translation is exactly what the software factory automates away. The durable job is building and supervising the system that writes the code. That job is harness engineering, and this post is the playbook for it.

The loop

The whole playbook fits in one loop, the same loop you already follow as an engineer:

Prepare

Do

Review

PREPARE DO REVIEW until it passes

The difference between you and OpenAI is that they automated the loop and you still run it by hand. Each stage on the timeline is this same loop with more of it automated. Climbing to the next stage means handing the next piece of it to the system.

Every practice below invests in one of these three steps or protects an investment already made, and each one buys a specific piece of trust. Skip them, and no gate opens. Pay them, and the loop runs with less and less of you in it.

Prepare

Prepare covers everything the agent will find when a session starts, and what it finds is all it knows. Anthropic describes coding agents perfectly:

“Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”

That is your agent. Every session starts blank. If something is not written down or enforced, it does not exist.

You already know how to handle capable people with zero context, because every company onboards new hires. Every hard question about “codebases for AI” answers itself when you swap “AI” for “a new engineer.” A great codebase for agents is a great codebase for humans. The whole Prepare step is that same onboarding, applied to agents.

Document the product

A new engineer’s first need is to understand what the project is, who it serves, how to launch it, and what to expect once it runs. An agent’s first need is the same. Write that overview and keep it short.

Skip documentation about the code. The code is the one thing the agent can already read. Well-named functions and types explain the how, and prose about implementation rots the moment the implementation changes. Save the writing for what the product does and why it exists.

To test it, land in the repository, read the README file, and get the app running locally, all without opening the source. If a fresh agent can do that, your documentation is finished.

Turn the rules into a map

The overview gives a new engineer the product. Rules give them your standards, what separates a good function from a bad one, and a good strategy from a bad one. Between humans, culture does this job. You tell a colleague “this could be cleaner,” they remember, and the team converges. An agent has no team memory to converge into. So you write the rules down.

The naive version is one big rules file at the repository root, a AGENTS.md or CLAUDE.md, listing every do and...