When Coding Stops Being the Constraint, Everything Else Becomes Visible
The talk frames Spotify's view that coding itself is no longer the bottleneck in software delivery. Here is my read on what that frame means in practice. If you accept it, most of your tooling investment for the last decade was aimed at the wrong target. The honest engineering question now is what the new constraint actually is, and that answer turns out to be different at every company. Spotify's value as a messenger is that they have actually run the experiment at scale.
Three key takeaways
- If coding is no longer the bottleneck, then optimizing for code production is optimizing for last decade's constraint. The new constraint is upstream: intent specification, system observability, review capacity, and coordination across many teams shipping at once.
- The developer platform has to evolve to treat agents as first-class users. They need auth, discovery, governance, and observability, the same way human engineers do. The platform that supports agents well is the same platform that supports humans well, just rethought.
- Code review is going from a secondary concern to a primary engineering investment. Volume is going up, value per review is going up, and the chokepoint is moving here. Spend platform money accordingly.
The constraint moved, and most teams have not noticed
For the last twenty years, the assumption underneath every developer tool was that the human typing was the limiting factor. IDEs got faster. CI got faster. PR review tools got slicker. Each of these investments made sense because the bottleneck was the human keyboard. Speed up the typing, speed up the delivery.
That assumption is now broken. Agents type fast. They can produce a working PR in minutes that would have taken a senior engineer an afternoon. Coding speed is no longer where the time goes. So where does the time go now?
At Spotify scale, the answer is upstream. The new bottlenecks are intent specification, where someone has to figure out clearly what should be built. System observability, where the team has to understand whether the change actually worked in production. Review capacity, where humans have to evaluate output that is now arriving ten times faster. Coordination, where multiple teams shipping simultaneously have to avoid stepping on each other.
If your tooling investment is still aimed at making coding faster, you are optimizing for a constraint that no longer dominates. The exercise to run with your platform team is simple. Where does an idea actually slow down on its way to production? If the answer is no longer "writing the code," then your tooling priorities need to shift.
Intent as the new bottleneck
The clearest place the constraint has moved is intent specification. With agents in the loop, "what should this code do" is a much larger share of the work than "how should this code be written." The agent can implement almost anything once it knows what to build. The bottleneck is getting to a precise enough specification that the agent's implementation is the right one.
This is a different kind of skill than most engineers have been hired for. It is closer to product thinking, system design, and customer empathy than to algorithm work. The engineers who are most effective with agents are the ones who can write a clear, complete, specific intent. The ones who struggle are the ones who used to thrive on cleverness in the implementation, where the cleverness no longer matters because the agent can produce equivalent implementations on demand.
The tooling implication is real. The developer platform needs to support intent specification as a first-class activity. That means good ways to capture intent, link it to code changes, track its history, and use it as a verification target. Most platforms treat intent as a JIRA ticket that gets closed when the PR merges. That is not enough anymore.
The developer platform has to support agents as users
Spotify built Backstage to give engineers a coherent platform. Auth, service discovery, deploy pipelines, observability, all in one place. The same logic now applies to agents. Agents need a coherent platform, with the same primitives, designed to make them productive rather than dangerous.
What does that look like? Auth that scopes agents to specific permissions, so an agent fixing a bug cannot accidentally call production APIs it should not touch. Service discovery that agents can query the same way humans do, so the agent knows which service owns the code it is about to change. Deploy pipelines that treat agent-produced changes the same as human-produced changes, with the same checks, the same blast radius controls, the same rollback paths. Observability that lets the team see what agents are doing in aggregate, so patterns of failure are visible before they become incidents.
This is the move that most companies have not made yet. They are using agents like consultants: someone gives them a task, they produce output, the output goes through a human-shaped review process. The next step is treating agents like employees of the platform, with the same kind of integration humans have. That requires the platform to be ready, and most platforms are not.
The companies that build this first will have a real edge. Their agents will be safer, more productive, and more aligned with company practice. Their human engineers will spend less time babysitting agent output and more time on the upstream work that actually matters.
Review at scale is the new chokepoint
When agents write code faster than humans can review it, review becomes the bottleneck. Every team at every company is hitting this wall right now. The PR queue grows, the review quality drops, the team starts rubber-stamping changes because they cannot keep up, and the value of review goes to zero.
The patterns that work address this from multiple angles. First, machine-assisted review: tools that pre-screen PRs for obvious issues, surface diffs that need attention, and de-prioritize changes that are low-risk. Second, scoped reviews: not every PR needs the same depth of human attention. Refactoring an internal helper is different from changing a payment flow. Build review queues that route by risk, not just by team. Third, escalation rules: an agent's PR that touches a critical service needs more eyes than an agent's PR that touches a test helper. Encode the escalation in the platform, not in the reviewer's head.
The hardest of these is the last one. Risk classification is a system that takes work to build and to keep accurate. But once it exists, review capacity goes much further. The senior engineers get the high-risk reviews where their judgment matters. The medium-risk reviews are spread across the team. The low-risk reviews are mostly automated. Review stays meaningful because it is allocated where meaning is needed.
If your team is drowning in PR review, the answer is not "review faster" or "review less." The answer is to build a system that allocates review effort proportional to risk. That is a platform investment, and it is overdue at most companies.
The team unit is changing
Spotify's squad model assumed a small group of humans working closely. With agents in the mix, that unit is changing. The squad is no longer four humans. It is four humans plus an evolving capacity of agent help that scales up or down depending on the work.
This shift raises questions that nobody has fully answered yet. Is the squad still the right primitive, or does the team become something more like a person-plus-agents pod? How is agent capacity allocated across teams when the budget is shared? Does a senior engineer manage a team of humans, a team of agents, or both? What does mentorship look like when much of the keyboard work is delegated and the junior engineer is learning from review feedback rather than from writing code?
I do not think there is a single answer here. The right structure depends on the work. For exploratory product work, where the value is in good intent and fast iteration, small human teams with heavy agent help look right. For mature systems where the value is in operational stability and careful changes, larger teams with lighter agent use look right. The interesting work is in giving each team the right shape rather than mandating one structure across the company.
Metrics that survive the shift
DORA metrics still matter. Deploy frequency, lead time, change failure rate, mean time to recovery. These are not invalidated by agents. If anything, they become more useful, because they measure outcomes rather than inputs, and outcomes are what changed least when the tooling changed.
What also matters now is developer experience. Do engineers feel like they are doing work they value, or are they spending their day reviewing agent output they did not ask for? Are they learning, or are they being deskilled? Are they shipping outcomes, or are they shipping volume? These soft metrics used to be hard to defend. They are now central, because the work shifted and the people doing the work need to find meaning in it for the team to function.
The companies that measure both are the ones that figure out the right balance. The companies that only measure DORA see velocity go up and miss the slow collapse of team morale. The companies that only measure satisfaction see morale go up and miss the slow drift in delivery quality. Both signals are needed, and both have to be acted on.
What this means for the next year
If you run a platform team, audit your investment portfolio. How much of it is still aimed at speeding up coding? Move some of that investment to the new constraints: intent capture, system observability, scoped review, agent-as-user platform support.
If you run an engineering org, look at your review system. It is becoming the chokepoint at every company moving fast. Building a real review allocation system is a year of work and worth every quarter of it.
If you are an individual engineer, the work you do is shifting in shape. The keyboard hours are going down. The judgment hours, intent design, system thinking, review, coordination, are going up. The engineers who lean into that shift are becoming much more valuable. The engineers who resist it are becoming less so.
The underlying signal is hopeful. The engineering job is not disappearing. It is changing shape, and the new shape is in many ways more interesting than the old one. The keyboard work was always the means to an end. The end was good systems serving real users. Spotify's framing helps make that change explicit, and gives the rest of us vocabulary to use as we figure out the same shift inside our own companies.
That is the larger move. Stop optimizing for typing speed. Start optimizing for the work that only humans can do well, which turns out to be most of the work that was always supposed to matter most.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Coding is no longer the constraint at Code with Claude London 2026. https://youtu.be/zFslvuvYifQ