The Narrow Part Is Moving

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?

What it looked like from the inside

I can tell you what it looked like in one person’s year, because I’ve just lived it.

In March I started a tournament companion for judo parents: the people sitting in a sports hall, refreshing three websites, trying to work out when their child is on the mat. The scraper and the first live tracker shipped the same day. By September I had a small fleet of agents on one machine. A trip planner whose agents got their names on a family holiday, because the work needed one of them on the road and another at the workbench. A research agent for accounting standards that ran seven research passes and seven independent validation passes and was built, end to end, in a day. In its trial it answered ten of twelve questions correctly, got none wrong, and invented no citations.

Over the same seven months, I published nothing.

That’s not a confession; it’s the data point. The building got cheap. The deciding, the checking, and the telling didn’t. I had a queue of finished things and an empty stage, and the narrowest part of my own pipe had quietly moved from the keyboard to me.

The constraint moves. It never disappears.

There’s an old idea from manufacturing that explains this better than anything written about AI. Every system has one constraint at a time: the stage that sets the pace for everything. Speed up anything that isn’t the constraint and you haven’t made the system faster. You’ve built a queue.

So when the build stops being the constraint, the constraint doesn’t vanish. It moves. Look at where it goes:

Upstream, to deciding. What should we build at all? What does “right” mean for this user, in this organisation, this quarter? A specification used to be a document you handed to a team that would take weeks to find its gaps. Now an agent finds them in minutes, and the specification is exposed as the actual product of thought it always was.
Downstream, to knowing. Is it correct? Did it get there for the right reasons? Google’s paper describes testing splitting in two: checking what the agent built, and checking how it got there, because “a fluent output that skipped its verification steps is a more dangerous failure than one with a visible error.”
Further downstream, to adopting. Will anyone use it? Will the organisation let it live? This is where I’ve spent most of my career, and it 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.

My own machine made all three visible. The agents could build a feature before I’d finished my coffee. What they couldn’t do was decide between two of my own instructions that contradicted each other: one session was told to “leave” some old data, another to “dump, then delete” it, and neither knew about the other. The fix wasn’t a smarter agent. It was a dated list of standing instructions and a rule that conflicts come back to me. The constraint was human direction, and it still is.

On the verification side, the most valuable thing an agent did all summer was notice that its own tool was broken. Mid-flight, on the way home from that holiday, a flight alert arrived with a raw status code where a word should have been. The agent spotted it, checked the flight another way, decided not to alarm anyone, and filed a report. Another agent fixed it during the layover. The test had passed for weeks, because the test was written for the data we expected, not the data the world sent.

That’s what the new constraint looks like. It isn’t typing. It’s knowing.

Cheaper code means more work, not less

In 1865 an economist named William Stanley Jevons noticed something that annoyed the efficiency optimists of his day. Steam engines had become much more efficient with coal. Britain’s coal consumption had gone up, not down. Cheaper work made more uses worth doing.

Code is now on the same curve. When a feature costs a day instead of a month, a whole class of software suddenly becomes worth building: software for problems that never justified a team. A tournament companion for parents. A research agent for one person’s accounting questions. A keeper for a machine that runs a dozen projects. None of these would have existed five years ago, because nobody would have staffed them.

And every one of them arrived with its own deciding, checking and adopting. More software means more specifications, more verification, more organisations deciding whether to trust something new. The work doesn’t disappear. It moves to a different place.

That’s how I read the fear about jobs. The fear assumes a fixed amount of work to be shared out between people and machines. That assumption has been wrong for every general-purpose technology I know of. It will be wrong again, though, as I’ll come to, “wrong on the total” is not the same as “harmless”.

No one gets to stand still

There’s a companion to Jevons that takes the comfort out of it. In 1973 the evolutionary biologist Leigh Van Valen proposed what became known as the Red Queen hypothesis, after Lewis Carroll’s line in Through the Looking-Glass: “it takes all the running you can do, to keep in the same place.” Species don’t get safer by surviving longer, because their competitors keep evolving too.

Everyone is getting the faster engine. The advantage it gives you is real and temporary. What doesn’t equalise is the part that isn’t being commoditised.

Here is my bet, and I’d rather name it as a bet than dress it up as a forecast. Writing code is drifting from craft towards commodity, the way electricity and compute did before it. Models that compete only on getting better at writing code are racing into that commodity. The gains that matter next will come from the stages around the code: specialists that go deep in one domain and check their own work against sources, and generalists that orchestrate, keep the instructions straight, and know when to ask a human.

The research agent I mentioned is the first kind. The keeper on my machine, and the shared improvement flow my projects now run on, are the second kind. Neither is impressive because it writes code quickly. Both are useful because they make the slow parts less slow.

What would prove me wrong? If, a year from now, the teams pulling ahead are the ones with the fastest code generation, and specification and verification have stayed exactly as hard as they are today. I’ll be watching.

The doom maths has Malthus’s shape

Then there are the darker scenarios. AI becomes something only a few can afford. Jobs vanish faster than new ones appear. People despair.

In 1798 Thomas Malthus did the arithmetic: population grows geometrically, food arithmetically, therefore catastrophe. It was a clean chart. It was wrong on the total, because the supply line didn’t stay straight. The fixed denominator was the error, and almost every doom chart since has had the same shape.

But I want to be fair to the doom, because the honest version of it is stronger than the dramatic one. Malthus was wrong about the aggregate and right about plenty of people. Famines happened. Jevons tells you that total demand grows; it says nothing about who gets the new work, or how long the gap lasts. The handloom weavers did not become the factory managers. And access to the most capable models is, today, a dependency most of us don’t control: I’ve watched a vendor swap a model underneath a working system and quietly break its guardrails.

So the total isn’t the risk. The speed and the distribution are. That deserves attention, budgets and policy, not dismissal. It doesn’t change the direction of travel.

Where to?

Red Queen and Jevons will keep us moving. Where to, and what other discoveries, opportunities, or even dangers are in front of us? Time will tell.

And maybe AI could too, so I asked it. Before writing this, I ran the storyline through my Writing Lab: a panel of AI-simulated personas, each built on one real thinker’s published work, set up to argue the piece apart. None of them are real people speaking. They are AI-generated perspectives, and the people who inspired them are credited below.

Three things they argued that I hadn’t seen on my own:

Ezra (constraints theorist, based on Eliyahu Goldratt’s thinking): the biggest risk isn’t the new constraint, it’s inertia. Most of our planning machinery still optimises the old one.
Vera (AI sceptic, based on Gary Marcus’s thinking): the productivity numbers are soft, so don’t lean on any of them. The argument about the moving constraint works with any speed-up greater than zero.
Wren (strategic mapper, based on Simon Wardley’s thinking): model access belongs on the map as a dependency you don’t own, not in a disclaimer at the bottom.

Where I disagree with them is the ending. Vera wanted me to cut “maybe AI could too” as a shrug. I think it’s the point. The narrow part is moving to judgment, and judgment gets better when it’s argued with.

So, a question for you: in your organisation, where is the narrow part going? And is anyone standing there yet?

Sources and credits

Addy Osmani, Shubham Saboo, Sokratis Kartakis, The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering, Google, May 2026 (p.19, p.22, and Figure 5, p.20). Animation A uses Figure 5’s phases and durations.
Eliyahu M. Goldratt, The Goal (1984), Theory of Constraints.
William Stanley Jevons, The Coal Question (1865).
Thomas Robert Malthus, An Essay on the Principle of Population (1798).
Leigh Van Valen, “A New Evolutionary Law”, Evolutionary Theory (1973); Lewis Carroll, Through the Looking-Glass (1871).

The Writing Lab panel for this piece was simulated with AI (Claude). Each persona is built on one thinker’s published work; none of them said any of this, so please read the originals:

Wren (strategic mapper, based on Simon Wardley’s thinking)
Ezra (constraints theorist, based on Eliyahu M. Goldratt’s thinking)
Tomas (economic historian, based on William Stanley Jevons’s thinking)
Lena (evolutionary biologist, based on Leigh Van Valen’s thinking)
Vera (AI sceptic, based on Gary Marcus’s thinking)
Iris (editor, based on Ann Handley’s thinking)
Owen (conversion designer, based on Oli Gardner’s thinking)
Kaja (brand storyteller, based on Paweł Tkaczyk’s thinking)

How the Writing Lab works: the method, and why the personas carry names and credits: The Voices in the Room.