Part 1 of a five-part series: From Cloud AI to Local Models.
Most teams met AI through someone else's cloud.
You opened a web app, pasted a prompt, got something useful back, and the shape of the thing quietly became the definition of the thing. AI meant a hosted model behind an API. It meant tokens crossing a network boundary. It meant a provider owned the runtime, the policy layer, the outage, the bill, and most of the workflow.
That was the first practical deployment model.
It was not the final one.
The cloud won because it was the obvious first answer
Cloud AI won the first round for the same reason most centralized platforms win the first round: it made the hard thing instantly usable.
You did not need to buy hardware. You did not need to tune inference. You did not need to choose quantization settings, manage model files, serve a runtime, or explain to finance why a rack of GPUs was suddenly part of the developer platform. You called an API, and intelligence arrived.
That matters. Hosted frontier models made the category real for people who never would have installed a local model. They compressed years of infrastructure work into a textbox and a billing account. They gave every team the same cheap way to find out what AI could do for them.
But "this made adoption easy" and "this is the permanent architecture" are different claims.
Engineering history is full of things that started as a centralized service because that was the fastest way to make the capability available. Then the usage pattern stabilized. The organization learned where the capability mattered and where it did not. The first rough edges turned into durable requirements. Eventually the question changed from "can we access this" to "does this belong inside our own infrastructure boundary?"
AI is going through that same cycle.
A deployment model is not a definition
The mistake is treating the current access pattern as the nature of the technology.
Cloud AI feels natural today because most people first experienced capable models there. But nothing about "AI-assisted engineering" requires that every use case round-trip through a shared vendor endpoint. That is one answer to where the model runs, who owns the runtime, how policy is enforced, how context is supplied, how data crosses boundaries, and how failures are absorbed.
It is not the only answer.
This distinction matters because deployment models carry values. A hosted model optimizes for broad access, central improvement, and provider-managed complexity. That is useful. It also means your workflow inherits the provider's constraints:
- their uptime
- their rate limits
- their pricing curve
- their data boundary
- their policy surface
- their product decisions
- their latency profile
None of those are moral failures. They are just the trade you made.
The problem starts when teams forget they made a trade at all.
The cloud dependency becomes architecture
The first few AI calls feel like tooling. A helper in the editor. A chat window beside the docs. A script that summarizes a pull request. At that scale, the dependency is easy to ignore.
Then the calls spread.
The editor starts depending on it. The review process starts depending on it. Support triage starts depending on it. Incident summaries, internal docs, migration plans, test generation, code search, and backlog grooming all start quietly assuming that the model is available, affordable, allowed to see the context, and shaped correctly for the workflow.
At that point the model provider is no longer a tool. It is part of the system.
That is where the old distributed systems question returns: what happens when the dependency disappears?
The answer might be acceptable. Maybe the feature degrades. Maybe the review summary waits. Maybe the incident commander writes the update by hand. But you should know that answer, because once AI becomes part of normal engineering operations, cloud dependency is not a procurement detail. It is runtime architecture.
This is the same reason the face changed, but the dependency didn't. "The model provider is down" is just a newer version of "the database is down" or "the region is down." Different noun. Same shape.
Local models are not nostalgia
There is a lazy version of the local-model argument that turns into nostalgia: real engineers run everything themselves, the cloud was a mistake, dependency is weakness, bring the machines back under the desk.
That is not the argument.
Cloud models are useful. Frontier models will keep mattering. Some work really does benefit from the strongest generalist available, and many teams should not spend their time operating inference infrastructure before they understand what they need from it.
The better argument is more boring and more durable: once a capability becomes common, repeated, sensitive, high-volume, and workflow-specific, teams naturally start asking whether parts of it should run closer to the work.
Closer to the code.
Closer to the data.
Closer to the policies.
Closer to the failure domains the organization already knows how to operate.
That is what local and self-hosted models represent. Not a rejection of cloud AI, but a normal infrastructure response to a capability becoming important enough that the default boundary starts to matter.
The future is probably not pure local
The useful future is not every engineer running an enormous model on a laptop and never touching a cloud API again. That is just the mirror-image mistake.
The likely future is routing.
Use the cloud model where the cloud model is the right tool: hard reasoning, rare tasks, broad knowledge, expensive synthesis, workflows where the marginal cost is worth paying. Use local models where locality is the point: tight iteration loops, private context, high-volume bounded tasks, offline tolerance, tool calls near the codebase, and internal automation that should not depend on someone else's queue.
That is a deployment question, not an identity question.
The serious version of AI-assisted engineering will not ask, "cloud or local?" the same way serious infrastructure teams do not ask, "database or cache?" They ask what each component is buying, what failure it introduces, and whether the placement matches the workload.
The reframe
The cloud was the first AI deployment model because it made AI available before most teams could run it themselves.
That was a good starting point.
But a starting point is not a destination. As usage moves from occasional experimentation to everyday engineering infrastructure, the questions change:
- Does this workflow need frontier intelligence, or local availability?
- Does this context belong outside the organization?
- Is this cost acceptable at the volume we actually want?
- What happens when the provider is slow, unavailable, or changes the rules?
- Is the model shaping our workflow more than our workflow is shaping the model?
Those are infrastructure questions. They are where this series is going.
The future of AI-assisted engineering is not everyone renting the same generic intelligence from the same handful of endpoints forever. It is teams learning which parts of intelligence should be centralized, which parts should be local, and how to route between them without pretending one deployment model is the whole category.
The cloud made AI easy to start using.
The next question is where it should actually live.
Next: Part 2 — Fast at What?