A software delivery process built around a small number of engineers writing most of the code by hand has a natural bottleneck: how much a person can type and think through in a day. As AI agents take on a larger share of implementation work, that specific bottleneck loosens, and a different one becomes visible: coordinating the output of multiple agents and people so it adds up to a coherent system rather than a pile of locally-reasonable, globally-inconsistent parts.
That's an orchestration problem, not a coding problem, and it rewards a different skill set. Sequencing which piece gets built before which dependency exists, deciding which changes need human review and which don't, and catching the places where two independently-generated pieces of code make incompatible assumptions about the same shared interface: none of that is solved by a more capable coding model. It's a delivery management problem that gets harder, not easier, as the volume of generated work goes up.
Where the actual scarcity moves
Teams that under-invest here tend to see a specific failure pattern: individually plausible AI-generated changes that pass their own tests, get merged, and then interact badly in ways nobody explicitly reviewed because no single change looked risky on its own. The scarce skill isn't generating the pieces anymore. It's holding a model of how they fit together and catching the places where they don't, before that gap reaches production.
What this changes about team structure
Practically, this argues for investing in the roles that were traditionally under-resourced relative to individual contributors doing the coding: technical leads who hold the cross-cutting architectural picture, and delivery managers who can sequence dependent work across a team producing at higher volume. Those roles don't show up as directly on a burndown chart as a shipped feature does, which makes them easy to under-invest in right up until the integration problems start showing up in production.