An engineer at work asked me a good question last week. “What’s harness engineering, and do I actually need to learn it — or is it going to be obsolete by the time I do?” Fair question. The term is about five months old, half the people using it mean different things by it, and the people who build the most capable coding agents around keep going on record to say the thing you’d build will get absorbed into the next model.
So here is my answer, stated plainly, because I think most engineers are getting it wrong: harness engineering is the most important skill you can build right now beyond coding and architecture themselves. And the strongest evidence that it matters is that most engineers don’t yet believe they need it.
I’ve been writing harnesses for over a year, so treat that as a disclosed bias rather than a neutral survey. What follows argues against the smartest version of the other side — the case that harness work is disposable scaffolding the models will eat for breakfast — because that case is largely correct, and it still doesn’t touch the skill I’m talking about.
TL;DR
Harness engineering is real but young. The phrase traces to Mitchell Hashimoto in February 2026 and an OpenAI Codex case study days later; Fowler and Böckeler formalized it as “Agent = Model + Harness.” Report it as an emerging frame, not a settled discipline — and no “harness engineer” job title exists yet.
The labs are right that the crutch layer shrinks. Anthropic’s Cat Wu says “the models will eat your harness for breakfast”; Boris Cherny says scaffolding gets “pushed into the model itself.” No one at Anthropic said “don’t learn it.”
The benchmark fight lives at the crutch layer. Same model, different scaffold moves scores by up to 28 points on GAIA and 18.6 points on Terminal-Bench 2.0 — but Agents’ Last Exam shows model choice drives roughly 3x the spread of harness choice. Scores were beside the point.
The skill lives at a layer the benchmarks don’t measure. Not a better crutch — a different unit of work: research → spec → ticket → build → PR → review → merge → deploy, driven by the harness. OpenAI ran that loop with 3 engineers to ~1M lines and 1,500 PRs with zero human-written code.
Harness engineering is not IDE engineering. If you treat the harness as an extension of your old editor workflow, you cap your ceiling. The durable move is letting it drive and jumping in when needed.
Yes, you need to learn it. The specific syntax is throwaway. That’s exactly why the skill matters — you’re learning to operate a new unit of work, not one vendor’s config file.
The question, stated bluntly
Start with what “harness engineering” is even asking you to do, because the word carries two arguments at once and people talk past each other constantly.
I already made the case that orchestration beats model quality in It’s the Harness, Stupid back in April — same model, large spread in outcomes, the competitive edge moving from model superiority to ecosystem superiority. That piece defined what a harness is and showed that it dominates results. I’m not going to re-argue it. This is the follow-up question that piece left open: if the harness matters that much, is building one a skill worth learning — or a treadmill that resets every model release?
That distinction is the whole article. Because the answer the evidence points to is: parts of it reset every release, and the part that doesn’t is the part almost nobody is naming. Most of the public argument is being had about the parts that reset.
What a harness actually is
The cleanest definition comes from Martin Fowler and Birgitta Böckeler: “the harness” is everything in an AI agent except the model itself. Agent = Model + Harness. They split it into guides that push instructions forward and sensors that feed results back, and they frame the whole practice as a specific form of context engineering. Simon Willison puts it the same way from the other direction: a coding agent is software that acts as a harness for an LLM.
When I say “using a harness,” here’s the concrete inventory I mean:
Agents — the loop that calls the model and routes its tool calls, plus any sub-agents you dispatch work to.
Skills — reusable capabilities you can invoke by name instead of re-explaining every time.
Hooks — deterministic gates that fire on events: run the tests, block a commit, reformat on save.
Workflow — the orchestrated path from research to deploy, and who (or what) drives each step.
Harness-specific instructions — how this harness should behave, kept distinct from project-specific instructions about this codebase. Conflating those two is one of the most common configuration mistakes I see.
Memory and search — what persists across sessions, and how the agent retrieves it.
Internalize that inventory before you touch any tool, because every product arranges these pieces differently and calls them different things. Hugging Face is the one source I’ve found that formally separates the scaffolding (the behavior layer — prompts, tool descriptions, memory) from the harness proper (the execution layer that calls the model and decides when to stop), then notes that most products just call the whole bundle a harness. That ambiguity is real, not something to paper over: the term is contested, some practitioners call it an old idea in new packaging, and Latent Space literally ran a piece titled “Is Harness Engineering Real?”. I don’t want to oversell a five-month-old buzzword. I want to separate the durable part from the disposable part, and to do that I have to give the skeptics their strongest swing first.
“The models will eat your harness for breakfast”
Here’s the skeptical case in its own words, and it’s a good case.
Cat Wu, who heads product for Claude Code, has a line for it: the models will eat your harness for breakfast. Her team does a system-prompt audit on every new model and deletes the reminders the model no longer needs. Her example: a to-do enforcement tool built to stop Claude Code from overclaiming that a refactor was finished became dead weight once newer models completed multi-step refactors on their own.
Boris Cherny, who created Claude Code, says the same thing from the architecture side. In an Every.to interview, he described the tool as “the thinnest possible wrapper over the model” and said that as models advance, “stuff that used to be scaffolding... gets pushed into the model itself.” His team builds harness features they expect to delete: “we build most things... even if that means we’ll have to get rid of it in three months. If anything, we hope that we will get rid of it in three months.” Disposable on purpose. And at Sequoia’s AI Ascent this spring he extended it forward — prompt-injection defenses, static command verification, permission modes, human-in-the-loop gates would all become less critical, he argued, “because models will do the right thing themselves.”
This isn’t only an Anthropic view. It’s the bitter lesson applied to agents: building in how we think the work should be structured tends to lose, over time, to raw capability and scale. Han Lee makes the practitioner version bluntly: “Almost all of it is going to dissolve into the next generation of models... build each production harness like you mean to replace it.” Tool wrappers dissolve because models read OpenAPI specs directly now. Elaborate memory layers collapse into “plain text in progress.md plus git log.”
Two concessions I’ll make up front, because the fair version of this argument requires them. First: nobody at Anthropic said “don’t learn it.” The claim that they did is a paraphrase — a real cluster of “the harness shrinks” statements from Wu and Cherny, compressed by repetition into something stronger than anyone actually said. Second, and this is the one that stings: even the benchmark evidence for harnesses says model choice usually wins. On Agents’ Last Exam, swapping models with the harness fixed produced an 18-point pass-rate spread; swapping harnesses with the model fixed produced about 6. “The model accounts for about 3x the pass-rate spread of the harness.” If your goal is a higher number on the leaderboard, buy the better model before you tune the scaffold.
So the skeptics have a benchmark, a bitter lesson, and the people who build the reference implementation all pointing the same way. If I stopped here, the answer to “do you need to learn it” would be “not really — wait for the next model.” I don’t stop here, because all of that is arguing about a layer I don’t mean.
Why both are right — and why it doesn’t touch the real skill
The reconciliation is that “harness” names two different things, and the argument above is entirely about the first one.
The first layer is scaffolding-as-crutch. A hook that reminds the model to actually run the tests. A tool wrapper that translates an API the model can’t yet read. A permission gate that catches a mistake the model still makes. Anthropic’s own framing nails why this dissolves: “every component in a harness encodes an assumption about what the model can’t do on its own.” When the model can suddenly do that thing, the component becomes dead weight — exactly Wu’s deleted to-do tool. This layer is supposed to shrink. Anthropic builds it disposable on purpose. The benchmark gaps live here too: the 28-point GAIA swing and the 18.6-point Terminal-Bench spread measure how much a scaffold props up a fixed model’s score. Prop-up value falls as the model climbs. That’s the whole skeptical case, and it’s correct.
The second layer is workflow orchestration. Letting the harness drive the entire loop — research → spec → ticket → build → iterate → PR → review → merge → deploy — as one continuous operation instead of a sequence of prompts you babysit. This layer does not dissolve into a better model, because a better model doesn’t decide what’s safe to run unattended, what the blast radius of an autonomous change is, or where a human judgment call has to sit. Better models make the loop run better. They don’t make the loop design itself.
Blake Crosley draws the same line and I think it’s the sharpest version: harness syntax is ephemeral and gets absorbed, but verification judgment is durable — knowing what’s safe to run without watching, what the acceptable failure modes are, where the loop needs a gate. The config file you write today is throwaway. The judgment about how to structure autonomous work is not.
The killer piece of evidence sits in the phrase’s own origin story. When OpenAI published its harness-engineering case study, the headline number was three engineers producing roughly a million lines of code across 1,500 pull requests, with zero human-written code, by engineering the harness around Codex. Read that carefully. That is not a better crutch bolted onto a fixed workflow. It’s a different unit of work — the engineers stopped writing lines and started operating a loop. No model upgrade alone produces that shape of output, because the shape is a workflow-design decision, not a capability. Ryan Lopopolo’s summary of what changed is the tell: the only scarce resource left was synchronous human attention. That’s an orchestration problem, and no amount of model progress makes it go away.
This is why I can concede the entire benchmark argument without losing anything. Model choice beats harness choice on scores — sure, roughly 3x on Agents’ Last Exam. But the fight over scores is being had at the crutch layer, and the skill I mean lives at the orchestration layer, which those benchmarks don’t even measure. Even the strongest model still needs someone who knows how to hand it a whole workflow instead of a single task.
Harness engineering vs. IDE engineering
Here’s the crux, and it’s where I think most engineers cap their own ceiling without noticing.
The biggest difference between harness engineering and IDE engineering is what the unit of work is. In the editor era — including the AI-autocomplete-in-your-editor era — the unit is a change you make, assisted. You’re still driving. The tool suggests, you accept, you commit. A good harness inverts that. The unit becomes an outcome you delegate: research through deploy, handled by the harness, with you supervising the loop rather than typing inside it.
If you approach a harness as an extension of your existing editor workflow — a faster autocomplete, a smarter pair — you’ll get some lift and you’ll hit a ceiling fast, because you’re still the bottleneck on every step. The results I’ve gotten that actually surprised me came from letting the harness drive the whole loop and jumping in only where my judgment was needed: at the spec, at the review, at the “is this safe to merge” gate. That maps exactly onto Crosley’s durable skill. You’re not writing less carefully. You’re spending your attention on the decisions that don’t delegate, and letting the loop own the ones that do.
This is a materially different workflow from anything I did before agents, and I say that as someone who’s lived through several supposed paradigm shifts that turned out to be the same job with new keybindings. This one isn’t. The muscle you build isn’t “prompt the model well.” It’s “decompose an outcome into a loop a machine can run mostly unattended, and know precisely where to stand in it.” Harrison Chase, who runs LangChain, frames harness engineering as an extension of context engineering, and that lineage is right — context engineering is about a year old and settled, harness engineering is the newer, contested layer on top. But the operative verb changed. You’re not composing a context window. You’re operating a workflow.
Do you need to learn it? Yes — here’s how
Yes. The fact that it still feels optional is the problem, not a reason to wait.
Here’s the path I’d suggest, and it’s roughly the one I took.
Start by understanding what using a harness means — the inventory from earlier: agents, skills, hooks, workflow, harness-specific versus project-specific instructions, memory, search. Not as vocabulary. As the actual pieces you’ll arrange. If those seven words don’t map to concrete settings you can change, start there before you touch a workflow.
Try several, and configure them well. Don’t judge the category from one tool on defaults. Learn to tune Claude Code yourself until it performs, rather than running it out of the box and concluding the harness “doesn’t matter.” Try Codex, Gemini, Auggie, OpenCode. I built claude-mpm, so weight my enthusiasm for the multi-agent approach accordingly — the point isn’t which one wins, it’s that you can’t feel the shape of the skill from a single vendor’s config.
Lean into the differences instead of smoothing them over. The instinct is to find the tool that feels most like your old editor and stop. The results live in the opposite direction — in the workflows that feel least familiar, where the harness drives and you supervise. Best results come from leaning into what’s different, not translating it back into what you already knew.
Let it drive, and know where to stand. This is the whole skill in one sentence. Hand the loop the outcome, supervise at the gates your judgment actually owns, jump in when the blast radius or the ambiguity demands it. That standing-in-the-right-place instinct is what transfers across every tool and survives every model release.
And that’s the reframe I’ll close on. Everything about the specific harness you learn this quarter is throwaway. The config syntax, the exact hooks, the tool wrappers — Han Lee is right, the next model eats away at it. But that’s precisely why the skill is worth building, not a reason to skip it. You’re not learning one vendor’s settings file. You’re learning to operate a new unit of work — an autonomous loop from research to deploy — and that competence is the thing the model upgrades keep raising the value of, not erasing. The syntax is disposable. The judgment about how to run the loop is what compounds.
Most engineers will figure this out eventually, when the workflow shift is obvious in hindsight. The ones who figure it out now get a head start measured in the gap between “my editor got smarter” and “my unit of work changed.” I’d rather be early on that one.
One layer up: loop engineering
There’s a move past the harness, and it picked up a name while I was writing this.
The stack is starting to read like a ladder: prompt engineering, then context engineering, then harness engineering — and now loop engineering on top. Each rung stops being where you spend your attention once the rung below it gets good enough to trust. You quit hand-tuning prompts when context engineering settled into a roughly year-old, mostly-solved practice. The bet underneath loop engineering is the same shape one level up: once your harness is solid, you stop prompting the agent and start designing the loops that prompt it for you.
The term isn’t mine. Addy Osmani formalized it in June, and his definition is the one I’d hand someone first: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” He also collected two lines that land the shift faster than I can. Peter Steinberger’s version: you should be designing the loops that prompt your agents. And Boris Cherny — the same Cherny from the “eat your harness for breakfast” section — put it flatly: “I don’t prompt Claude anymore… my job is to write loops.” LangChain picked it up a week later, and their framing is the practical one: you don’t build a loop, you stack them — an agent loop inside a verification loop inside an event-driven loop inside a hill-climbing loop, each one checking the one below it.
Here’s the seam between the two layers, drawn plainly. Harness engineering is the discipline of building the scaffolding — the agents, hooks, skills, gates, and workflow from the inventory up top. Loop engineering is what you do once that scaffolding is good enough that you stop typing prompts and start directing repeatable cycles. The harness is what you build. The loop is what you run on it, again and again, with your attention moved up to which loops to run and when to trust them unattended. That’s the same “let it drive, know where to stand” instinct from a few paragraphs back, pushed one rung higher: now you’re not standing inside the loop at all — you’re choosing which loops get to run.
I’m not planting a flag here. The people already naming it are out ahead of me, and that’s the reason to point at it — this is where the harness work goes next, not a term I’m coining. If harness engineering closes the gap between “my editor got smarter” and “my unit of work changed,” loop engineering is what shows up on the far side of that gap, once the unit of work is a cycle you supervise instead of a task you run. I’m watching that one closely. And I’d start learning it before it feels obvious.
Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.
Related reading:
It’s the Harness, Stupid — The predecessor to this piece: same model, wide spread in outcomes, and why the competitive edge moved from model quality to orchestration. It defined what a harness is; this piece argues that building one is a skill worth learning.
HyperDev’s Three Golden Rules — The working rules I keep coming back to for professional AI work, and the discipline that keeps a driven-by-the-harness loop from running off the rails.
Claude Sonnet 5 Takes the Default Driver Slot — A concrete example of the crutch layer shrinking: adaptive thinking folds interleaved reasoning into the model, removing work harness authors used to do by hand.
Loop Engineering — Addy Osmani’s June 2026 piece that named the layer above the harness: once the scaffolding holds, you stop prompting the agent and design the loops that prompt it. The forward edge of the arc this article traces.
The Art of Loop Engineering — LangChain’s treatment of loop engineering as stacked loops — agent, verification, event-driven, hill-climbing — each one checking the one beneath. The practitioner’s map of where harness work heads next.
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners, including the coding-agent leaderboards this piece leans on.