Picture a project manager running a large-scale deployment at a tech company. The AI tool she integrated for document handling works perfectly on the test set: it summarizes, extracts, and formats files exactly as promised. Then one morning a client sends a batch of files with a completely different structure, and the assistant fails in ways nobody anticipated. Worse, a month later, the same tool suddenly handles that harder case flawlessly. Nobody updated it. Nobody told the vendor. The capability simply appeared.
This is the strange behavior called "sudden scale," and it is quietly reshaping how business operators should think about planning. The idea is simple enough once you see it in the data. Researchers building large language models noticed that as models grew past a certain size, certain tasks stayed broken for a while and then, almost overnight, started working. A model small enough to handle might be unable to reason about a simple chain of logic, while the next size up solves it. There was no update. There was no new feature release. The capability emerged only after the model crossed some threshold.
What is actually happening
In academic terms this shows up as a "phase transition," borrowing language from physics. Properties of the system appear abruptly rather than gradually. When teams plotted performance on hard tasks against model size, the curves did not climb steadily. They stayed flat, then spiked. A task might sit at ten percent accuracy one generation and jump to ninety percent the next. Researchers like Noam Brown at Anthropic documented these jumps systematically, calling them "emergence." A capability that the smaller model cannot perform becomes reliably available once the model grows large enough, often by a factor of two or three in parameters.
The plain-language takeaway is that AI capability does not always arrive in tidy increments. It sometimes arrives in jumps, and you cannot always predict from today's performance exactly what tomorrow's model will be able to do. The model that works for your task today might be a version that simply lacks a skill the next generation has, whether or not anyone wrote that skill on purpose.
Why this matters for your planning
Most operational roadmaps assume steady progress. You build a product plan around features that exist, you estimate costs based on current performance, and you sign contracts with vendors assuming the tools will behave consistently. Sudden scale breaks that assumption in a specific way. The thing that makes your roadmap fragile is not that models regress. It is that they advance faster than the planning cycle can account for.
Consider a company that selects a vendor for customer service automation. The sales demo shows a model that handles tier-one support competently. Procurement locks in a three-year contract based on that capability. Six months later, a new model generation arrives that can now handle tier-two support on its own. The tool the company paid for two years ago is now a fraction of what the market offers. The roadmap built around the old model looks out of date almost immediately.
The reverse risk exists too. You may design a system around a skill you assume the model will have, only to discover the skill does not appear until you reach a model size or cost you never planned for. You build the product, and the feature you counted on simply does not work. This is the planning trap: both your optimistic and your conservative timelines can be wrong in the same quarter, because the underlying capability landscape shifts discontinuously.
The real planning risk
The core problem is that roadmaps built around today's known features can go obsolete faster than expected. This is fundamentally a planning risk, not just a technology risk. When capability emerges in jumps, you cannot reliably extrapolate. A roadmap that assumes linear improvement will be based on a false premise from day one.
This cuts into two areas of the business that executives usually treat as separate: procurement and product roadmaps. Procurement moves slowly. Contracts, pricing, and vendor relationships lock in for years. If the baseline capability shifts during a contract, you may be locked into paying for a tool that is now a fraction of the market standard, or you may find renegotiation painful because of switching costs. The roadmap side suffers in kind. You may have scoped a product around a specific model capability, and that capability may not exist yet, or may appear only in a version that changes your entire architecture.
How to build readiness
There is a practical way to handle this, and it starts with changing how you think about timelines. Instead of building plans around a single forecast of capability, design for a range. Acknowledge that the model that works today may lack a skill the next model has, and price your plans accordingly.
Shorten the loop. The teams that cope best with sudden scale are the ones that test current models frequently rather than betting everything on a single long-term procurement decision. Rather than locking a vendor into a multi-year deal on the strength of one demo, negotiate shorter terms, include escalation clauses for performance, and keep the ability to move to a newer model without starting from scratch. Treat capability as a rolling variable rather than a fixed input to your costs.
Map the specific capability you need, not the general promise. "Handles customer questions" is too vague to plan around. Write down exactly what the model must do, in what volume, and with what accuracy. This tells you precisely which threshold would matter to you and lets you act the moment a model crosses it. When the capability appears out of nowhere, you will already know it is useful and have a plan to use it.
Build in flexibility at the architecture level. If your system can swap one model backend for another without a rebuild, a sudden capability jump becomes an opportunity rather than a disruption. The companies caught out are the ones whose entire product is fused to a single model's current limitations.
The direct answer
To answer the question directly: AI models develop new capabilities out of nowhere because capability does not always increase steadily. Models often stay stuck on a task until they reach a certain size, at which point the skill appears suddenly, sometimes jumping from nearly useless to highly reliable in a single generation. This is a genuine planning risk for your business. Your roadmaps built around today's known features can go obsolete faster than expected, so your procurement and roadmap timelines must reflect that reality.
How ready is your company? The honest test is whether your planning treats AI capability as something that will arrive on schedule. If it does, you are not ready. The companies positioned well are the ones that design for discontinuity: short procurement cycles, capability-specific requirements, model-swappable architecture, and timelines that assume the next model may do something today's model cannot. When the capability shows up out of nowhere, those teams will be first to use it, and they will not be caught behind a plan that just expired.
