Last winter a company I worked with spent the better part of a quarter building one clever piece of automation. The AI tool they had adopted kept losing the thread on long documents, so the team wrapped it in scaffolding: a chain of prompts that chopped each document into pieces, summarised each piece, stitched the summaries back together, and re-fed them so the model would not forget the opening by the time it reached the end. It worked. It also took two capable people most of the quarter. Then the vendor shipped a new model with a far larger memory, and the whole apparatus became dead weight almost overnight. The chopping, the stitching, the re-feeding now sat between the team and a model that needed none of it.
It is tempting to file that under bad timing. It’s not bad timing. It is the central fact of building anything on AI right now, and once you see it clearly it changes what you should spend money on.
The ground only moves in one direction
Nobody in this field is building on stable ground, and it is worth being honest with yourself about that before you write the cheque. Hugo Bowne-Anderson, an independent data and AI consultant who hosts Vanishing Gradients, a long-running podcast for people who build with AI, took stock of the middle of 2026 and counted, inside four months: one lab shipping a model with a million-token memory, an open model pushing further into long multi-step jobs, another arriving with native vision. That, he wrote, “amounts to more than benchmark churn.” The pattern under the releases is consistent. Models keep getting better at holding large amounts of information together, at using tools, and at doing work that used to require scaffolding built around them.
The direction matters more than the speed. Capability keeps climbing into the model, and as it does it swallows the machinery people build around the outside to prop it up. The industry’s word for that outer machinery is the harness. “As those capabilities move into the models,” Bowne-Anderson wrote, “the boundary around the harness moves with them.” Planning that used to need custom logic can now happen inside the model. A bigger memory changes how much external stitching you need. Better tool use “can make yesterday’s orchestration code unnecessary or actively get in the way.”
Read that last clause twice, because it is the part that catches leaders out. The scaffolding you build to compensate for what today’s model cannot do has a shelf life, and the clock on it is the next model release. Sometimes it does not merely expire. Sometimes it turns into a liability that slows the better model down.
Watch the people who live at the sharp end
The clearest place to see this is among the teams whose entire product is scaffolding around a model: the companies making AI coding tools. They feel every model release first and hardest, so their behaviour is a useful early warning for everyone downstream.
Take Amp, a coding tool from the software company Sourcegraph. Nicolay Gerold, who builds it, describes the operating discipline without any romance: “We constantly throw away large chunks of the code base.” Every major model release forces his team to ask what still belongs in the product, what the model can now handle by itself, and which of their own features to delete.
The cleanest example is a feature they called Handoff. They built it because the summarising trick their tool used to survive long sessions kept losing the plot. Then that stopped being the binding problem, and the reason the feature existed had moved inside the model. So they deleted Handoff. Keeping it would only have put friction between the customer and a model that no longer needed the help.
This is not one company’s quirk. When Amp announced it was shutting down its own editor plug-ins, it wrote the general rule down: the agent (in their words, “the prompts and tools you wrap around a model”) “is no longer the limiting factor.” What decides the outcome now, they argued, is how you organise your codebase for agents and how your organisation uses them: “those are now the bottlenecks.” Their promise to customers had shrunk to one line: “when the frontier moved, we would move too.” And they stopped describing the product as a fixed thing at all. “It’s no longer a point on a map. It’s an arrow.”
Every model release raises the waterline. Anything you built to compensate for a weakness sinks below it and gets absorbed; the investments that are about your own business stay above it and are worth more, not less, once the model improves.
There is a sharper version of the liability point, and it comes with receipts. OpenAI’s own engineers found that the automatic summarising their coding tool used to manage long sessions had been quietly degrading its performance: summaries of summaries distorted the model’s earlier reasoning. That finding reaches the outside world through a write-up of the team’s internal report rather than through a paper, so read it as a strong signal from one engineering team, not as a measured industry result. Use of the trick more than doubled over a single month while it was doing that damage. One of Amp’s engineers put the lesson bluntly: you should basically never use that particular workaround. The scaffolding built to help the model had started to hurt it.
Durable versus disposable
If the ground only moves in one direction, the useful question stops being “which model should we pick.” That answer expires on a schedule. The question worth asking is: which of the things you could build will still be worth having after the next three model releases?
Gerold offers a test that translates cleanly out of coding and into any AI project. For every piece you are tempted to build around a model, ask whether it helps you inspect, verify, recover, or merge the model’s work — or whether it is “just babysitting yesterday’s model.” Put in the plainest business terms: does this investment get more valuable as the models improve, or does it get deleted?
The disposable pile is everything whose only job is to compensate for a current weakness. Prompt-chain gymnastics. Orchestration glue: the custom code that stitches the model through a fixed sequence of steps and tools. The elaborate workflow that exists purely because the model could not yet be trusted to do the whole thing in one pass. The better the model gets, the less any of it earns its keep. My client’s document-stitching machine was pure disposable. So was Amp’s Handoff.
One fashionable item belongs squarely in this pile, and it is worth naming because it gets expensive fast: the practice of letting a model run in long automated loops, grading and rewriting its own work for hours. Gerold, who does this for a living, calls the practice overrated outside a handful of genuine cases. He flags a second cost that travels with the same habit: hundreds of parallel agent threads, and a team’s attention fragmented across all of them. A loop the model soon outgrows is a loop you maintained for nothing, and one nobody had the attention left to check.
The durable pile is different in kind. These are the investments that get better as the model improves, because they are about your business rather than about the model’s shortcomings.
- How you know it is working, and how you catch it when it is wrong. Evaluation is the boring investment that compounds. A stronger model makes more decisions, faster, which means the cost of a silent mistake climbs rather than falls, and the checking layer that catches it becomes worth more, not less. The people building with this technology keep writing the same sentence in different words: two of the conversations doing the rounds alongside Bowne-Anderson’s essay are titled Stop Shipping AI Nobody Can Verify and The Verification Crisis: Why Trust Is the New Bottleneck in AI.
- Your own data and the encoded knowledge of how your business actually runs. The model is a commodity that every one of your competitors can rent by the month. A clean, well-organised record of your processes, your cases, and your judgement is not.
- Guardrails and governance: the settled rules about what a system is allowed to touch and what must have a person in front of it before it acts. In a regulated firm these matter more as the model is trusted with more, not less. A guardrail that sits in front of the decision, rather than a report that explains afterwards what the system did, survives every model upgrade, because it encodes your risk appetite rather than the model’s shortcomings.
- Taste and judgement: knowing when to take the keyboard back, and knowing when a plain, predictable rule beats an AI step altogether. This is the human layer that a better model raises the value of, because it decides where the better model is pointed.
- The organisational capacity to keep moving. Being an arrow rather than a point is not a slogan; it is the difference between a team that treats each model release as an upgrade and one that treats it as a crisis.
The one question that sorts a durable investment from a disposable one, and the three decisions it points to.
What this means for your bets
Three moves fall out of all this for anyone deciding what to commission, what to buy, and what to leave alone for now.
Build and own the durable layer. Evaluation, your own data, your governance, and your team’s ability to adopt new tools quickly. These are the parts a vendor cannot sell you and the next model cannot delete, which is exactly why they are worth your own money and attention.
Buy or rent the disposable layer, and expect to swap it. The model, and most of the tooling wrapped around it, is replaceable by design. Don’t marry a supplier’s scaffolding, and don’t build a two-year plan on this quarter’s model’s weaknesses. If a pitch is mostly clever workarounds for current limitations, you’re being offered a depreciating asset. Price it as one and keep your exit cheap.
Wait on anything whose only job is to patch a gap the roadmap will close. Before funding a build, borrow Bowne-Anderson’s three questions for cutting through a feature list: what must this actually do, what must it remember, and what happens if it is wrong? Most of the elaborate machinery teams reach for exists to answer the middle question the hard way, and a bigger model tends to answer it for free within a release or two. If the honest answer to “what do we lose if the next model makes this unnecessary?” is “a quarter of engineering time,” that is a reason to wait, not a reason to build.
None of this is an argument for waiting until the dust settles. The dust isn’t going to settle; the four-month stretch above is the new normal, not a spike. The companies getting real value from AI are not the ones who bet on the right model. They are the ones who built the durable layer (the evaluation, the clean data, the guardrails, the judgement) and stayed deliberately light on everything else, so that each new model made them stronger instead of forcing a rebuild.
This piece is only about where the money should go. If the question you actually have is how to make an individual agent survive real work, that is a different piece and a different altitude. So is the four production disciplines a healthcare agent deployment needs, and so is the anatomy of the harness itself .
If you want the primary source rather than my reading of it, Bowne-Anderson publishes the podcast and his essays at hugobowne.substack.com, puts the episodes on YouTube, and teaches the practice directly — Building AI Applications from First Principles and Master Agentic Data Science. Worth the time if you are the person who has to make these calls.
So the next time a vendor or an internal team brings you an impressive AI build, ask the one question that sorts durable from disposable: if the next model made this unnecessary, what would be left? If the answer is your data, your checks, and your judgement, fund it generously. If the answer is the build itself, rent it and stay light. The effort that frees up belongs in getting that split right. Making that call well, release after release, is the discipline.
