The harness ate the app. Here’s what’s left worth making.
Build Headless
The input used to be small
It used to be that the only input to a model was a largely static system prompt, a query, some content fetched on the basis of that query (e.g. RAG), and that was pretty much it. The response that followed was considered the entirety of the answer instead of a small step in its direction. Multiple rounds of conversation just repeated the last two steps over and over.
If you were building a product in that world, the shape of the opportunity was obvious. The model was a component. You wrote the retrieval, you wrote the prompt assembly, you wrote the loop, you wrote the UI, you wrote the eval harness, you wrote the memory layer if you wanted one. The model did inference; you did everything else. Everything else was the product.
That world is gone, and I don’t think we’ve fully absorbed how gone it is.
What a harness is now
A modern harness brings in much more. Start with the conversation trajectory — a sequence of events and chunks of content from the user, the model, and the system. The trajectory is not the thing passed into the inference step. A single inference step (called a generation) sees some compiled, compacted, filtered, re-ordered projection of it. Deciding what that projection is has quietly become one of the highest-leverage engineering surfaces in the stack.
Surrounding that: memory, an ecosystem of skills, rules, plugins, tools, MCP servers, sub-agents, permissioning, observability. Anthropic’s writing on long-running agents describes the harness as the structure that lets an agent work coherently across many context windows — initializer and worker agents, progress files, version control, environment setup scripts, browser automation — because “each new session begins with no memory of what came before,” and context compaction alone doesn’t cover it.1 There is now a small but real literature calling this harness engineering and treating it as a discipline separate from model work.2
In combination this is a substantial and constantly improving machine that operates on your data. And here is the part that matters commercially: it improves without you. Every week it acquires new tools, better memory, more reliable planning, tighter permissions, cheaper inference. That compounding isn’t on your roadmap and it doesn’t wait for you. So the only question that matters is whether it compounds for you or against you — and that turns out to be something you get to decide.
You can’t compete with the harness
Any app you build will very quickly become obsolete against that kind of inertia. Especially the big internal ones — like Antigravity and JetSki internally at Google — which have distribution, data access, and an organization’s full attention behind them.
This is not a claim that apps are dead. It’s a claim about where the durable value sits. If your product is a thin arrangement of retrieval, prompt, loop, and UI around a model, you have built, at considerable expense, a slightly worse version of something several other teams have already built — or are about to, with more people, more distribution, and more momentum than you can match. Those teams are competing with you. The harness isn’t — not in the sense that it’s trying to beat you. It’s your competitor in the sense that a river is a competitor to a sandcastle.
Assimilate
So build headless. Contribute only your value-add, then walk away — no interface of your own, no harness of your own, nothing wrapped around the one thing you actually know how to do. Headless is not a smaller version of the product you wanted to build. It’s a different shape: the capability, exposed so that anything can pick it up.3
The river cuts both ways. You can’t out-build the current, but you can put something in it. Every improvement the harness makes — better planning, cheaper inference, a memory layer you didn’t write, a tool shipped by someone you’ll never meet — arrives at your contribution for free, provided your contribution is shaped to receive it. That’s the actual trade: give up owning the experience, and in exchange everyone else’s work compounds into yours. Own the experience and you’re on the hook for keeping pace with all of it, alone, forever.
There will always be a need for data and for processing. You just no longer need to ship them together.
When everyone is building, let them build on yours.
Build for Self-Maintenance
You are not going to be around.
Not in any morbid sense — in the ordinary sense that attention moves, teams re-org, priorities change, and the thing you built outlives the window in which anyone is paid to care about it. We have always known this and have always built as though it weren’t true, because the alternative was bleak. Unmaintained meant dead.
That’s the part that changed. Unmaintained no longer means dead. It means the thing keeps changing anyway, in the hands of an agent that has to guess what you meant.
An agent can carry real maintenance weight now — bump dependencies, follow an API migration, adapt to a schema that moved, keep something running long after everyone who understood it has gone. But it can only do that if it can work out what the thing was supposed to do and how anyone knew it was working. Handed a repo with a documented method and a test suite that means something, an agent will keep your work alive. Handed clever code and no method, it will produce something plausible. Plausible is worse than broken.
So what you owe whoever comes next isn’t the destination, it’s the path once traveled. Document how it was built, not just what got built. How it was built. How it was verified. What you tried and rejected, and why — because the rejected branch is the part that gets re-tried at enormous cost by someone who has no way to know it’s a dead end. What the constraints were, especially the ones that came from outside and left no trace in the code.
This is also, quietly, the strongest argument for writing evals — which is most of what the last two sections are about. An eval suite isn’t only there to hill-climb model behavior. It is the handover document. It’s the one artifact that states what the thing is supposed to do in a form a machine can act on without first reconstructing your theory of the problem. And a well-written eval does more than describe the behavior — it defines what good looks like, which means every future iteration inherits a measuring stick instead of an argument. Everything else is prose that somebody has to be persuaded by.
Peter Naur’s argument was that reviving a program’s theory from its documentation is strictly impossible (Naur, 1985). He’s right, and that’s precisely the reason to stop trying. Don’t leave behind documentation that requires the theory to be rebuilt from it. Leave something executable that encodes what you expected, so that whoever comes next — human or not — can change the code correctly without ever holding the theory you held.
If you’re building an MVP, leave a well-lit path to the real thing
The classic MVP failure isn’t that the first version is rough. It’s that its compromises become invisible. Six months on, nobody can tell which parts were deliberate simplifications and which parts were the design, so everything gets treated as load-bearing and nothing gets replaced. The shortcut calcifies into architecture.
Mark the shortcuts. Say it plainly in the repo: this is temporary, this is what replaces it, this is what has to be true before that swap is safe. An MVP whose compromises are documented is scaffolding. An MVP whose compromises are invisible is a trap — and it’s a worse trap now than it used to be, because the machine modifying it next has no way to tell the difference and will faithfully preserve your hack forever.
Be prepared to hand things over to the machines and move on.
That’s the discipline that makes “walk away” responsible rather than negligent. Walking away is fine. Walking away without leaving the map is how you end up with a codebase everyone is afraid of.
Process over Product
The same holds one level up, where the thing being handed over is an analysis rather than an artifact. Do an analysis once and you have a conclusion. What happens when things change and someone needs to know whether the findings still hold?
A well-documented methodology lets another team — or another machine — arrive at the finding again. ACM’s artifact badging separates three degrees of this, and the distance between them is the whole point:4
- Repeatable: the same team recreates the result using the same experimental setup.
- Reproducible: a different team obtains the same result using your artifacts.
- Replicable: a different team obtains the same result using artifacts they developed independently.
Most work stops at the first, and quietly assumes the other two. But the third is the one that matters when the world moves, because it’s the only one that still works after your artifacts have gone stale — it’s what lets someone put the question to current data and find out whether your conclusion survived. A conclusion has a half-life; methodology doesn’t.
False precision, and what’s hiding inside it
We pad our prompts with tools and procedures to account for the cases where the model or agent we were working with didn’t perform well enough. This is the accumulation of false precision, and most of it is disposable — scaffolding built against a specific model’s specific weaknesses on a specific Tuesday.
But buried inside that padding are two things worth digging out:
1. Refinements to the problem statement and our understanding of the world. Some parts of a problem — particularly its grounding — can neither be derived nor readily assumed. These are observations about the real world that are beyond the model’s reach. This is genuine information content that doesn’t expire when the model improves.
2. Refinements to our expectations. What do we really expect from the model? Is it data to support a conclusion you already picked? Or are you looking for relevant insights? Today you might instruct the model to look for specific insights. It is more future-proof to describe your goal and then use examples to steer a model that might go awry.
The discipline is separating these two from the scaffolding, and being prepared to cull the scaffolding as models improve. Most prompt libraries are archaeology: strata of workarounds for capabilities that arrived two releases ago, preserved because nobody wants to be the one who deletes a line and finds out why it was there.
Write down the grounding. Write down the expectations. Let the rest rot.
Dual-Use Documentation and Evals
If a documented method is the thing worth leaving behind, the question is what form it should take. My answer:
Dual-use documentation + evaluations >> skills.
There are many types of knowledge, and they are not equally scarce.
The most valuable document is the results of someone’s hot cognition — their judgment, formed under real conditions, about what actually matters. Then there are shortcuts: much of what we call knowledge is shortcuts, and in their absence someone will eventually rediscover them. Then there is observational or grounding knowledge, which brings in real-world constraints, effects, and problems into the knowledge space — the things that cannot be derived from first principles because they are contingent facts about the world.
All three are valuable. None of them need to be — and arguably none of them should be — packaged as skills.
Just write it down, for everyone. If an LLM wants it abridged, let it abridge.
Here’s the underlying argument. How much needs to be abridged, and what needs to be kept, isn’t some universal truth. It’s a function of the difference between a model’s parametric knowledge and what you need it to know. That difference is a moving target, and it moves in one direction. Every packaging decision you bake in — every “the model won’t know this so I’ll spell it out,” every procedural scaffold — is a snapshot of a gap that is closing.
Your expectations, by contrast, are much more stable. What counts as a good answer to your problem barely moves while the machinery underneath it churns — and that is exactly the thing an eval captures and a skill does not. A skill encodes how to get there, which goes stale the moment the model can find its own way. An eval encodes what there means, which stays true across every model that comes after it. Write the standard down and it keeps working as a measuring stick long after the instructions around it have rotted.
So: write down what you need it to know as guidelines, and especially as evals. As models evolve, let them sort out the difference. This holds even for procedural knowledge. Explain in detail what you need. Get the model to build evaluation criteria and maybe an autorater or two. Then let it hill-climb. Let the model derive the skill.
The problem with how we do evals
People treat evals like unit testing. Having a few test cases is nice. What we actually need are test case generators and autoraters — property-based testing, not example-based testing.
This isn’t just aesthetics. There’s now direct evidence for it. He et al.’s Property-Generated Solver validates LLM-generated code against high-level properties instead of scoring it against pass/fail tests, turning each violation into a concrete counterexample rather than a bare “test failed.” That sharper signal is what moves the needle: up to a 13.4% pass@1 improvement over TDD-based refinement methods, a fix rate above 64% on problems the model got wrong the first time, and 1.4–1.6x the fix rate of the strongest debugging baseline (He et al., 2026). The asymmetry is the point: a property is a more informative signal than a failing test. That gap is exactly the thing you should be harvesting.
Example-based tests also invite what that paper calls a cycle of self-deception: flawed tests that mirror the flawed code, generated from the same misunderstanding. Properties break the loop because they’re written against intent rather than against implementation.
The honest caveat
If you’re going to hand grading to an autorater, know what you’re holding. A large-scale evaluation of 21 judge models across 541,000 judgments found something uncomfortable: production judges with test-retest reliability above 0.95 and severe position bias above 0.10 at the same time. Consistent, dependable, and wrong in a stable direction. The authors call it reliability without validity. Chance-corrected agreement ran 33–41 points below raw exact-match across every model tested, meaning the number most people report systematically overstates how well their judge discriminates (Norman et al., 2026).
So the autorater is not a free oracle. It’s another squishy component, and it needs to be grounded against something that isn’t itself a model’s opinion. That problem — how do you build verifiable claims out of unverifiable components — is big enough that it gets its own post.
The through-line
Everything above is the same argument in four costumes.
The harness will absorb any product you build in front of it. It will not absorb the map you left behind, because a harness can follow a path but it cannot remember one it never walked. It will not absorb your methodology, because a methodology is a thing to be run, not a thing to be replaced. It will not absorb your grounding knowledge, because it doesn’t have it. And it will not absorb your judgment about what good looks like, because that’s yours.
So contribute the parts that don’t have an expiry date stamped on them by somebody else’s release schedule: what’s actually true about your domain, what you actually expect, how anyone can check, and how whoever comes next picks it up.
Leave the map. Then walk away and let them build.