The Loop Collapsed

Every methodology we’ve ever invented was just a workaround for slow computers and expensive mistakes.

Waterfall wasn’t stupid. It was rational.

If building the wrong thing costs six months of work, you’d better spend a long time figuring out what to build before you start. Spec reviews, requirements documents, QA gates, these weren’t bureaucratic inventions of mediocre managers. They were the rational response to a world where mistakes compounded and feedback was glacially slow.

Then agile came along and said: what if we just made the loops faster? Don’t try to get the spec right upfront. Show something working every two weeks. Let the feedback correct you before the cost compounds.

Clever.

Agile’s insight wasn’t about sprints or standups or story points, those are all just mechanics.

The real insight was that

the speed of the loop determines how wrong you can afford to be.

Agile cut the feedback loop from months to weeks. That was a huge deal. But what happens if you cut it further? What happens when the loop collapses entirely?

That’s what’s happening right now.

You can now show a working prototype to a stakeholder, get their reaction, and show them a revised version, not in the next sprint, not tomorrow, but in the same conversation.

The spec being wrong stops being a failure mode. It becomes the expected starting condition. You don’t try to write the right spec. You use the wrong spec to generate the first experiment, show it, watch the client react, update your understanding, and run the next one.

And if your API budget allows it, you can run a hundred experiments simultaneously.

Think about what that means. You’re not iterating. You’re searching. The process looks less like development and more like how evolution works, or how a designer generates twenty rough options before a client meeting.

You produce a population of candidates, the client selects, you breed the next generation. Wrong guesses aren’t waste, they’re signal. The faster you can generate and discard wrong guesses, the faster you converge.

Deep Irony

Everyone assumed waterfall is obsolete. What actually happened is almost the opposite. Waterfall’s structure - specs, quality gates, formal requirements, QA phases turns out to have been right all along. What was wrong with waterfall was never the structure. It was the latency. Months between phases made the whole thing unworkable because the world changed while you were executing the plan.

Compress those phases to hours and the whole structure becomes rational again. Write a spec. Build against it. Run a quality audit. Show the client. That’s a few hours now, not a few months. Do it again. The ceremony that made waterfall feel like a straitjacket dissolves when every phase is done before lunch.

This is what tools like the Quality Playbook are actually pointing at. It’s an AI skill that reads your codebase, derives behavioral requirements, runs a multi-model audit, and produces a formal bug report with TDD-verified patches.

If that sounds like extremely old-fashioned QA, good, because it is!

It’s fifty-year-old quality engineering discipline. The insight is just that AI makes it cheap enough to run on every codebase, every iteration, by the developer themselves, rather than requiring a dedicated QA team and a three-week testing phase.

Faster and parallel

The part that changes everything is the parallel experiments.

Traditional development, even agile, is a single hypothesis at a time. You pick a direction, commit to it for a sprint, show it, adjust. AI lets you run many hypotheses simultaneously.

The constraint is no longer “how fast can we build”, it’s “how many useful variants can a human evaluate before their judgment degrades.”

That second constraint turns out to be pretty small. A client can meaningfully react to maybe three to five variants before cognitive overload sets in. But three to five variants shown same day is infinitely better than one variant shown next week. You’re not limited by build speed anymore. You’re limited by human attention and decision quality, which means the most valuable skill in this world isn’t writing code or even writing specs, it’s designing experiments that maximize the signal you extract from each client reaction.

This is how design has always worked. A good designer doesn’t spec a logo and iterate on it. They sketch twenty options, let the client react, and use the reaction to understand what the client actually wants which is usually different from what the client said they wanted. Software couldn’t work this way before because experiments were expensive. Now they’re not.

Always there are nuances

There are real limits to this. Some experiments have side effects that don’t disappear when you discard them. Anything touching databases, payments, infrastructure, or regulated domains can’t be shown-and-discarded without consequences. The parallelism is bounded by how well you can isolate experiments from each other. And convergence isn’t guaranteed, if you run a hundred experiments that don’t vary the right axes, you get a hundred unhelpful data points and a confused client.

The hard part, the part that doesn’t get automated, is experiment design. Knowing which axes to vary. Knowing how to structure a client interaction so they’re reacting to the thing that matters, not the color of the button.

Knowing when you’ve converged versus when you’re thrashing. That’s judgment, and it remains scarce.

But the ceiling on that judgment used to be constrained by how fast you could execute experiments. Now it isn’t. The developer who can design good experiments and read the signal from client reactions quickly is now operating in a completely different space than the one who can only code fast.

The methodologists will catch up eventually. They’ll name this and give it a framework. There will be consultants(ahem, yours truly) and someone will write a book(yep, working on it).

But the underlying principle is simple: every development methodology ever invented was a strategy for managing expensive mistakes. Make mistakes cheap enough, and the whole apparatus of methodology becomes optional. What you’re left with is just the question:

what’s the fastest way to find out if you’re building the right thing?

The answer, it turns out, is to show it to someone. As many versions as possible. As fast as possible. Today.