The Two-Speed Roadmap: Planning AI Features When the Model Floor Moves Every Quarter

There is a specific kind of regret that only happens on AI teams. You spend a quarter building an elaborate workaround — a multi-step prompt chain, a custom reranker, a hand-tuned tool-routing layer — and ship it. It works. Then six weeks later a new model drops, does the whole thing natively in one call, and your quarter of work is now dead weight you have to rip out. The feature didn't fail. The floor moved.

This is the structural problem with planning AI features in 2026: the substrate you're building on is improving faster than your release cycle. From 2023 into mid-2025, frontier labs shipped on a roughly six-month cadence. By Q1 2026 that compressed to substantive releases roughly every four weeks, with stretches where five labs shipped inside a thirteen-day window. The thing you're standing on moves under you between planning and launch.

The instinct most teams have is to plan harder — longer roadmaps, tighter specs, more upfront design. That instinct is exactly backwards. When the underlying capability is a moving target, a longer plan just means a longer list of bets that the next model release will invalidate. What you need instead is a roadmap that runs at two speeds: one track for things that get better when the model improves, and one track for things that get deleted when the model improves. They are not the same kind of work, they should not be funded the same way, and conflating them is why so much AI engineering effort evaporates.

The Two Categories Every AI Feature Falls Into

Every feature you build around a model is making an implicit bet about the relationship between your work and the model's trajectory. There are only two bets, and they point in opposite directions.

Compounding bets get more valuable as models improve. These are the things the model can't do for you no matter how smart it gets, because they aren't capability problems — they're access and context problems. Your proprietary data pipeline. Your integrations into systems the model has no credentials for. Your evaluation suite that encodes what "correct" means in your domain. Your customers' historical context. When the model gets smarter, these assets let it do more, not less. A better model plugged into your unique data produces better output; a better model plugged into nothing produces a better chatbot anyone can rent.

Depreciating bets get less valuable as models improve. These are workarounds for present-day model limitations. The chain-of-thought prompt engineering you wrote because the model couldn't reason. The orchestration framework you built because the model couldn't hold a multi-step plan. The output parser you maintain because the model couldn't reliably produce structured data. Every one of these exists to compensate for a gap, and the labs are spending billions of dollars to close exactly those gaps. You are, in effect, racing the model's roadmap — and you will lose.

The clearest historical example is reasoning scaffolding. For about two years, a whole cottage industry built chain-of-thought wrappers, multi-step planners, and self-critique loops because models couldn't reason reliably on their own. Then reasoning got baked into the models themselves. The scaffolding didn't get better. It got deleted. The teams that had treated it as durable infrastructure ate a migration; the teams that had treated it as disposable shrugged and pulled it out.

Why "Just Build the Workaround" Is a Hidden Liability

Here's the trap: depreciating work often looks like the responsible engineering choice in the moment. The model can't do X reliably, customers need X, so you build the scaffolding for X. That's not wrong. The mistake is how you build it — with the same durability assumptions you'd apply to any other system.

A workaround built like permanent infrastructure accrues silent liability. It gets test coverage, documentation, a clean abstraction, a place in your architecture diagram. All of that investment is sunk cost the day the model absorbs the capability, and worse, the abstraction now actively resists removal because three other things depend on it. The LlamaIndex team has described this as the scaffolding layer collapsing — the elaborate middleware that existed to compensate for model weakness gets eaten as the weakness disappears, and the teams holding the most engineered version of it have the hardest time letting go.

The fix isn't to stop building workarounds. It's to build them disposably and label them as such. The useful gate is the six-month test: before investing in any tooling, ask whether it will still be useful in six months when models improve. If the honest answer is no, build it as explicitly temporary — prioritize speed over robustness, isolate it behind a clean interface so it's easy to amputate, and write down the removal trigger. "When a model can do structured output reliably above 99%, delete this parser." Documenting the disposal criteria is the whole discipline. A workaround with a written expiration date is a tool; the same workaround without one is technical debt that nobody has permission to remove.

Loading…