Part 2 of 4 of The Narrow Part Is Moving. Each part has its own short video.

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.

← Part 1 · The full article · Part 3 →

Sources

  • Eliyahu M. Goldratt, The Goal (1984), Theory of Constraints.
  • Osmani, Saboo, Kartakis, The New SDLC With Vibe Coding, Google, May 2026 (p.22).

The panel that argued this series, and who inspired it: the full article.