Developer tool adoption surveys tell a consistent story at the moment. AI-assisted coding has gone from a novelty to a standard part of most engineers' workflows in a remarkably short period — Stack Overflow's figures show adoption moving from 44% in 2023 to 92% in 2026. The productivity gains are real, and they show up in deployment frequency, in the speed at which teams can prototype new features, in the reduction of the more mechanical parts of programming work.
This is mostly good. But it creates a tension that I think deserves more attention than it usually gets.
The Multiplication Problem
When developers ship code faster, more code goes to production. More services get created, more configurations get changed, more infrastructure gets provisioned. The total surface area of what a team is responsible for grows, even if the team size does not.
The challenge is that the operational maturity required to manage that surface area does not scale automatically with the velocity of code delivery. An engineer who ships two features a week with reliable, self-service deployment tooling is in a different situation than one shipping the same features through manual handoff processes and shared environments. The code velocity matters, but so does the system that receives it.
Platform engineering is the discipline that deals with this gap. It is the work of building and maintaining the internal platforms that let developers move quickly without each team having to reinvent the same infrastructure, solve the same deployment problems, or navigate the same compliance requirements independently.
What a Good Internal Developer Platform Actually Provides
The term "Internal Developer Platform" has accumulated enough marketing weight that it is worth being specific about what the useful parts actually are.
The most valuable platforms I have seen have a few things in common. They provide golden paths — opinionated, well-maintained routes for deploying the most common types of services — that make the right thing easier than the wrong thing. They abstract infrastructure complexity without hiding it entirely, so developers can get things done quickly but can still understand what is happening when something goes wrong. And they build compliance and security requirements into the path itself, so governance does not have to be bolted on separately or enforced through manual review.
That last point matters more as code velocity increases. If every deployment requires a human to review it for security and compliance, and deployments are happening ten times as frequently, something has to give. Either the review quality suffers, or the deployment frequency does. Platform engineering resolves that tension by making the review programmable and automatic.
The Unglamorous Reality
Platform engineering is not usually the most exciting work in an engineering organisation. It does not ship user-facing features. It does not generate the kind of visible output that gets celebrated in sprint reviews. It is infrastructure for infrastructure, and it requires sustained investment over time to work well.
This is partly why it tends to be underfunded relative to its importance. Gartner's research suggests 80% of large organisations now have dedicated platform teams, and those that do report 30 to 50% improvements in deployment speed and significant reductions in cognitive load for product engineers. That is a substantial return, and it is also the kind of return that accrues quietly rather than appearing on a single release date.
The analogy I sometimes use: platform engineering is load-bearing in the same way that foundations are load-bearing. You only notice it when it is missing.
The AI Era Makes This More Pressing
The specific pressure AI tooling creates is worth naming directly. More builders shipping more code faster into less mature infrastructure is a risk, not just an opportunity. The teams navigating this well are the ones that treated the increase in developer productivity as a reason to invest in operational maturity, not as evidence that they no longer needed to.
There is also a newer dimension: AI agents are beginning to interact with deployment infrastructure directly. An agent that can open a pull request and trigger a deployment pipeline needs the same guardrails as a human developer — arguably more explicit ones. The platform becomes the interface not just for engineers but for the software those engineers are increasingly writing to act on their behalf.
Getting that right requires thinking carefully about what the platform allows, what it prevents, and what it makes auditable. These are solvable problems, but they require the platform to be in place first.
If platform engineering is something your organisation is trying to make the case for — or make more effective — I am happy to talk through what has worked in different contexts.