Operations | Monitoring | ITSM | DevOps | Cloud

Every AI coding tool ships the same promise: your developers, faster. Autocomplete in the IDE, agents in the terminal, a working prototype before lunch. And it delivers, at least for the person holding the keyboard. The problem is that most of what it takes to ship software was never a solo activity, and that is the part the market keeps skipping.

Running workloads across AWS, Azure, and GCP is the operational reality for most enterprise engineering teams. The challenge isn't the providers themselves, it's what happens when each one accumulates its own delivery pipeline, its own security configuration, and its own environment management tooling. What starts as provider flexibility quietly becomes provider-specific complexity, multiplied across every team that ships.

Business continuity planning has a quiet assumption built into most of it: that the infrastructure the plan runs on will cooperate. Backup systems will be accessible. Recovery procedures will work as documented. The provider whose services underpin the critical path will be available, or at least recoverable within the window the plan specifies. That assumption is tested every time a major provider has an outage, a regional failure, or a service disruption that cascades across dependent workloads.

For the past two years, the conversation around AI in software engineering has focused on one thing: productivity. Engineers are shipping faster, writing more code, and completing work in hours that once took days. Every new model promises another leap forward. What gets far less attention is what all that speed demands from the people using it. Guillaume Moigneu, Field CTO at Upsun, has spent the past year watching engineering teams adapt to AI-assisted development.

If your team has adopted AI coding agents, you've probably noticed something strange: writing code stopped being the hard part. That's the shift Patrick, a principal engineer at Upsun, kept returning to in our latest Product Highlights conversation. He's spent twelve years here, most of them writing back-end APIs in Go, and the past year building with AI on our newest product, Upsun Dispatch. His verdict on where the bottleneck moved is blunt: "The code isn't really a problem anymore.

There's a version of cloud strategy that looks like a decision and a version that looks like drift. Most enterprises are living the second version. AWS won an early workload because the team knew it. Azure followed the Microsoft enterprise agreement. GCP came in through a data science team that preferred its ML tooling. Nobody chose concentration; it just accumulated.

Ask any engineering leader how AI has changed their team, and you'll get an optimistic answer. Ask them to prove it with a number, and most go quiet. That gap is the story of 2026. Individual engineers are faster than they've ever been. Teams, in a lot of cases, aren't. We talked to our own engineering team, the people who've spent the last year building and shipping Upsun Dispatch and living through exactly this shift, and the same tension came up again and again.

When platform providers talk about autoscaling, they usually mean one thing: application autoscaling, adding or removing web instances based on traffic. The pattern is well understood. Define a metric, set a threshold, and let the platform act on it. Most platforms still leave database capacity as a separate, mostly manual problem. Teams either pre-provision for the worst hour of the worst day, upgrade plans on a calendar, or wire together their own scaling logic on Kubernetes or RDS.

Hosting an MCP (Model Context Protocol) server on Upsun lets AI IDEs like Cursor, Codex, Claude Code and Windsurf reach real infrastructure context (database schemas, service logs, environment variables), closing the gap between local coding assistants and your cloud environment.

For most IT leaders, multicloud didn't arrive as a decision. It arrived as a fait accompli. A team chose AWS for one workload. Azure came in through a Microsoft enterprise agreement. A SaaS acquisition brought its own cloud dependencies. A DR requirement pointed to a second region with a different provider. Nobody declared a multicloud strategy; the organization just became one. Today, 87% of organizations run a multicloud strategy, balancing an average of 2.6 public cloud providers simultaneously.