The model is no longer the bottleneck. The organisation is.
That is the only sentence worth taking out of Code with Claude 2026. I was at the London edition today. The talks were framed as a coding event. They weren't. Once you strip out the demos and product launches, every serious session was about the same thing. What breaks inside a company when models stop being the constraint.
Lisa Crofoot set up the frame in the opening keynote. Anthropic has shipped eight frontier models in twelve months. The task horizon for an agent has moved from minutes to hours, and the next jump is to continuous, always-on agents that own goals rather than tasks. Jeremy Hadfield's "The capability curve" on the main stage put the doubling on screen. Her line for the developers in the room was the only line that mattered: build for the next model, not the current one. Most companies are doing the opposite.
The flip side of all that capability is that the old bottleneck is loosening. The product playbook of the last decade assumed engineers were the scarce input. Roadmaps were carved to fit capacity. Ideas got binned because nobody could ship them. Niklas Gustavsson, Spotify's VP and Chief Architect, said it plainly on stage. Coding is much less of a bottleneck now. His org ships around 4,500 deployments to production daily across 3,000 engineers. Their PR frequency is up 76 percent following the Opus 4.5 release in November. Most of those PRs are now authored by an agent paired with a developer. Anthropic's own internal number is 200 percent more PRs per engineer.
The interesting question is no longer how fast we can ship. It is which constraint replaces coding. From the summit, I count five. Ranked by what bites first.
One. Review. This quarter.
More code is landing than humans can read. Every org that has tripled output without tripling review capacity is now sitting on a queue that breaks first. PR review was built for a world where humans wrote every line. With agents writing most lines, review queue depth becomes the floor on shipping. If your review process still assumes a human looks at every diff, you are about to fall off a cliff this quarter.
Two. Decisions. This year.
When coding stops being scarce, the constraint moves to what to ship. Alex Kaluzny, Doctolib's CTO, talked about prototyping features in production. What used to take weeks now takes minutes. The result is not faster product. It is too many viable ideas, and a leadership team that cannot tell them apart. Alexander Bricken's "The thinking lever" research talk pointed at the cognitive side of the same problem. Taste, and the willingness to kill ideas, becomes the new floor. We will come back to this.
Three. Identity. 2-year problem.
Identity is the unsolved problem of agent-native systems. An agent spawns another agent, calls a service, writes to a record. Who has permission, what is audited, what does the chain look like. Ruslan Semenov said on the enterprise panel that monday.com is rebuilding its permission model from scratch to treat agents as first-class users. Anthropic's own platform answers the question from the other side: Claude Managed Agents gives each agent a scoped identity rather than borrowing the user's. There is a protocol war coming, and the orgs that wake up to it now will own the standard.
Four. Standardisation. 2-3 year programme.
Spotify spent years pushing engineers onto a smaller set of approved technologies, a single developer portal in Backstage, and lint rules that flag drift from the house pattern. What was a developer experience play turned out to be the strongest moat for AI agents in their codebase. Fragmented code performs worse with Claude. Consistent code performs better. The implication: code got cheap, judgement didn't.
Five. Scaffolding readiness. Continuous.
This is the one Anthropic's own team raised but didn't dwell on. Sid Bidasaria's "Stop babysitting your agents" and Margot van Laar's "The prompting playbook" picked at the same scab from different angles. The harnesses, loops, instructions and tools you built around earlier models are still in your stack. As Claude gets smarter, that scaffolding starts holding it back. Generalised primitives beat bespoke wrappers. I have lived this on my own stack: 28 hooks across my workflows, several already rewritten or retired as newer models needed less of them. If you cannot tell which of your scaffolding still earns its place, you are paying interest on infrastructure that solved last year's problem.
The platform reads the same list
Anthropic's own platform releases this year answer one of these five bottlenecks each, and the agenda lays the mapping out if you read it carefully. Claude Managed Agents speaks to identity: scoped agent identity instead of a borrowed human credential. Ravi Trivedi's "Memory and dreaming for self-learning agents" speaks to review and decisions: agents that retain context can handle judgement calls, not one-shot tasks. Ralph Ramos's "What's new in Claude Code" and Punit Shah's "Getting more out of the Claude Platform" both speak to standardisation: how to keep a codebase consistent enough that the model can reason about it. The releases are not arbitrary. They are a roadmap that tells you where the industry has diagnosed the constraint. The serious money in 2026 is in operating agents at the org level, not in calling them.
But you are not Spotify
The obvious objection is that all of this is survivorship bias. The named orgs in this deck are large. Spotify has around 3,000 engineers, and the enterprise panel featured monday.com, Doctolib and Delivery Hero, all at enterprise scale. Of course they feel the constraint moving. The median fifty-person product team still has coding as its primary bottleneck.
The honest answer is that the bottlenecks scale down. Review becomes who validates one agent's output, not who drowns under a thousand PRs. Identity becomes what your single agent is allowed to do, not an enterprise auth chain. Standardisation becomes how consistent your own code is to the model that reads it. The names change. The constraint moving doesn't. If anything, small teams feel it sooner. There is no platform team to absorb the shift for you.
Where I might be wrong
Every editorial reading puts the author at risk. These are the three checks I would update this read on. If any resolves the wrong way by the date listed, the thesis bends or breaks.
One. If the top complaint in Q4 2026 engineering surveys is still "too many bugs" rather than "too many PRs to review", the review bottleneck didn't bite first.
Two. If by mid-2027 product teams still evaluate themselves on throughput rather than judgement, decisions didn't become the new floor and I heard what I wanted to hear.
Three. If per-token compute pricing reverses in the next twelve months because cloud capacity catches up to demand, "code got cheap" was a window, not the new baseline.
The verdict
Which brings us back to decisions. Of the five, this is the one I would grip first. Not because it is the most technical, but because it is the least automatable. Review, identity, standardisation and scaffolding all eventually get solved by tooling. Vendors will sell you each of them. Decisions will not. Decisions come down to what to do, not how to do it. Judgement, taste and agency are paramount. Without taste, it just becomes slop.
Half-decent agents producing infinite half-decent output is the default future. The teams that win are the ones who can tell which output is worth shipping and which is noise. That is a taste problem, not an engineering problem. And taste, unlike scaffolding, doesn't compound from infrastructure. It compounds from people who have shipped enough work to know what good looks like.
I run a publication pipeline that has shipped 84 consecutive editions. The reason it is still worth reading is not that Claude writes it. It is that I made the decisions a long way back about what good looks like, and those decisions still hold. The pipeline is the easy half.
What to do on Monday
Three moves. Each one takes a day. Almost no org has actually done them.
Audit one process for the new bottleneck. Pick a workflow where Claude already does most of the work, then find the step that is still slow. Nine times in ten it is a human approval, not the work itself.
Name your new bottleneck. Pick one of the five. Make it a named workstream with a named owner. Right now it is nobody's job.
Run one thing your stack couldn't do before this cycle. A prototype in your production codebase. A routine that runs while you sleep. An agent in your slack. The act of trying is the work. I have a voice agent calling restaurants while I am off the laptop. I have a newsletter that assembles itself every Thursday. Both were unviable at the start of this cycle. Both are routine now.
The bottleneck moved. The orgs still optimising the coding bottleneck are buying more seats for a tool that just got cheaper. The constraint moved underneath them.
Move with it. Or optimise the wrong thing.
There is a companion deck to this argument, with the five bottlenecks ranked and visualised: The Bottleneck Moved.