The model is not the system: what we learned adopting a coding harness

For a long time we thought the important question was which model to use for coding. The newest model. The one with the best reasoning. The one that promised to write more code with fewer mistakes.

This week we changed our view.

The important question is not which model you have. It is the system around it: what context it receives, what it can touch, when the model changes, how the result is verified, and who decides whether it ships.

At Zero Ops, we call that system a harness. It is not a long prompt. It is the complete way you work with an agent.

We did not build this harness from scratch. We adopted existing patterns and tools, then adapted them to our working environment. The research is in understanding what deserves to stay, what needs to change, and what we still cannot claim is proven.

This article keeps three things separate: what we read in public sources, what we tested in our environment, and what is still a hypothesis.

The bill is mostly reading

Can Bölük (@_can1357) published an analysis of roughly 1.81B tokens across about 2 million tool calls. In that dataset, only 9% of tokens were edits and writes; the remaining 91% was reading, searching and context.

That is the author’s observation, not a universal law for every agent. But it changes how you look at cost. An agent spends most of its time trying to understand where it is, not typing the final change.

If a workflow makes two models read the same code, you have duplicated the expensive part before the first edit.

A plan is a postcard

The usual pattern sounds sensible:

1. the expensive model reads the repository and prepares a plan;
2. the cheap model receives the plan;
3. the cheap model executes it.

The problem is that a plan is a 2,000-token postcard. The real understanding was in the journey: files read, hypotheses rejected, errors found, and decisions made while touching the code.

The executor receives the postcard, not the journey. So it reads everything again.

In Stencil’s benchmark, Opus 4.8 on its own cost $2.78 per task with an 85% pass rate. Opus with /plan and Flash executing cost $3.18 with an 84.6% pass rate. The supposed saving was 14% more expensive.

That does not make planning useless. It means that separating planning and execution with a document does not guarantee that you transferred understanding.

Prewalk: transfer the trajectory

The alternative we find most interesting is called prewalk.

The flow is:

1. the frontier model explores the problem;
2. it turns what it learned into a short task list with validation;
3. it makes the first edit;
4. at that moment, the harness switches to the cheap model inside the same session;
5. the cheap model continues with the trajectory, the TODO list, and a valid first move as an example.

The switch does not happen because four turns have passed. It happens when two signals exist: an executable TODO list and a valid first edit.

In Stencil’s Opus arm, /prewalk lowered cost to $1.46 and time to 6.7 minutes, with a 78% pass rate. Quality is lower than Opus alone and cost is lower. That trade-off is the result; whether it is worth it depends on the task.

The same article measures how often runs search the published solution to the bug online. For Opus, the rate moved from 44% in the direct run to 72% with /plan and 13% with /prewalk. That is specific to SWE-Bench Pro, not a general claim about model intent.

My short version is: do not pass the cheap model the summary. Pass it the session.

Five phases, five questions

The other idea we are keeping is to separate roles. An agent that explores, plans, executes and grades itself against the same objective eventually mixes those jobs.

We use this sequence:

• Explorer: what is the real problem?
• Planner: what depends on what, and where does a human decide?
• Worker: what concrete task happens now?
• Critic: what could be wrong or simpler?
• Promoter: what changed, what evidence exists, and what remains open?

This is not an industry standard. It is a working arc that makes context changes visible and lets you choose the right model and verification level for each phase.

The worker does not need to re-argue the whole architecture on every step. The critic should not merely say that everything looks fine. The promoter prevents technically finished work from disappearing without communication or a record.

What is inside a harness

A useful harness contains unglamorous pieces:

1. Entry rules: an AGENTS.md defining scope, folders, style and stop conditions.
2. Reusable skills: one source of truth that different agents can read without copying instructions by hand.
3. Contracted tools: valid arguments, clear errors and bounded permissions.
4. Controlled context: working memory and relevant decisions, not every old message accumulated forever.
5. Verification outside the generator: build, tests, output, diff and then judgement.
6. Tracing: what was requested, what changed, what was checked and what could not be proven.
7. A human gate: the agent can propose and execute within scope; publication and high-risk changes need a decision.

Scott Fryxell’s argument points in the same direction: if Cursor, Claude, Pi or Codex read the same skills and rules, the interface becomes interchangeable. The advantage is not the brand of the UI. It is the shared working system.

What we adopted and adapted in our environment

This section is personal experience, dated August 28, 2026.

Already working

• We use a shared skills folder so Codex and Claude Code do not learn different rules.
• We separate exploration, planning, execution and review when a task has several moving parts.
• We run cheap checks first: build, tests, output and diff.
• We treat context and evidence as part of the work, not documentation added at the end.

Not proven yet

• automatic prewalk handoff on real tasks in our repository;
• which cheap model keeps quality best as a worker for each kind of change;
• whether the five-phase arc measurably reduces our review cycles;
• whether a new model behaves consistently in tools and JSON, not just chat and vision.

This distinction matters. Adopting a pattern does not prove that it works in production. A convincing conversation does not prove it either.

The objections belong in the design

There are three objections we do not want to hide.

First: for some teams, a separate plan protects the main context and makes sub-agent coordination easier. It may be the right decision.

Second: if a person reviews every line, saving a dollar on the model and paying for another review round is bad business. Human time has a price too.

Third: a high-risk change does not become safe because the worker is cheap. If the cost of a mistake is high, running the frontier model for the whole flow may be cheaper in real terms.

The decision is not “expensive versus cheap”. It is:

• how expensive is rereading?
• how expensive is review?
• what damage can an error cause?
• which automated checks exist?
• how much of the work already has a known pattern?

A 30-minute test

To find out whether your own harness is helping, choose a small task and record five things:

1. how many turns pass before the first edit;
2. which files the agent had to read more than once;
3. which part of the plan was lost when the model changed;
4. which checks caught errors without another model;
5. which human decision was explicit at close.

You do not need to build a platform. You need a comparison. Run it once directly and once with a controlled handoff. Measure time, reads, errors and human review. If you only measure tokens, you are missing half the cost.

The conclusion

Models will keep changing. One name will replace another and the catalogue will fill up with new promises.

What remains is the system around them:

• what context enters;
• what counts as done;
• when the model changes;
• who verifies;
• what evidence remains;
• and who has permission to continue.

The model can be interchangeable. The harness is the operation.

From experiment to capability

At Zero Ops, we help clients implement this kind of solution in their operations: understand where it creates value, adapt it to their processes, and leave clear rules, checks, and ownership behind.

The goal is not to become another dependency for every adjustment. It is for the team to operate, review, and improve the system on its own, reducing the need for recurring professional services. If the system only works while we are inside it, we have not transferred capability: we have created another black box.

If your company is trying to move agents or automations into production, the 2-week operations roadmap is the first door. We leave you with the flow mapped, value measured, and a plan your team can keep executing.

Sources, authors and projects

• Scott Fryxell — The Harness Is the Thing, GitHub @scott-fryxell and brayness. The author’s thesis, personal workflow and public harness.
• Can Bölük — You only need the frontier model for one single edit, X @_can1357. Token distribution, SWE-Bench Pro benchmark and prewalk.
• Fred Hohman, Matthew Conlen, Jeffrey Heer and Duen Horng Chau, Communicating with Interactive Articles. Principles and limits of interactive articles.
• Bruno Gonçalves — Building an Advanced Agentic Harness, X @bgoncalves and DataForScience/LLMs. Roles, tools, plans and verification primitives.
• Hacker News discussion. Community counterpoints.

Benchmark data belongs to its authors. Observations about our environment are personal and dated. General conclusions are interpretation, not a performance promise.