The Bottleneck Moved: How Tech Teams Stay Fast When Agents Write the Code
Coding stopped being the slow step. Across four recent talks, the same pattern shows up: agents can draft changes quickly, and teams then stall on quality, review, trust, and verification.
This is not the same argument as automating a whole company, or as a single verification loop inside one coding product. It is about how a team stays fast once agents are already writing most of the diffs.
Where the time actually goes
Unattended agents make the codebase worse over time. Dexter Horthy, on Beyond Coding and again at the Agentic AI Foundation, walks through SlopCodeBench: models get a greenfield app, then a sequence of features, without the whole problem up front. Failing tests climb. The best models still score in the mid-teens. His warning is practical: do not mortgage the codebase on the hope that next year's model will clean it up. Aim for 2-4x, not 100x. Do fewer things in parallel, and keep a human in the research-design-plan loop for anything that changes architecture.
The review process is often slower than the model. Dario Hamidi of Amp, also on Beyond Coding, says the team ships to production about 50 times a day, and the change that makes that possible is not the agent. It is dropping pull requests and feature branches. He argues even a team that is not using AI can pick up double-digit productivity by merging to trunk, because people then check their own work instead of waiting in a queue built for strangers. The matching constraint is trust: build environments where agents cannot "juggle knives," with short-lived credentials and permissions you would actually approve.
Verification does not scale with generation. IBM's Prompt to Production puts the new bottleneck in one sentence: human verification at AI scale. Planning, impact, and evidence matter more than the first line of code, because a real change also touches tests, config, pipelines, and monitoring. A related IBM piece on IDE vs CLI makes the same point from the toolchain side: the friction is coordinating the work around the code, not typing it.
Specs and evals are the team interface. Guillermo Rauch, in David Ondrej's interview, describes an agentic workflow built on trying many models, personal and company evals, and agents that can review an app or ship a function from a short instruction. The useful bit for a team is not the celebrity setup. It is a shared eval so "which model this week" does not become a private argument.
What to change on Monday
- Split the work. Small, reversible changes can go to a background agent. Anything that changes an abstraction stays in a research-design-plan pass with a human.
- Stop measuring speed by tokens or parallel agents. Measure deploys that did not raise incidents, and keep one priority in flight.
- Move review left. Auto-checks and a trusted environment beat a long PR queue. If you drop pull requests, say what replaces them: trunk, tests, and someone who still reads the diff.
- Write anti-slop rules the agent can see: patterns you will not merge, and a place for user feedback to re-enter the factory.
- Treat verification as the scarce resource. Plan the evidence (tests, flags, a short manual check) before you ask the agent to implement.
The teams that get faster are not the ones with the most agents running overnight. They are the ones who noticed the bottleneck moved, and staffed that step.