Let’s Go Chasing Waterfalls

TL;DR: AI flips the economics of software delivery. Code is getting cheap. Ambiguity is still expensive. That doesn't quite mean classic waterfall is back. Discovery is still messy, new product work still needs iteration, and the act part of PDCA still matters. But once the problem is understood, delivery is moving toward short, spec-driven, sequential loops: define, generate, verify, refine, repeat. The big shift is that the spec is becoming the primary artifact of software development.

For the last 20 years, most software process was built around one assumption:

Creating software is slow and expensive.

So we optimized for human throughput:

• lighter requirements

• shorter planning cycles

• more conversation

• less documentation

• more sprint ceremony

That made sense.

Humans are slow to implement. Humans are good at filling in gaps. Agile was a rational response to that world.

AI changes the cost structure.

Implementation gets cheap. Ambiguity stays expensive.

The bottleneck moved

A human developer can take a fuzzy ticket, ask questions, infer intent, and make judgment calls.

An agent will also fill in the blanks.

Both are a problem.

Both will guess the workflow. Guess the edge cases. Guess the architecture. Guess the business rules.

The difference is an agent will do all of that at an unprecedented scale.

So as implementation costs collapse, the cost of not being clear goes up.

That is why so many teams suddenly feel like their process is breaking.

The process did not break, it's been broken.

AI just make it more clear

AI exposes spec debt

Most teams have more spec debt than they realize.

For years, software delivery ran on a hidden layer of secret knowledge:

• unwritten rules

• half-defined requirements

• product decisions buried in Slack

• senior engineers filling in the blanks

• "everyone knows how this works"

Humans could survive that.

Agents can’t.

So all the fuzzy context that used to live in people’s heads now has to be externalized.

That is why this moment feels like a drift back toward structure.

Not because documentation suddenly got cool again.

Because the machine needs a clearer map.

Two kinds of work

This is where the conversation gets sloppy.

There are really two very different kinds of software work.

Discovery

This is new product work.

Finding product-market fit. Learning what users actually need. Figuring out the shape of the problem.

Here, the spec is unstable by definition.

You do not know the answer yet. That is the work.

AI does not fix that. It does not make product insight free. It does not make uncertainty disappear.

If anything, premature specs become more dangerous, because the machine can now build the wrong thing at high speed.

Delivery

This is known-territory work.

Build this integration. Add this report. Create this workflow. Refactor this system. Implement this already-understood feature.

Here, AI strongly rewards explicitness:

• clear requirements

• narrow constraints

• defined interfaces

• acceptance criteria

• good tests

This is where the move toward waterfalls is real.

And no, that split is not entirely new. Good teams have been separating discovery from delivery for a while.

AI just makes that split impossible to ignore.

Move left, then move

There’s a trap here.

When people hear "the spec matters more," they can hear "spend more time planning."

That is not the point.

Moving left does not mean getting stuck in planning. Especially not planning about planning.

It means learning earlier.

The act part of Plan-Do-Check-Act still matters.

That said, guard against letting the need for specs stifle creativity.

You still do not know everything up front. You still learn by doing. You still need to act.

AI changes the cost of the loop. It does not remove the loop.

That is why implementation becomes part of requirements refinement.

One workflow I like is simple:

Have an agent draft the user stories. Then have the agent implement against them.

You won't get it right, but the attempt is useful.

It surfaces contradictions. It exposes missing edge cases. It forces vague requirements to become concrete. It shows where the stories sound good but do not actually hold up.

So the loop starts to look like this:

requirements → implementation attempt → sharper requirements → architecture review → stronger implementation

That is the shift.

The old model treated implementation as the end of the process.

The new model uses implementation to pressure-test the spec before deeper architectural commitment.

This is still structured. It is still more spec-driven than classic agile. But it is not "spec and pray."

It is fast learning through bounded execution.

And the human still matters most at one key moment: The human decides when the loop stops.

The agent can keep drafting, generating, and refining.

The human decides when the requirements are sharp enough, the tradeoffs are clear enough, and the architecture is stable enough to commit.

Or said another way:

Agents run the loop. Humans navigate to the exit.

Why this starts to look like waterfall

Once the problem is understood, the winning loop starts to look more sequential:

1. define the requirement

2. define the constraints

3. generate the implementation

4. test and verify

5. update the spec

6. repeat

That is not classic agile improvisation.

That is staged execution.

And the better the spec, the better the result.

That is why this feels like a drift back toward waterfall.

But only partially.

Old waterfall failed because the feedback loop was too long.

You planned for months. Built for months. Tested for months. Learned too late.

AI compresses the loop.

Now you can write a tighter spec, generate a working implementation quickly, inspect it, revise the spec, and rerun the cycle the same day.

So yes, the shape looks more waterfall-like:

• more upfront clarity

• more sequencing

• more documentation

• more explicit acceptance criteria

But the loop is compressed.

This is waterfall structure at AI speed.

That is why "micro-waterfall" is the right frame.

The spec becomes the control surface

This is the bigger shift.

In the old model, code was the center of gravity.

Docs drifted. Tickets were approximate. The real truth lived in the codebase and in experienced engineers’ heads.

In the agentic model, that starts to flip.

The spec becomes the control surface.

Not just prose. Stories. Interfaces. Constraints. Acceptance criteria. Tests.

Especially tests.

The tests are often the sharpest part of the spec because they tell the machine what success actually means.

So code starts to look a little more like the compiled output of intent.

That is a bigger cultural shift than most teams are ready for.

Agile theater gets weaker

A lot of "agile" in practice was really just throughput management for human teams.

• story points estimated human effort

• sprints batched human work

• standups coordinated human blockers

• velocity tracked human output

That starts to matter less when implementation is no longer the scarce resource.

The real question stops being:

How long will it take to code this?

And becomes:

Do we actually know what we want?

That is why AI makes so much agile ceremony feel hollow.

Iteration still matters. Feedback still matters. Learning still matters.

But the bureaucracy built around human coding velocity starts to look like theater.

The engineer’s job moves up a level

This does not make engineers less important.

It changes what the job is.

Less:

• hand-writing every function

• translating vague tickets by intuition

• patching missing context through experience

More:

• defining the system clearly

• shaping architecture

• writing sharper specs

• expressing correctness in tests

• reviewing generated output

• deciding what is worth building in the first place

The engineer becomes more architect, editor, verifier, and operator.

Not less technical.

More leveraged.

The real shift

We are not going back to classic waterfall.

But we are moving toward a world where delivery looks more sequential, more constrained, and more spec-driven than the agile era taught us to expect.

That is the part worth saying plainly:

The spec is becoming the primary artifact of software development.

Not because writing docs is fun. Not because planning is the work. Not because discovery got easy.

Because once implementation gets cheap, the bottleneck moves to clarity.

And because the fastest way to improve clarity is often no longer a long meeting.

It is a bounded implementation attempt.

Plan enough to act. Then let the agent act. See what breaks. Tighten the stories, tests, or constraints. Then move forward.

That is not classic waterfall. That is not classic agile either.

It is cheaper learning through faster, smaller, more explicit loops.

So no, we are not fully going back to waterfall.

But we are absolutely moving toward a world where software delivery looks a lot more like high-speed micro-waterfall than most agile teams are ready to admit.