New research shows how much engineering time infrastructure consumes and what to do about it.
Adding another infrastructure provider is easy to measure. The engineering work created between providers is much harder to see.
It lives in the seams: configuring environments, reconciling identity and networking, debugging integrations, moving workloads between systems, and figuring out which layer is responsible when something fails.
Our survey of 500 AI Natives in the United States provides a measure: 60% say more than a quarter of engineering time goes to infrastructure work rather than model development.
Complexity builds across the stack: within layers, at their handoffs, and across the providers teams use. Each creates a different kind of operational burden.
Three areas where the engineering overhead accumulates
1. Between infrastructure layers
An AI workload doesn't run on compute, storage, networking, orchestration, and serving as separate pieces. It runs on the system formed together.
Between these layers is where infrastructure decisions can accumulate engineering work and operational overhead. Environments have to be configured, integrations debugged, data moved, and workloads scheduled. When something breaks, engineers also need visibility across the whole stack to find out what has gone wrong, and how to fix it.
The research shows teams are already feeling the strain of these handoffs.
Deployment is the most commonly cited source of friction or delay, named by 39% of respondents. Optimizing an individual layer can improve its performance. But if the layers around it still require engineers to stitch them together, the operational burden remains.
2. Between providers
The same effect becomes more visible as infrastructure spans multiple environments. The average AI Native uses four providers and tools across the AI lifecycle, and only 4% rely on a single infrastructure provider.
Every added environment brings its own interfaces, access controls, networking, and operating processes, and someone has to keep them all working together.
The research shows how the operational burden changes as provider count rises:
- 40% of businesses using one or two providers lose more than a quarter of engineering time to infrastructure work.
- 53% of those using three or four do.
- 73% of those using five or more do.
Provider count is a useful signal. But the deeper issue is the number of boundaries engineers have to operate across.
3. Between training and production
Training a model and running it in production are not isolated infrastructure problems. Moving between them can cross environments, orchestration systems, deployment processes, serving infrastructure, and observability tooling.
More than a third of AI Natives (34%) report taking four days or more to move a trained model into production.
The relationship with fragmentation is striking. Among businesses using fewer providers (one or two), 17% take four days or more. Among those using five or more, that rises to 44%.
This is where infrastructure complexity becomes product complexity. Engineers are not just operating individual systems. They are responsible for the path between them and across the product development and release lifecycle.
Reduce complexity while keeping flexibility
The answer is not consolidation for its own sake. Specialist providers exist because they solve real problems, and different workloads require different tools, frameworks, and operating models.
But the research points to a strong appetite for a more integrated foundation: 72% of respondents say a single platform spanning compute, storage, networking, and AI tools would be very or extremely valuable.
The opportunity for full-stack infrastructure is to remove unnecessary coordination between layers while preserving choice where it matters. An integrated stack can help address capacity, reliability, and performance to support AI workloads as one system from training through production.
That does not mean restricting choice. An integrated foundation still has to be interoperable with the tools and environments teams already rely on, so teams can reduce operational work without getting locked into a closed ecosystem.
At Nscale, that means bringing compute, orchestration, and inference together on a shared foundation, while enabling teams to use the tools and frameworks they already rely on.
This article was originally published as part of Nscale's Full Stack AI newsletter, where we share perspectives on AI infrastructure, engineering, and emerging industry trends.
Subscribe to receive future editions.
