When a team hits a ceiling with their coding agent, the first instinct is to reach for a better model. The reasoning feels obvious: the model is the part that produces the code, the code is the part that is wrong, therefore a smarter model will produce more correct code. Wait for the next release. Switch providers. Bump the tier.
This is sometimes right. It is much more often wrong, and the cost of being wrong about it is that you spend months waiting for a model upgrade to solve a problem the model was never the cause of.
The harness is the cause of the problem more often than the model. Most teams discover this only after they have exhausted the model-upgrade reflex and finally turn to look at everything else.
What a model upgrade actually buys you
Newer, stronger models do tangibly improve some things. They handle longer contexts more reliably. They make fewer simple reasoning errors on complex tasks. They follow nuanced instructions more closely. On a fixed prompt, with a fixed task, a better model produces a better answer.
What model upgrades do not change:
The fact that the agent has no idea your team prefers functional components over class components, because the convention is not in any file the agent reads.
The fact that your tests do not actually fail when the code is wrong, so the agent can ship broken code that passes CI.
The fact that your codebase has three different ways of handling errors and the agent picks one at random on each PR.
The fact that the rule the senior engineer keeps repeating in reviews is not encoded anywhere the next session can see.
None of these are fixed by a smarter model. They are fixed by a better harness. A smarter model loaded into the same broken harness will produce slightly more sophisticated versions of the same problems.
The diagnostic
The diagnostic is one question: when the agent fails, does it fail because it lacked information, or because it lacked capability?
A capability failure looks like: the task required reasoning the model could not do. The math was wrong. The algorithm was subtly broken in a way that required deep understanding. The bug fix required tracing through five layers of indirection and holding it all in mind at once.
An information failure looks like: the agent did something a senior engineer on the team would have done differently, and the difference is not about thinking harder, it is about knowing the team's conventions, the codebase's quirks, the unwritten rules, the things the team learned the hard way three years ago.
Information failures are the overwhelming majority of agent failures in production teams. They look like capability failures because they manifest as wrong code. But the wrong code is wrong because of missing context, not missing intelligence.
A capability failure does not improve when you give the agent more context. An information failure improves dramatically. The test is to put the missing context into the prompt (directly, by hand) and see if the agent gets it right. If yes, the harness is the bottleneck. If no, the model might genuinely be limiting.
In practice, when teams run this test honestly, the answer is usually "the agent could have gotten this right; the context just was not there." That is a harness problem with the model's name on it.
Where to spend the time instead
If you have a backlog of "the agent keeps doing X wrong" complaints, model upgrades are not where to spend the next hour. The high-leverage moves are mostly boring:
Read your rules file and ask whether each entry actually changes the agent's behavior. Delete the ones that do not. Add the rules you have been repeating in code review.
Run the agent on a task you know it has historically struggled with, and watch what it loads into context. If it is not reading the file that would tell it the answer, the file is not in its priors. Fix the priors.
Look at the last ten PRs that produced reviewer comments. For each one, ask: was this a missing rule, a missing test, or a genuinely hard problem? Most of them will be one of the first two.
Pick the single most-repeated reviewer complaint from the last month and either turn it into a rule, a lint, or a test. One of those three is almost always achievable in an afternoon.
None of these are glamorous. None of them require waiting for a new model release. All of them compound.
When a model upgrade actually helps
There is a legitimate case for model upgrades, and it is worth naming so the argument is not taken too far.
If your team has done the harness work (the rules are tight, the sensors are sharp, the conventions are encoded) and the remaining failures are genuinely about reasoning depth, then yes, a stronger model is the next move. Long agentic tasks, complex refactors, problems that require holding more context coherently in mind, multi-step debugging — these are where capability differences between models show up.
But the prerequisite is having done the harness work first. A team that has not won't be able to tell whether a model upgrade helped or not, because the noise from harness problems will dominate any signal from the model change. A team that has will see model upgrades produce specific, measurable gains on specific categories of task.
The order matters. Harness first. Model second.
The cost of the reflex
The reason this is worth being firm about: the model-upgrade reflex is expensive even when it does not work. Each upgrade attempt costs onboarding time, prompt tuning, billing changes, and team confidence when the upgrade fails to deliver the hoped-for improvement. Teams that go through the cycle two or three times start to believe the technology itself is not ready, when what is not ready is their own harness.
Meanwhile, every hour spent waiting for a better model is an hour not spent encoding the team's hard-won knowledge into a file the current model could already read. The opportunity cost of the reflex is the harness investment you did not make.
The model is the part of the system everyone talks about. The harness is the part of the system that determines whether the model can do useful work in your codebase. Most teams underestimate the second one by a factor of ten. Stop upgrading. Start engineering.
