When a company builds something with AI, it is really building two things at once. The first is the foundation: its data, its permissions, the connections between its systems and the rules of how its business runs. The second is scaffolding: the prompts, patches and workarounds that make today’s models good enough to use. Every new model release makes the foundation more valuable and makes some of the scaffolding unnecessary. I call the boundary between the two the depreciation line. Companies that never draw it fund both layers as one, and end up paying for scaffolding as if it were built to last.
The advice everyone starts with
For the past two years, companies starting with AI have heard two pieces of advice. Large companies are told to start small: run a pilot, pick a contained workflow, prove value, then expand. AI-native builders say something bolder: build for fast obsolescence, and be ready to throw code away whenever a better model arrives.
On the ground, though, the conversations I have with operators end somewhere else. Most of them have already seen the technology work, usually in a demo they ran themselves. What they want to know is whether the thing they are about to build will still be worth owning eighteen months from now.
Neither piece of advice answers that. A pilot shows whether a tool works today. It says nothing about whether the thing you are about to harden deserves hardening, and hardening is where the money goes. Throwing code away is easy for a startup. For a company with customers on the system, it is a luxury, and that gap is what this piece is about.
The line
Side by side, the two layers look like this.
One question sorts most pieces. If the next model did this task perfectly, would you still need this? If yes, it is foundation. If no, it is scaffolding.
If you build agents, a third word will already be on your mind: the harness, the runtime around a model that runs its loop, calls its tools, manages its context and enforces its permissions. Foundation and scaffolding describe why a piece of work exists. A harness describes what a piece of software does, and it contains both. The parts of a harness that connect the model to your systems, control what it is allowed to touch and record what it did belong in the first column. The parts that exist because today’s models lose track of long tasks, run out of context or need a second pass to get things right belong in the second. Treating the whole harness as one asset is the same mistake in a smaller box.
The rule that follows is simple. Build the first column to last. Build the second column to work, and only to work. Every hour spent making the scaffolding elegant is an hour spent hardening the part most likely to be deleted.
That changes the investment case as well as the architecture. Instead of carrying one return figure over three years, you carry two. Say a piece of scaffolding only pays back over thirty months, and you expect a model release to absorb it in twelve. You already have your answer, and no pilot will change it.
Why this is new
A company buying a workflow tool in 2018 could assume the capability it was paying for would still be scarce three years later. I built on that assumption for most of my career, and it held. It has stopped holding.
Nicolas Bustamante, founder of the AI research company Fintool, described the mechanism plainly in an essay first published in October 2025, “LLMs Eat Scaffolding for Breakfast.” Miss a single capability announcement from one of the major labs, he writes, and months of work can become obsolete. He names the casualties: vector databases, LLM frameworks, dedicated prompt engineering teams. Each was built in good faith to cover something models could not yet do, and each was absorbed once they could. He is just as direct about why teams hold on, from sunk cost to organisational inertia.
The same thing has happened inside everyday practice. Two years ago, teams building with these models kept libraries of carefully tuned prompts. They broke work into small steps and had a person check each one before the next began. They wrote extra code to catch output the model got wrong. Much of that has been absorbed. Today’s agents take a goal rather than a script, check their own steps along the way, and write much of their own test code, and a person reviews the result rather than every step. Testing shows where the line falls. The effort of writing tests turned out to be scaffolding, because agents now do most of it. The tests themselves, which spell out how the business is supposed to behave, are foundation. They matter more now, because agents write code against them. Run each piece through the question from earlier and it sorts itself.
The economics underneath are moving even faster. In September 2026 the research group Epoch AI estimated that the cost of reaching a fixed level of AI performance has fallen by about 47% every quarter since 2023, which works out to roughly 13 times cheaper each year. By their comparison, that is faster than computing, DNA sequencing or batteries ever got cheaper. Their own caveat is that benchmark scores are not the same as useful work. Even so, a capability that is expensive enough to justify custom scaffolding today is likely to be cheap, or built into the model itself, within a year or two.
Put together, this leaves companies with customers in an awkward position. What seems to be happening is that they make one of two mistakes. Some approve the whole build on a single business case, and end up paying to harden scaffolding that the next model makes unnecessary. Others cannot get that single business case past finance, because nobody can say how long the thing will last, so the project stalls in pilot. Both mistakes come from treating two kinds of investment as one.
Who this applies to
The problem is sharpest for a particular kind of company, and it is tempting to describe them by size. Size is the wrong way to sort them. What matters is whether a company can afford to throw code away, and three conditions make that hard.
The first is revenue to protect. Customers use the system today, under contract, and their expectations do not pause for a rebuild. The second is that technology supports the business rather than being the business. Customers pay for a service, and software is how it gets delivered. The third is a fixed technology budget in which AI is one line among many, competing with security, compliance and a roadmap already promised.
A 40,000-person enterprise meets all three as often as a 200-person services firm does, and so does almost any business unit inside a large company. That is why a big budget protects less than people assume. More money does not help when nobody can say how long the thing being funded will be needed.
To be fair, two kinds of company sit outside this problem. The first is the AI-native company, with no installed base and no contracts to honour. For them, Bustamante’s own advice, to build for fast obsolescence, celebrate deleting code and pivot in days, is exactly right. He sees this as where startups beat big companies, which he says are “late by at least two paradigms.” From inside a company with customers, much of that lateness is the cost of keeping those customers served.
The second is the company whose advantage has nothing to do with software. A maker of grid-scale energy storage is protected by its cell supply agreements, certifications, construction partnerships and installed base. AI sharpens its forecasting and speeds up its paperwork, and touches none of that. When a company like that explores AI without making big bets, it is reading its own moat correctly.
Drawing the line
Running through all of this is a shared belief that an AI investment is one thing, to be approved or turned down as a whole. This is where I differ. Drawing the line splits the decision in two. You decide, in advance and on the record, which parts you are willing to delete later, and you fund each part on its own terms. It is the version of building for obsolescence that a company with revenue can actually carry out.
In the platform rebuilds I have been part of, stopping was never an option. The old system had to keep serving customers every week of the migration, so nothing could be deleted until its replacement was already carrying the load. That is the normal condition of running software, and “delete it and pivot in days” does not describe it.
What survived those rebuilds was rarely the clever part. It was the data model, the permissions, the integrations and the audit trail: the unglamorous first column. AI is running the same pattern, only faster, which is why it pays to know in advance which column each piece belongs to.
Where the line goes from here
Two parts of this are still open, and they point the same way.
The first is how long scaffolding lasts. Nobody knows the right useful life for the second column, and I would be wary of anyone selling a number. Twelve months is a guess. So is eighteen.
The second is that the line itself moves. Some of what sits in the first column today, integration code especially, is exactly what better agents are learning to write. The table is a snapshot of today.
Both lead to the same answer. The line has to be redrawn on a fixed schedule rather than drawn once and defended. With the cost of a given capability roughly halving every quarter, a yearly review is too slow, which is awkward when budgets are still set once a year. The alternative is already visible. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by the end of 2027, because of rising costs, unclear business value or weak risk controls. Read against everything above, much of that looks like the cost of never drawing the line at all.
What to do about it
For anyone approving AI spend, three things follow.
Split every AI investment into two lines before you approve it. Foundation on one, scaffolding on the other, harness included. If a team cannot tell you which is which, that is your first finding.
Give the scaffolding an expiry date, and make it pay back before then. Write down the useful life you are assuming. If a piece only pays back after a model is likely to absorb it, build a cheaper version or skip it.
Redraw the line on a schedule, and keep score. Revisit it every quarter, or with every major model release. Record what got absorbed and how long it lasted. Almost nobody shares this across companies, so every organisation pays the same tuition privately. Your own record is the closest thing to an answer you will have.
I think that is where this settles. The companies that do well with AI will still throw away scaffolding, often and at real cost. The difference is that they will have decided in advance which parts were scaffolding, priced them that way, and kept their money in the foundation that every new model makes more valuable.