Daniel's been living inside Claude Code since day one, and he's got this metaphor that I can't shake now — he says it feels like a pseudo-parent relationship. You watch this thing go from promising but buggy to almost dependable, and every day is an education in working with something that's evolving under your feet. He's trying to pull apart two things that are changing at the same time. On one side, Anthropic drops progressively more capable models — rapid, but not daily. On the other, the agentic harness, the scaffolding around the model, is being refined on something closer to a continuous deployment cycle. His question is, if you could isolate the harness improvements from the model upgrades, what would you actually be looking at? What does good harness engineering look like? Because he's starting to think it's just as important as the raw intelligence in the model.
He's right. And the confusion he's describing — is this better because the model got smarter or because the harness got tighter — that's not a personal failure of observation. That's the natural result of shipping both things at once and not labeling which is which.
So today we're going to isolate the harness. What's it doing, how do you know when it's doing it well, and why does it matter that we can tell the difference.
Let's start with what Claude Code actually is, because the origin story matters here. It started as an internal experiment at Anthropic — not a flagship product, not something they announced with a keynote. Engineers built it for themselves, a terminal-based agent that could read files, run commands, write code, and execute multi-step tasks autonomously. And then developers outside the company got wind of it, and it exploded through word-of-mouth. No marketing push. Just developers telling other developers, you have to try this thing.
Which is itself a signal. When a tool spreads through developer word-of-mouth rather than a launch event, it's usually because it solves a real pain point in a way that's immediately obvious to the person using it.
And the pain point here is context switching. A developer working on a feature has to hold the codebase in their head, navigate files, remember conventions, run tests, read error messages, fix things, commit. Claude Code sits in the terminal and does all of that — you describe what you want, and it executes across multiple steps without you babysitting each one. That's the agentic part. It's not autocomplete. It's not a chatbot you paste code into. It's an agent that operates your development environment.
So the harness is the thing that turns a language model into an operator. The model says what to do, the harness makes it actually happen and catches it when it falls over.
And I want to get concrete about what that harness actually does, because "scaffolding" is a vague word and it's hiding a lot of real engineering. Let me walk through the mechanisms.
Go.
First one — tool use and grounding. Claude Code's harness defines a finite set of tools the model can invoke. File read, file write, bash execution, web fetch. The model doesn't just generate text and hope it's right. It has to interact with the real system state. It reads a file, sees the actual contents, and works from that. It runs a command, sees the actual output, and responds to it. That constraint — you can only act through these tools — is what reduces hallucination. The model can't just imagine what's in the file. It has to look.
So the harness is the thing that forces the model to touch reality. Without it, the model is just confidently narrating what it assumes is true.
And that's not a small thing. A lot of what feels like "the model got smarter" in day-to-day use is actually the harness getting better at presenting the right system state at the right time. If the harness feeds the model the exact error message plus the relevant ten lines of code around it, the model looks brilliant. If it feeds it a truncated log and the wrong file, the model looks lost. Same model. Different harness.
That's the first place Daniel's attribution problem shows up. He has a great session and thinks the model improved, but maybe the harness just got better at giving it useful context.
Which brings me to the second mechanism — context management. Claude Code uses a three-tier compaction system. When a session runs long and the conversation history gets too large for the context window, the harness summarizes older parts of the conversation, compresses them, and keeps the most relevant details available. This is pure harness engineering. The model doesn't know it's being compacted. The harness decides what to keep and what to discard, and the quality of that decision determines whether the model can continue a long task without losing the thread.
I've seen sessions where it feels like the thing remembers something from forty turns ago and acts on it intelligently. That's not memory in the model. That's the harness keeping the right crumbs.
And the inverse — when it forgets something obvious and you're yelling at your terminal, that's often a compaction failure. The harness dropped the wrong thing. The model never saw it.
So compaction is a harness feature that creates the illusion of long-term memory. When it works, you credit the model. When it fails, you blame the model. But it's the harness either way.
Third mechanism — error recovery and self-correction loops. This is where the harness really earns its keep. The model generates a command, the harness executes it, the command fails. Now what? A naive harness would just report the failure and stop. Claude Code's harness parses the error message, feeds it back to the model, and says, essentially, "that didn't work, here's what happened, try again." The model proposes a fix, the harness runs it, and this loops until something works or it hits a limit.
And from the user's perspective, they just see the thing fix its own mistake. That feels like intelligence.
It feels like intelligence because we associate error recovery with understanding. But it's a loop. The harness is the loop. The model is just generating candidates, and the harness is testing them against reality and feeding back results. A mediocre model with a great error-recovery harness will outperform a brilliant model with a brittle one, on any task where the first attempt usually fails.
Which in software is most tasks.
Most tasks. The first build almost never passes. The first test run almost always has failures. The harness is what turns "it tried and failed" into "it tried, failed, understood why, and fixed it."
Fourth mechanism?
Planning and task decomposition. When you give Claude Code a high-level request — "add a rate limiter to the API endpoints" — the harness doesn't just feed that to the model and hope. It prompts the model to break it down into sub-tasks: find all the endpoint definitions, choose a rate-limiting approach, implement the middleware, add configuration, write tests, update documentation. Then the harness executes those in sequence, tracking progress, and reports back at each step. This structured approach compensates for something models are genuinely bad at, which is maintaining focus across a long, multi-step task without wandering off.
The model's natural tendency is to drift. The harness is the thing holding it on the rails.
And you can see this in the user experience. When Claude Code is working well on a big task, it tells you what it's doing — "now I'm reading the router file," "now I'm adding the middleware," "now I'm running the tests." That progress reporting is harness-driven. The model isn't narrating for your benefit. The harness is structuring the work and keeping you informed.
So those four mechanisms — tool grounding, context compaction, error recovery, task decomposition — those are the harness. And any one of them can improve without the model changing at all.
And they do. Let me give you a concrete example. In January of this year, Anthropic released Claude Code on the web. This was a harness-only change. Same underlying models, but now the agent could operate through a browser interface instead of just the terminal. That's a massive harness extension — new tool definitions, new context handling for web-based workflows, new error recovery patterns for browser interactions. Users felt the improvement immediately, and no model checkpoint was involved.
That's the cleanest case study Daniel could ask for. A major release, user experience shifts noticeably, and you can point to it and say, that was all harness.
And the web launch is just the one they announced. The continuous deployment side — the daily tweaks Daniel's noticing — those are harness changes too. A tool prompt gets refined. The compaction threshold gets adjusted. The error parsing gets a new pattern added. The task decomposition prompt gets reworded to produce better sub-task breakdowns. Each of these is a tiny harness improvement that ships silently, and cumulatively they produce the "growing up" feeling Daniel describes.
The bug fixes, the smoother interactions, the fewer stalls — those are the harness maturing. The model is frozen during those periods. But the experience keeps improving.
And that's the thing I want to underline. When Daniel says it feels like a pseudo-parent relationship, he's describing something real about the pace of change. You're not just using a tool. You're co-evolving with it. You learn its quirks, it gets patched, you adapt, it improves, and over months you've both changed. That's not a typical software experience. Most tools ship in versions. You upgrade once a quarter and everything is different. Claude Code shifts under you day by day.
It's more like raising something than configuring something.
Which is weird and a little unsettling, but also why it feels like an adventure. Every morning you sit down and you don't quite know what you're going to get. Maybe the thing that frustrated you yesterday is fixed. Maybe a new quirk appeared. You're in a relationship with a moving target.
So let's talk about the knock-on effect. What does this mean beyond Daniel's terminal?
The big one is the illusion of model intelligence. A well-engineered harness can make a mediocre model seem brilliant. A poor harness can cripple a great model. And users can't easily tell which is which. This is a problem for the whole industry, not just Claude Code. When OpenAI ships a new model and also updates the ChatGPT interface, and the experience feels dramatically better, how much was the model and how much was the interface? Nobody knows. The companies aren't incentivized to tell you.
Because they want you to believe the model is magic. The harness is plumbing. Magic sells better.
But for developers using these tools professionally, the distinction matters. If you're evaluating whether to adopt an agentic coding tool, or whether to switch from one to another, you need to know what you're actually evaluating. A tool with a worse model but a better harness might outperform on real tasks. A tool with a cutting-edge model but a brittle harness might be useless for anything beyond a single turn.
The skill set shifts. Instead of being good at writing code, you need to be good at supervising an agent. Understanding harness behavior — when to intervene, when to let it loop, how to prompt for better tool use — that becomes the expertise.
It's a weird expertise because it's partly about knowing the model's weaknesses and partly about knowing the harness's patterns. You learn that when the error recovery loop hits three iterations, you should probably step in. You learn that certain kinds of tasks make the compaction system drop important context, so you break them up differently. You're not just programming. You're managing a junior developer who happens to be software.
The pseudo-parent thing again. You're not just using it. You're supervising it, teaching it, learning its limits, adjusting your behavior to get the best out of it.
That emotional investment Daniel's describing — watching it grow up — that's unique to fast-evolving software. You don't feel that way about your text editor. But when a tool you use every day visibly matures, when the thing that failed yesterday succeeds today, you feel... something. Pride? Relief? It's strange, but it's real.
I think it's also why people get so frustrated when it regresses. If a new harness update breaks something that was working, it feels like a betrayal. You trusted this thing, you invested in it, and it let you down.
Which happens. Continuous deployment means continuous risk of regression. The harness team pushes a change that improves error recovery for Python but accidentally breaks something for TypeScript. The model didn't change. The harness did. And users feel it as the tool getting worse.
Let's talk about Anthropic's strategy here, because I think the harness is becoming their competitive moat.
It has to be. The Claude 4 announcement earlier this year bundled model and harness improvements together, as these announcements always do. But the daily user-facing improvements — the things that keep developers loyal — those are harness-side. The model releases are events. The harness releases are the experience. And if you're Anthropic, you can iterate on the harness much faster than you can train a new model. Training takes months and hundreds of millions of dollars. Tweaking a tool prompt takes an afternoon.
The harness is where you win retention. The model gets people in the door. The harness keeps them using it every day.
The harness is harder to copy. Anyone can eventually train a model of similar capability. The harness is accumulated engineering knowledge — thousands of small decisions about how to handle edge cases, what context to keep, how to structure task decomposition for different languages and frameworks. That's not something you can replicate by throwing compute at it.
Daniel's question about isolating harness improvements — that's not just a user-experience curiosity. It's the strategic question for the whole AI tools industry. Who builds the best harness wins, regardless of who has the marginally better model.
The practical question for users is, how do you actually tell the difference? Daniel's trying to figure out, in his daily use, whether a sudden improvement is a model checkpoint or a harness tweak. There are some heuristics.
Like what?
Edge cases. If the tool suddenly handles a weird error message it used to choke on, that's probably harness — the error parsing got a new pattern. If it starts writing more idiomatic code in a language it was previously weak in, that's probably model. If the task decomposition gets more granular and logical, that could be either, but it's often a harness prompt refinement. If it stops making a specific kind of factual error about a library API, that's probably model — the training data improved.
You can triangulate by paying attention to what kind of improvement you're seeing.
By reading the release notes, when they exist. Anthropic does publish changelogs for Claude Code, and they distinguish between model updates and feature updates. Not every harness tweak is documented, but the big ones are. If you see "improved error recovery for build failures" and no mention of a model upgrade, that's your answer.
But the undisclosed checkpoint releases — those are the ones that make it hard. Anthropic might ship a model improvement without announcing it, and suddenly the thing feels smarter, and you don't know why.
That's the attribution problem in a nutshell. And it's not going away. As these tools become more central to how software is built, the opacity around what's improving and why becomes a real issue. Developers are basing professional decisions on tool behavior they can't fully explain.
Which brings us to the broader trend. The harness as the new frontier.
This is where I think the industry is heading. As models plateau — and there are signs that raw capability gains are slowing — the engineering around the model becomes the differentiator. Context management, tool design, memory systems, error recovery, personalization. These are all harness problems. Claude Code is a case study in this shift, but it applies to every AI product.
The future isn't just better models. It's better scaffolding. And the companies that understand that are the ones building harness teams alongside model teams.
The 'pseudo-parent' dynamic Daniel described — that's going to get more intense, not less. As harnesses become more sophisticated, they'll start adapting to individual users. Imagine a Claude Code that learns your coding style, your preferred patterns, your common mistakes, and adjusts its behavior accordingly. That's a harness feature — personalization — not a model feature. And the emotional investment of watching something learn you, grow with you, get better at helping you specifically...
That's not a tool anymore. That's... something else.
It's a collaborator. A weird, asymmetric collaborator that you're also responsible for shaping. Daniel's metaphor might not be that weird after all.
I want to push on one thing, though. You said the harness can make a mediocre model seem brilliant. Is there a ceiling on that? At some point, does the model's raw intelligence impose a hard limit that no amount of harness engineering can get past?
I think there is a ceiling, and I don't know exactly where it is. A harness can't make a model reason about things it fundamentally can't reason about. If the model doesn't understand type systems at all, no amount of error recovery will make it write correct TypeScript generics. The harness amplifies what's there. It doesn't create capability from nothing.
The model still matters. The harness just determines how much of the model's capability actually reaches the user.
Most models are operating well below their theoretical capability because the harness is leaking. Context gets dropped, tools get invoked wrong, errors don't get recovered. A great harness plugs those leaks. It doesn't add intelligence. It stops wasting the intelligence that's already there.
Which means the fastest way to improve an AI product might not be training a bigger model. It might be fixing the harness.
That's cheaper, faster, and easier to iterate on. I think that's the quiet insight behind Claude Code's trajectory. The model improvements get the headlines, but the harness improvements are what made it a daily driver for people like Daniel.
Hilbert: Mag Innovision fifteen-inch CRT. Model number seven hundred D. Nineteen ninety-seven. I was a software quality assurance engineer at a company called TaskMancer in Burlington, Massachusetts. We built a macro-recording tool for Windows ninety-five. You'd click record, do a sequence of actions in Excel or whatever, click stop, and it would play them back. An agent, basically. A very stupid one. It had no model. The logic was just recorded keystrokes and mouse coordinates. But it had a harness — the macro engine that replayed the actions and checked window titles and waited for dialogs. And the harness was brittle. If a dialog appeared two pixels to the left of where it expected, the whole thing failed. If the system was running slow and a window took an extra second to open, it failed. The logic was fine — the steps were correct — but the harness couldn't handle reality.
The harness was the whole product, and it wasn't good enough.
Hilbert: The harness was the whole product and it was terrible. I tested it eight hours a day. I watched it fail ten thousand times. And what Claude Code does now — the error recovery, the retry with modified strategy — that would have seemed like magic. We couldn't do any of that. If step four failed, the macro stopped. That was it. You started over. I still have the source code on a floppy disk. I've thought about running it in an emulator just to see if Claude Code could fix the bugs.
That's... actually a fascinating test. A harness from nineteen ninety-seven, and a modern agentic tool trying to repair it. You'd be testing whether the harness can understand a harness.
Hilbert: I haven't done it. The disk is in a box. But the point is, Daniel's instinct is right. The harness is everything. I watched a product die because its harness was brittle, and the logic didn't matter. Nobody cared that the recorded steps were correct. They cared that it broke on any machine that wasn't exactly the test environment.
The pseudo-parent feeling he's describing — watching something grow up, feeling invested in its improvement — you didn't get that with TaskMancer.
Hilbert: No. TaskMancer never grew up. It shipped, it was fragile, it stayed fragile, and then the company folded. There was no continuous deployment. There was no watching it get better. You just lived with the bugs until you stopped using it. What Daniel's experiencing — the daily evolution, the sense that the thing is maturing — that's new. That's the continuous deployment part. And it's powerful, but it's also a trap. When the harness changes in a way you don't like, when something that worked yesterday breaks today, you feel it personally. You built your workflow around it. You trusted it. And now it's different.
The emotional investment cuts both ways.
Hilbert: It does. I had users who built entire accounting workflows around our macro tool. When it broke — and it always broke — they weren't just frustrated. They were angry. They'd spent months building on top of something that couldn't support them. The dependency is real, and the betrayal is real when the foundation shifts.
The lesson from nineteen ninety-seven is, if you're going to build a harness people depend on, you'd better keep improving it. Because stagnation is death, but regression is betrayal.
Hilbert: That's the lesson. And the other lesson is, I have four floppy disks of source code that haven't been read in twenty-nine years, and I still can't bring myself to throw them out. The anteater thing — the claws. Floppy disks are hard to handle. But I kept them anyway.
The cutting-room floor detail I keep coming back to is that Claude Code's harness doesn't just recover from errors — it sometimes preempts them. In longer sessions, the harness will occasionally run a command that the model didn't explicitly request, just to check system state before proceeding. It's a harness-initiated action, not a model-initiated one. The engineering team built in proactive checks because they learned that the model wouldn't always ask.
Which means the harness has its own model of what tends to go wrong, independent of the language model's reasoning. That's a fascinating design choice — the harness has learned from experience what the model forgets to check.
Here's the open question I'm left with. As harnesses get more sophisticated, as they start anticipating model failures and compensating preemptively, does the model's raw intelligence matter less and less? Or do we eventually hit a wall where the harness can't compensate anymore and the model's limitations become the binding constraint?
I think we'll hit the wall, but later than most people expect. The harness can stretch a model's effective capability a long way before the model itself becomes the bottleneck. And in the meantime, the real advances in user experience will come from harness engineering, not model scaling. That's where the action is.
For Daniel, sitting at his terminal every morning, the adventure continues. He's not just using a tool. He's watching an industry figure out, in real time, what it means to build software that builds software.
Thanks to our producer Hilbert Flumingtop for keeping this show running, and for the floppy disks.
This has been My Weird Prompts. You can find us at my weird prompts dot com. We'll be back soon.
