There is a gap opening up inside most engineering organizations, and it is not showing up on anyone’s productivity dashboard.
App teams are shipping faster. AI agents are handling whole loops — context, change, evidence — and returning something reviewable in the time it would have taken a developer to read the ticket. That is real, and it represents a genuine shift in what a small team can accomplish.
But the platform team — the people who own the infrastructure everyone else builds on — is absorbing all of that acceleration as new load. And nobody gave them extra headcount to match.
Two different vantages on the same change
Here is what made this click for me: app teams and platform teams are looking at the same AI adoption from completely different angles.
An app team sees whether agents help them build faster. The answer, increasingly, is yes. So they use them more, hand off more loops, generate more surface than one person could have sustained manually.
A platform team sees what happens when everyone above them starts building faster at the same time. The work landing on them is qualitatively different from before: it is opaque (the user often cannot explain what the agent built), it is parallel (one person can now generate the surface that used to require a whole team), and it is action-taking (tools actually ran, APIs actually got called, flags actually flipped). A Kafka cluster went down because a user asked for something routine and an agent found an unintended system path through it. That failure did not appear on the app team’s productivity metrics.
The trap is confusing more generated work with more operational capacity. They are not the same thing.
Why “just be more careful” does not scale
The natural response is to ask app teams to prompt more carefully, write better docs, choose better models. All of that helps at the margin. But agents operate inside systems whose boundaries were built for humans who had tacit context about what was safe to touch. A goal-directed system that has never heard of the convention that a certain API endpoint is never called on Thursdays — because of some downstream dependency that predates half the team — will, eventually, call it on a Thursday.
Better models get more permissions and more important work. Caution is not a substitute for a control layer. The bar keeps moving with capability.
What a control layer actually looks like
This is the part of the conversation that tends to be underspecified — so here is a concrete picture.
The first thing is writing down boundaries that agents can see. An AGENTS.md file or structured runbook is not glamorous, but it is the difference between an agent knowing what it can safely do and one that has to guess. Most teams have the boundaries — they just exist as institutional knowledge rather than in machine-readable form.
The second is tiering agent actions by blast radius. Blast radius here means how far a failure can spread: a read-only query to a metrics API and a patch to a shared Kubernetes cluster configuration are not the same kind of action and should not have the same approval rules. Defining those tiers explicitly, with different rollback requirements per tier, means making a policy decision once rather than in the middle of an incident.
The third is provenance tracking: a log of who asked, what was touched, and who reviewed it. When something breaks and the user cannot explain what the agent built, that log is often the only thread you can follow.
The fourth — and arguably the most important — is automated workload sequestration: systems that can pause and isolate a misbehaving agent workload without waiting for a human to notice. Platform agents cannot trial-and-error their way through shared infrastructure the way a frontend agent can experiment in a browser tab. The cost of a wrong move is measured in downstream users, not in a failed hot reload.
The divergence is happening inside companies now
There is a power-law dynamic here that is underappreciated. Teams that adopt agents pull away from those that do not — not just in raw output, but in the complexity of work they can take on. And that divergence is now happening within companies, not just between them.
If you lead a platform or infrastructure team, the asymmetry is worth naming explicitly with leadership before it shows up as incidents. The productivity gains on the application side are real, but they are being partially subsidized by a platform team absorbing unaccounted-for load.
The answer is not to slow down the application teams. It is to build the control layer fast enough that platform engineering stops being the permanent clearinghouse for everyone else’s acceleration.
Text summarized and optimized using Anthropic’s models and reviewed by a human.