Harness engineering: how I build with coding agents

Most of the code I ship now goes through a conversation between agents before it gets to me. One builds the change and opens a pull request. Another reviews it, leaves comments, and asks questions. The first agent makes changes, pushes again, and the loop continues.

That loop is a big part of how I build now.

Harness engineering is a useful name for the work around it: giving an agent the tools, context, checks, and feedback it needs to carry a task through. OpenAI’s account of building with Codex describes a similar shift towards engineering the environment in which agents work. That framing makes sense to me. Writing the code is one part of a much larger process.

Before the loop

Before the agent writes code, I want the goal to be clear. What problem are we solving, who is it for, and what should work differently? I also want to say what is outside the scope of the change.

The spec gives that goal something concrete to work against: expected behavior, design references, important edge cases, and acceptance checks. For a small change, a few sentences can be enough. The point is to make the decisions clear, without prescribing every implementation step.

Anthropic’s Claude Code guidance puts useful emphasis on the context the agent cannot discover from the repo, and on giving it a check it can actually run. A screenshot, a failing test, or a short example of the expected behavior gives us something to compare the result against.

A brief can be this simple:

Goal: [The user problem and the outcome we want.]
Scope: [What belongs in this change, and what does not.]
Context: [Relevant files, product decisions, and design references.]
Acceptance: [Observable behavior, important edge cases, and checks to run.]

Read the relevant code first. Resolve any ambiguity that would materially
change the result. Make routine implementation decisions yourself.
Deliver the change and report the checks run, their results, and any gaps.

For Claude Opus 5.5, the current model-specific guidance recommends starting at medium effort and measuring before turning it up. Thinking is always enabled; asking for a written chain of thought is not needed. Clear requirements and evidence of the result are more useful than another instruction to “think harder.” For a longer brief, separating instructions, context, and examples also helps keep the request clear.

The loop

The coding agent handles implementation and adds automated tests. Opening a pull request automatically starts CI and the tests, with an AI review running in parallel. Every new push to the PR starts that process again. The checks include builds and security checks, and a preview environment gives us a working version of the change.

Feedback has somewhere to go. A failing test, a review comment, or something wrong in the preview goes back to the coding agent. It fixes the issue, pushes the changes, and CI and AI review run again in parallel. The useful part is keeping that cycle moving without me having to relay every comment between the two.

When everything is green and the AI feedback is addressed, I give my review and direction. Any changes I ask for go back to the coding agent and through the same loop. When I approve, the PR can move towards merge through the usual review and deployment process.

Two agents agreeing doesn’t prove a change is correct. Tests and a working preview give me more to go on than either agent saying it’s finished.

Where I spend my attention

UI/UX gets the most attention in my review. I start with the working product: how it looks, how clear it is to use, and how the interactions feel. The small details matter, and I give feedback until the experience feels right.

I also review high-stakes code, the schema, and the data structure. What are we storing? Which relationships are we creating? Does this model make sense for the product, including the things we are likely to build next?

A screen can look right while the model underneath it is awkward. I want to understand the ownership of the data, the constraints, and what a migration means for existing records. Those choices tend to stay with us longer than the first version of the interface.

I can delegate a lot of implementation once those decisions are clear. I still need to decide whether we’re building the right thing, and whether the structure supports it.

Show me the working thing

Every PR automatically gets its own preview server, updated with each push. It has enough representative test data to exercise the entire app: different roles, populated screens, and the states needed to try the main flows. The agents exercise those flows and send screenshots and short videos. I can open the preview, try it myself, and give feedback on the actual interface.

Checking out the code locally is optional. Most of the time I review in the PR preview and never need a local checkout, even for UI tweaks. I can ask for a spacing adjustment, see the updated preview, and ship it from there. If a UI/UX issue needs hands-on investigation or I want to work on the details myself, I check out the branch. That’s a choice within the review, rather than a step every change has to go through.

This is also why browser testing matters. Anthropic’s work on long-running agents describes agents declaring work complete after limited testing, and the improvement from having them exercise the app in a browser. A screenshot helps me judge the design. A video helps me follow an interaction. Neither replaces checking that the data was saved correctly or that permissions were enforced.

Then ship it

Automated tests, CI, security reviews, and agent feedback do a lot of the routine checking. Once everything is green, I review the decisions and the working result. My direction starts another round; my approval lets the change move forward. In a company, that can still mean following the usual process, such as another person reviewing the PR before merge and the normal deployment steps afterwards. A passing PR is one checkpoint; the deployed version still needs to work.

What I’m finding useful is turning recurring feedback into something the next change can use: a regression test, clearer project instructions, or another check in CI. The loop gets a little better each time.

I still care about the details. I’m spending more of my time deciding what good looks like, and building a process that can show me whether we got there.