What is a harness?
An AI model on its own is an engine sitting on a workbench. It runs, it makes noise, but it doesn't take you anywhere.
The harness is everything you build around it to turn it into a car: the instructions you give it, the tools it can use, the context files it reads at startup, the tests that check its work, the rules about what it's allowed to touch.
When you use Claude Code or Codex, part of that harness comes with the tool. The other part is yours to build: your CLAUDE.md, your instructions, your tests, the way you split up the work. If the word "agent" doesn't mean much to you yet, start with the agentic coding guide.
The term took off in spring 2026 as harness engineering, the craft of building that environment well. And almost at the same time, another idea started going around: models are getting so good that all of this will soon be pointless.
The temptation: throw it all out
The argument is appealing, and it isn't wrong. Every model generation has made some of the previous generation's tricks obsolete.
AI researchers have a name for this: the bitter lesson. Rich Sutton put it into words in 2019: over time, methods that lean on computing power end up beating methods that lean on human cleverness. The clever setups we build to help a model are often swept away by the next one.
My take: models make half of the harness useless. And they make the other half more important than ever. The whole point is knowing which half is which.
The half models have already eaten
Everything that existed to compensate for the model's weaknesses goes away as those weaknesses go away.
Magic phrases. "You are a senior developer with 20 years of experience." "Think step by step." "This is very important for my career." In 2023, these lines really did improve answers. Today, models reason before answering without being asked. These phrases cost nothing, but they no longer bring anything either.
Giant rules files. The 2,000-line "rules" packs copied from a forum, explaining to the model how to write a React component or name a variable. A current model already knows how. Better: it reads the rest of your code and works out your conventions on its own.
Splitting everything into tiny steps. Two years ago, you had to break every task into micro-steps, or the model would lose the thread halfway. Today's agents make their own plan, keep a task list and come back to it.
Homemade multi-agent setups. An "architect" agent, a "developer" agent, a "tester" agent passing work along through hacked-together scripts. The tools now build this in, and a single well-briefed agent often does better than the chain.
Repeating yourself in every message. Models hold far more context, and the tools know how to summarize it when it overflows. You no longer need to paste your database schema into every request.
What they have in common: these were training wheels on a bike. The model has learned to keep its balance, so they can come off.
The half that gains value
The other half of the harness doesn't make up for a weakness in the model. It provides what the model cannot know, however powerful it gets.
Your business context. The model doesn't know your customers are pharmacies, that a refund must be approved by a human, or that you dropped annual plans last year because they caused too many disputes. None of that is written anywhere in your code. A model ten times smarter won't guess it any better.
Your definition of "it works." An agent stops when it thinks it's done. If no test proves otherwise, it's right from where it stands. Tests are how you write down, in black and white, what has to work: a customer can pay, a user can't see another user's data, an invoice actually goes out. The agent can write those tests. It can't decide which ones matter to your business.
Automatic checks. CI (continuous integration: a robot that reruns every test on each change and blocks it if something breaks) isn't there for today's change. It's there for next Tuesday's, which will quietly break what worked the week before.
Guardrails. What the agent is allowed to touch: not the production database keys, not the payment settings without review, no deleting data without a backup. A more powerful model makes fewer mistakes, but the ones it makes travel faster and further.
Eyes on production. The agent can't see what's happening for your users. If nobody shows it the errors, it keeps improving an app that crashes for half your customers.
Back to the car: an engine twice as powerful doesn't make the brakes useless, it makes them essential. And it still doesn't know where you want to go.
| What makes up for a model weakness | What provides what the model doesn't know | |
|---|---|---|
| Examples | Magic phrases, generic rules, micro-steps, agent chains | Business context, tests on critical flows, CI, access rights, alerts |
| With a better model | Becomes useless, sometimes harmful | Gains value |
| Who has to write it | Soon, nobody | You, or someone who knows your product |
The stronger the model, the more checking matters
This is the least intuitive part. A stronger model produces more code, faster, with fewer visible mistakes. As a result, you review less, you trust more, and you let bigger changes through.
The mistakes that remain are also the quietest. AI often nails the hard part and misses the obvious: a forgotten access rule, a payment counted twice, a webhook failing silently. The code is clean, the app seems to work, and the problem shows up three weeks later.
When your agent wrote 50 lines a day, you could review all of it. When it writes 5,000, only tests and CI can keep up.
The trap: throwing out both halves at once
There are two mirror-image mistakes.
Keeping everything, out of fear. Your instructions file has grown since 2024. It contains rules written for a model that no longer exists: "always use this version of that library," "never change more than three files at once." The current model follows them to the letter, and they hold it back. Outdated instructions aren't neutral.
Throwing everything out, out of excitement. "The new model is amazing, no need for tests anymore." That's taking the brakes off because the car accelerates better. As long as everything goes well, you won't notice the difference.
The right move is to sort.
The big cleanup: a 15-minute checklist
Open your CLAUDE.md (or AGENTS.md, or your Cursor rules) and run each line through one question: could the model figure this out by reading my code?
- Yes: delete it. Naming conventions, a description of the stack, how to write a component, the "be rigorous" and "think carefully."
- No: keep it, and make it precise. What your product does and for whom, past decisions and why they were made, what's forbidden, sensitive areas such as payments or personal data.
Then check what surrounds the agent:
- Do the 3 flows your business runs on have tests? Usually: sign-up, payment, access to a customer's data.
- Do those tests run automatically on every change, or only when someone remembers?
- Does your agent have access to production? If so, take that access away and have it work on a copy.
- Are your backups tested? A backup you've never restored is still a hypothesis.
- Does someone review changes to authentication and payments before they go live?
- Do you know when your app crashes for a user without them having to email you?
If you answer no to more than two of these, the power of your model is not what's holding you back.
So, is the harness doomed?
The part of the harness that told the model how to work is disappearing, and that's good news. You have fewer prompts to write and fewer recipes to follow.
The part that says what matters, what's forbidden and how to tell if it worked won't disappear. It's the spec, the quality control and the insurance. It doesn't depend on how smart the model is, it depends on your product.
I'd even say this is where the difference between two apps built with the same model will be decided. They have access to the same intelligence. What sets them apart is what was built around it. It's also why agents don't replace the people who know how to frame them.
Want a solid harness around your app?
I set up the half that won't disappear: tests on your critical flows, CI that blocks before things break, scoped access and a context file that speaks about your business. If your app already exists, a code audit tells you what's missing. If you'd rather hand your product over, see the offer or let's talk about your project.
For more articles on building products with AI, subscribe to the newsletter.
