When AI Hits a Wall on Large Systems, It's Not Because You Still Need Humans

"AI makes you faster" is a story about small apps — about how many tries you get. On a large system, AI still can't deliver. But not because you need a human. It's because no one in the world has found the right way to use AI at that scale yet. Spec-driven development is just the search, still in progress.

"AI makes development faster." Everyone says it. Half of that is true. The other half trips you up somewhere you probably don't expect.

I spend my days working on a large system. On the side, I also build tiny apps by hand, letting AI do the actual work. Doing both has made one thing very clear: the "AI makes you faster" story only holds up cleanly in the smaller of those two worlds.

Today I want to write, from the inside, about where the line between "faster" and "not faster" actually runs — and what's really happening just past it. Let me put the conclusion first. When AI still stalls on large-scale development, it isn't because you need a human. It's because no one in the world has yet found the right shape for using AI on something big.

AI's real win isn't speed. It's the number of tries.

A mock — a working prototype — isn't an AI invention. Humans have always built them. What AI changed is how fast the mock shows up.

And when it's fast, what changes? People say "you catch mistakes earlier," but that's not quite my experience. The real shift is that the number of attempts you get goes up by an order of magnitude. You don't have to be right on the first shot. If it's wrong, throw it away and build again. Run it as many times as it takes to land. That genuinely changes the texture of building.

But — this only works wholesale up to the size of a small app.

The moment it gets big, winning by sheer iteration stops working.

A small app you can rebuild whole, all at once. So the number of tries converts straight into power.

A large system doesn't work that way. Touch one feature, and the effect ripples out further than you can follow yourself. What's connected to what, and what breaks — if you can't run that impact analysis, you can't rebuild it, and you can barely hold it where it is.

What you need here isn't speed. It's holding the spec's connections in a form where you can trace the impact of a change. And this isn't something AI introduced. It was always necessary, back when humans built everything alone. The only difference is that in a human shop, you could fudge it — keep the connections in a veteran's head.

So the world started hunting for "spec-driven development."

The move to put those connections not in someone's head but into the spec itself is rising right now, led from the US. It's called spec-driven development.

The core is simple. Before you write code, you firm up a structured, behavior-first spec. You set that spec as the single source of truth, and let the AI both implement and verify against it. GitHub's "Spec Kit" and AWS's "Kiro" are the headline examples, and the flow boils down to: what to build, how to build it, cut it into small tasks, then implement. It's the exact opposite of letting AI improvise and drifting off later — so-called "vibe coding."

But that answer isn't proven yet at scale.

Here, let me be honest. Spec-driven development hasn't been proven to work.

Even the people testing it carefully are working with small-to-medium examples. If anything, for a tiny change the spec balloons out of all proportion, and you hear engineers say it's harder to read the pile of generated spec documents than to just read the code. The same spec yields slightly different code each time you run it. You give instructions, and the AI cheerfully skips part of them. People even drag up the history of an earlier method that chased a similar ideal and collapsed under its own weight — warning that an improvement you meant well by can quietly make things worse.

In short, how to use AI at scale is something engineers all over the world are still standing in front of — at the same cliff, stopped.

This isn't a Japan story.

It would be easy to fold all this into "Japanese big companies are just old." Easy, and wrong.

Firming up the spec, keeping the connections traceable — this has nothing to do with country or culture. The demand to make something large run correctly falls equally on every team in the world. Japan just happens to push that demand out into the open, in the shape of institutions and contracts, which makes it an easy specimen to observe. So this probably isn't someone else's problem for your organization either. As long as you carry a large system, the same cliff arrives eventually.

The counterintuitive part

"AI makes development faster" and "but in the end you still need humans" — both, to me, miss the mark.

The first mistakes a story about small-app iteration for the whole story. The second runs deeper. Watching AI stall on something big, people want to relax: see, you still need humans after all. But my premise is the reverse. Sooner or later, AI does it better. What's missing isn't a human's turn — it's that the right shape for using AI on something big, the best practice, simply doesn't exist yet. Firming up the spec isn't a fortress humans hole up in. It's scaffolding, still under construction, for handing the reins to AI cleanly.

So I don't believe "large systems will stay human territory." If anything, I'm suspicious of the urge to believe it. The only thing I don't know is how to hand something this big over to AI — the handoff itself.

I stand in that answerless place every day. Firming up specs, drawing the connections, feeling my way toward a "right way to use AI" that no one knows yet. It's not that I've found the answer. But where the cliff is, and why you fall — that much you can see from the inside. I want to keep an honest record of it.

Next time: take that firmed-up spec into heavily regulated work, and you hit a different wall. Even when you've spelled everything out, if it can't be translated into "the vocabulary of audit," the AI comes to a dead stop. I want to write about that mechanism.

Where in your work is the system that's "too big to rebuild all at once anymore"? How AI can be used there — nobody holds the answer yet. I'd genuinely like to hear about your cliff. The subscribe button is right there.