In agentic workflows, the bottlenecks are definition and review

The bottleneck in agentic coding workflows has quietly moved. It used to be generation - how fast can you get working code out. That part is largely solved: agents produce plausible, often correct, multi-file changes in minutes, and increasingly the generation itself doesn’t even need a frontier model. Smaller, cheaper models handle a lot of implementation fine once the task is well framed.

What’s left over is everything that requires judgment, and it sits on both sides of the generation step.

Upstream, the bottleneck is defining the work. An agent will build exactly what you describe, including the ambiguities, so the quality of the output is capped by the precision of the definition going in. The time I used to spend typing code I now spend deciding what the change should be, what it should explicitly not touch, and how I’ll know it worked - before any code exists. This was always the hard part of software; agents didn’t create it, they just stripped away the implementation work that used to hide it. The industry data points the same way: Agoda’s engineering leadership found that AI raised individual output while project-level delivery barely moved, because coding was never the constraint - specification and verification were.

Downstream, the bottleneck is review: can a human (or another system) verify that the change does what it claims and matches the intent behind the request, without breaking something adjacent. Reviewer attention is the expensive resource now, and it degrades with volume - the tenth diff of the day gets a worse review than the first, regardless of how alert I feel. Agent-written diffs are also harder to review than human ones: there’s no author who already understands the change, so the reviewer is the first person to reconstruct the why.

Between those two, generation is close to free. So the levers worth pulling are on the edges: sharper definitions going in, and output that’s easier to verify coming out. In practice that means smaller, more scoped changes over large sweeping ones, even when the agent could do the sweep in one pass. I write down acceptance criteria before dispatching the task rather than after reading the diff. And I’ve learned to treat a diff that “looks right” with more suspicion than one that’s obviously wrong, because the plausible-but-subtly-broken change is the one that gets through review.

The uncomfortable implication is that agentic coding doesn’t remove the need for careful engineering judgment - it relocates it, to before the code exists and after. You spend less time typing and more time deciding what should be built and whether to trust what got built for you. Teams that treat this as a solved problem because “the agent wrote it and the tests pass” are going to accumulate the kind of subtle correctness debt that doesn’t show up until it’s expensive.