Part 1 of 4 of The Narrow Part Is Moving. Each part has its own short video.
For forty years, the narrowest part of building software was the building itself.
Everything else queued in front of it. The ideas, the requirements, the roadmap, the “can we just add one more thing”. And a whole family of roles grew up to manage that queue: product managers, Scrum Masters, delivery leads, agile coaches like me. We got very good at making the slowest stage flow.
That resource is getting less scarce every month. And I think most of us haven’t noticed what that means yet.
The opportunity, plainly
We have just widened the narrowest part of how software gets made. Not by ten percent. By an order of magnitude, on the right kind of work.
Google’s own engineers put it carefully in a paper this May: “AI compresses this cycle dramatically, but unevenly: implementation that once took weeks can now be done in hours, while requirements, architecture, and verification remain stubbornly human-paced.” Their figure comparing the two lifecycles has a caption I keep returning to: same phases, different bottlenecks, different proportions. Under the requirements phase, in the new version, it simply says: specification quality is the new bottleneck.
Read that as a threat and you’ll spend the next two years defending the old neck. Read it as an opportunity and the question becomes much more interesting: if building is no longer the constraint, what is? And what could we do if we took that seriously?
Where the queue is going
The queue won’t disappear. It’s moving to both ends of the pipe, whether most organisations have noticed or not.
- Upstream, to deciding. What should we build at all, and what does “right” mean for this user, this quarter? A specification used to be a document a team needed weeks to find the gaps in. Now an agent finds them in minutes, and the specification shows itself for what it always was: the actual product of thought.
- Downstream, to knowing. Is it correct, and did it get there for the right reasons? Google’s paper splits testing in two: checking what the agent built, and how it got there.
- Further downstream, to adopting. Will anyone use it? Will the organisation let it live? That part hasn’t sped up at all.
Which, for those of us in those roles, is familiar ground. Deciding what to build, and knowing whether it’s right, is close to the work we already do.
In part 2 I’ll show what this looked like in my own year: seven months, a small fleet of agents, and not a single post.
Sources
- Addy Osmani, Shubham Saboo, Sokratis Kartakis, The New SDLC With Vibe Coding, Google, May 2026 (p.19 and Figure 5, p.20). The animation uses Figure 5’s phases and durations.
The panel that argued this series, and who inspired it: the full article.