"We should wait for the next model release."
You've heard this. You've maybe said it. The reasoning is sound — new models come out every few months, each one genuinely better than the last. Why commit to an architecture today when a dramatically better model might be six weeks away?
Here's the problem. A dramatically better model is always approximately six weeks away. The cadence of AI releases guarantees it. There is never a moment when the next release isn't imminent. And the spell cast by that certainty freezes all implementation work, because why build with today's tools when tomorrow's will be better?
Time Stop is self-renewing. The next model arrives, and it is better. But by then, the next next model is already announced. The spell recasts itself. The team remains in a state of strategic readiness, which is indistinguishable from strategic paralysis except that the slide deck is more polished.
The cruelest feature of Time Stop is that it is never entirely wrong. The next model will be better. The question the spell prevents the team from asking is whether waiting for it is worth more than shipping with the current one. Since the spell also freezes that conversation, the answer is always deferred.
This is not a new pattern. Technology teams have always had reasons to wait. "Let's wait for the next framework version." "Let's wait for the language feature." "Let's wait for the standard to stabilize." What's different now is the cadence. Previous technology cycles moved on the order of years. AI model releases move on the order of weeks. The window between "this model is good enough" and "but the next one might be better" has collapsed to the point where it's always open.
The result is a team that is perpetually almost ready. They have evaluated the tools. They have prototyped with the models. They have a roadmap. They have a strategy. What they don't have is shipping software, because every time they approach a decision point, a new model announcement resets the evaluation clock.
The damage compounds in ways that aren't immediately visible. While the team waits, competitors ship. Customers find alternatives. The team doesn't build shared practices around any tool, because which tool would they standardize on? When they finally do adopt something — usually because someone with authority forces a decision — there's no institutional knowledge, no conventions, no guardrails. Everyone starts from scratch, makes their own mistakes independently, and the messy, ungoverned adoption that the waiting was supposedly preventing happens anyway, just six months late.
The counter-move is a shipping deadline that someone with budget authority actually enforces. "We ship this Friday with this model and this architecture, full stop." The model will be better next month. The architecture will need updating eventually. The tool will be superseded. None of that changes the fact that shipping with today's tools teaches you things that waiting for tomorrow's tools never will.
The spell can only be broken by a deadline with consequences. Not a target date. Not a goal. A deadline that someone enforces, that has real organizational weight behind it, and that treats "but the next model" as a reason to plan the migration after launch, not a reason to delay the launch itself.
The next model will be better. Ship anyway.
Time Stop (Pending Next Release) is one of the spells in The AI Developer's Field Guide, a field guide to the anti-patterns AI brings to software engineering.