In production, some things hold when you lean on them. Others only look like they will – right up until real users arrive.
Most systems are built on a mix of things you know and things you assume. The solid parts are the ones you have tested, measured or confirmed. The empty parts are the assumptions: a vendor claim, a polished demo, a famous logo, code that worked once, capacity nobody actually verified. The problem is that solid and empty often look identical until weight lands on them. That is especially true in AI.
AI makes it unusually easy to build something that looks production-ready before the assumptions underneath it have actually been validated. A strong demo can hide weak foundations surprisingly well. The job is to find those weak spots before your users do. Here are five places we see them most often.
1. Cloud capacity is not the same as guaranteed capacity
Building on a major cloud provider does not automatically mean unlimited capacity will be available when you need it. On-demand capacity is still shared capacity. Under load, models or infrastructure can be throttled, constrained by region or simply unavailable at the scale you expected.
Guaranteed capacity often means reserving it in advance – which can mean a different commercial model, a different price and a budget decision that needs to happen much earlier than expected.
The question is not simply: Can this service scale? It is: Can it scale for us, in this region, at this level of traffic, when we need it?
2. “Supported” does not mean production-ready
A model or platform can support everything you need on paper and still fail on the things that decide whether it works in production. How many users can it handle concurrently? What happens to latency under real load? What are the practical rate limits? What does performance look like with the workload you will actually send? A feature being supported and a workload being production-ready are two different things. Test both.
3. Frameworks hide decisions you may still need to understand
Agent frameworks can remove a huge amount of repetitive plumbing: model calls, tool orchestration, memory and state management. That is valuable. But abstraction can also hide behaviours that matter in production.
Conversation history may grow unnecessarily. Old tool results may keep getting carried forward. Token usage and latency can increase over time. Shared session state can behave differently once several requests are happening concurrently.
None of these automatically make a framework bad. They simply mean that a trusted name or popular framework is not a substitute for understanding what happens underneath your own workload.
4. AI-generated code is only as informed as the context it receives
AI coding tools can move incredibly fast. But when they do not have access to the real environment they are building for, they have to fill in the gaps. That can mean a connection pool based on an assumption, a missing timeout, an aggressive retry strategy or an integration pattern that looks perfectly reasonable in isolation. The code may pass every development test. Then real traffic arrives.
The answer is not to avoid AI-generated code. It is to give the AI the real context: architecture, configuration, infrastructure constraints, APIs and operational requirements – and then validate what it produces. AI is much better at engineering from facts than from guesses.
5. Your model dependency is still a dependency
The model underneath your system is not fully under your control. Providers change models. Versions are deprecated. APIs evolve. Commercial terms change. Availability can vary by geography or regulation. If the whole application is tightly coupled to one model or provider, changing later can become expensive.
A thin abstraction layer between your application and the model can make that dependency easier to manage. The goal is not to pretend every model is interchangeable. They are not.
The goal is to make switching possible without rewriting the entire application. That is much cheaper to design early than retrofit later.
The obvious is often where production breaks
None of these problems are exotic. Capacity. Latency. State. Configuration. Dependencies. They are the ordinary parts of software engineering. But AI can make them easier to overlook because so much attention goes to the new and impressive part of the system.
When the model performs well and the demo looks great, it becomes tempting to assume the foundations underneath are equally strong. That is exactly when you should check them.
Define what “it works” means when real users arrive. Then prove it with real traffic, real numbers and real constraints. The cheapest hour on any AI project is the one you spend testing the thing everyone already assumed was fine.
