The AI Stack That Chose Itself

Something I keep noticing, and it took me a while to put a name to it.

A company ships three AI features across a year. The search box picks up semantic ranking. The support inbox starts drafting replies. A summariser lands on the activity feed. Three good features, three teams, three sensible calls made at the moment they had to be made.

Put them side by side, though, and a different picture shows up. One feature calls a frontier API directly. One goes through whatever key the platform team already had. One runs a small open-weights model on a box someone spun up for a hackathon and never turned off. Two of them store embeddings, in different places and in different shapes. And nobody can say whether any of the answers got better or worse last month.

What strikes me is that there is no bad decision anywhere in that story. Every individual call was reasonable. There was simply never a decision about the whole.

That is what I have come to mean by an AI stack — not the tools, but the decisions about the tools that somebody made on purpose. And my honest read is that most software companies already have one. It just assembled itself while everyone was busy shipping.

The decisions get made whether or not anyone makes them

The tooling is already inside the building. Stack Overflow's 2025 survey found 84% of respondents are using or planning to use AI tools in their development process, up from 76% the year before. That is not a procurement decision working its way through a committee. That is what engineering did last Tuesday.

The part I find easy to underestimate is that choices made one at a time are still choices, and each one quietly narrows the next. Which model a feature calls shapes what its failure modes look like. Where the vectors live sets the price of a migration. Whether a team wrote its own retry and fallback logic decides whether an outage is a blip or an incident.

None of that feels like architecture while a feature is being shipped. All of it is architecture the moment there are four features.

That, to me, is the difference between a stack and a pile. A stack is a set of choices someone can defend. A pile is a set of choices nobody can name.

The ground moves faster than a roadmap does

The argument I find most persuasive for designing this deliberately has nothing to do with tidiness. It is that the ground keeps moving.

Menlo Ventures' 2025 State of Generative AI in the Enterprise puts enterprise foundation model API spend at $12.5 billion — and the share of it has reshuffled twice in two years. OpenAI went from roughly half of enterprise LLM API spend to 27%; Anthropic from 12% in 2023 to 40% in 2025; Google from 7% to 21%.

Read as a scoreboard, that says who is winning. I think it is more useful read as a rate of change, because then it says something else: whoever gets picked, the assumption that they will still be the right answer in two years is the softest thing in the whole architecture.

I do not take that as an argument for hedging across every vendor. That costs more and buys less than it sounds like. I take it as an argument for knowing where the seam goes — which parts of a system are allowed to know the name of a model, and which parts must never. A team that can answer that changes its mind in an afternoon. A team that cannot has an eighteen-month project ahead of it and does not know that yet.

"Almost right" is the part I worry about most

The same Stack Overflow survey found that 46% of developers actively distrust the accuracy of AI output, and that the single biggest frustration — 66% of them — is "AI solutions that are almost right, but not quite."

That phrase stayed with me, because of what it describes. Not a system that fails loudly, which anyone would catch. A system that is mostly correct, drifting slowly, in a direction nobody happens to be measuring.

When nothing in the stack measures output quality, a whole class of question becomes unanswerable. Is the newer model better for this particular job? Did last week's prompt change help? Is the cheaper option good enough for the low-stakes half of the traffic? Those are all answerable, but only if something in the architecture was built to answer them. Otherwise they get settled by whoever sounds most certain in the room, which is a poor way to spend an engineering year.

That is why I have stopped thinking of evaluation as something bolted on after launch. It is the piece that makes every other piece swappable.

The bill arrives late

Stacks that assemble themselves tend to fail in a particular way, and there is now hard data on it.

IBM's 2025 Cost of a Data Breach Report found that 13% of organisations reported breaches of AI models or applications — and of those, 97% had no AI access controls in place. One in five reported a breach traced to shadow AI, the unsanctioned tools people adopt on their own, and those breaches ran about $670,000 more expensive than the rest.

The governance figures explain a lot of that. Among breached organisations, 63% either had no AI governance policy or were still writing one. Of the ones that did have a policy, only 34% audited for unsanctioned AI at all.

What I take from those numbers is not a story about sophisticated attackers. It is a story about companies that could not produce a list of the places their data goes, because no such list was ever written down. And the bill for that shows up long after the people who built each piece have moved on to something else.

The five questions I keep coming back to

A stack is not a diagram, and it is not a vendor list. When I am trying to work out whether one actually exists, these are the five things I want to see answered in writing:

• What is the architecture? Not the tools — the shape. What calls what, what is allowed to fail, and where the seam sits that lets a component be swapped without a rewrite.
• Which tool sits at each layer, and why that one? A reason specific to this product beats a reason that would apply to anybody.
• Where is output quality measured? One place, with numbers recorded before the next model release, so a change can be judged instead of debated.
• Where does data go, and who agreed to that? Every third-party call the product makes, on a single page.
• What can this team build and maintain? The most honest of the five, and the one most often skipped. An architecture a team cannot operate is a hiring plan, whether or not anyone has said so out loud.

Very few companies can answer all five today. I do not read that as a failure of engineering. It is the fairly predictable result of shipping AI features faster than anyone was ever asked to design for them.

The part that is hard to redo

Features are replaceable. A summariser can be rewritten in a sprint and nobody outside the team will notice.

What sits underneath is not like that. It is the accumulated set of assumptions every feature was built on, and it gets more expensive to change with each new thing that lands on top of it.

So the teams I expect to move fastest through the next couple of years of model releases are not the ones that guessed the winner. They are the ones that decided, on purpose and early, which parts of their system were allowed to care.