Operations | Monitoring | ITSM | DevOps | Cloud

AI has made writing code fast, and you can feel it. Commits are up, pull requests are up, new repos spin up over a weekend, and your engineers swear they are faster. But where are all the new products? If every team really got faster, the software you use every day should be getting visibly better. AI helped your engineers ship more code. It didn't help your team ship more products.

Upsun is included in IDC ProductScape guide to worldwide cloud deployment-centric platform capabilities. Building and scaling applications has never been more complex or more critical. Engineering teams are under constant pressure to ship faster, manage increasingly complex infrastructure, and adapt to the rapid rise of agent and AI-powered development. Choosing the right platform to support these demands is an important decision for technology organizations.

Choosing a Platform-as-a-Service (PaaS) is not just an infrastructure decision. It is also a decision about how personal data will be handled over the life of the project. It's a governance commitment made early, with consequences that run late. A PaaS does not remove an organization’s accountability for privacy, security, or regulatory compliance. However, a well-architected PaaS can materially strengthen the control environment in which those obligations are managed.

If you've read our previous piece on the 8 stages of AI engineering maturity, you know where your team sits. Turns out adopting AI is the easy part; adapting to its consequences is where most organizations struggle. For more than a decade, software organizations optimized around a single assumption: implementation capacity was scarce.

There's a version of this conversation that plays out in engineering organizations everywhere. Leadership pushes for standardization. Developers push back. The argument from developers is reasonable on its face: every codebase has different needs, every team has tools they're good at, and adding process feels like slowing down to go faster. It's a genuine tension, and it's also a false one. The teams that ship the most aren't the ones with the most infrastructure freedom.

A few months ago, Steve Yegge published his 8 levels of AI-assisted development, and it clicked the moment I read it, because I had lived that exact progression myself, moving from autocomplete to running agents one step at a time. Framed as an AI trust gradient, it finally gave the industry a vocabulary for something most of us were already going through without a name for it. If you haven’t read it, save it for later.

Standardize the route from code to production. Everything else is a team decision, not a platform problem. Most app delivery problems do not start with bad engineering. They start with too much variation. One team provisions environments manually. Another keeps deployment notes in a wiki. A third has a staging setup that only one engineer understands. Security reviews happen late because the platform does not make the safe path obvious.

Environment drift persists when teams standardize code but leave infrastructure, data, and access decisions to individual teams and manual setup. Most teams know their environments are not identical. What they underestimate is how quietly the gap widens. A database version is out of sync between production and staging; an environment variable is added manually to one server but never tracked; a cron job runs in production but was never captured in the dev config.

I have an Upsun project that's nothing but proofs of concept. It's a dashboard, basically. Each POC gets its own tile. Click in, and you land on a page with three tabs. The first tab is a written explanation of what the POC argues. The second tab is the POC itself, with a built-in demo that automates a walkthrough of the feature so the recipient can watch it run without me on the call.

I keep hearing the phrase "code is cheap." I don't know who came up with it. Whoever it was clearly has not seen an Anthropic bill. I get what they mean. The cost of writing a line of code has cratered, AI does most of the typing, you know the rest. Fine. But the phrase is combative in a way that doesn't help anyone, especially the engineers in the room. "Code is accessible" lands better. Less swagger, more honesty. Either way, here's the line my friend Guillaume gave me that finally cracked it open.

IT leaders rarely think they have an infrastructure problem. When a roadmap slips or an audit finding lands, the reflex is to hire more senior engineers, a bigger platform team, another DevOps lead. But headcount is rarely the real lever. The bottleneck is the "hidden factory": the undocumented, invisible work that sits between a developer writing code and that code reaching customers. It doesn't show up in post-mortems because engineers treat the workarounds as normal.