🌶️ “Spec-driven development + autonomous agents” is just Waterfall 2.0.

Yes, I'll keep banging on it.

We saw the news that Cursor ran long-running coding agents for close to a week on a single project and ended up with a browser rendering engine from scratch (HTML parser, CSS cascade, layout/rendering, etc.).

And that’s exactly the trap.

Leaders see this and think: “Perfect. We’ll write a big spec, throw it over the wall to agents, and receive finished software.” 😂

That vision is incredibly compelling, I know, especially in large enterprises. It’s the same dopamine hit SAFe gave: certainty, control, predictability, dashboards and the promise of scale.

But here’s my provocation: this paradigm breaks down when applied to an emergent, ambiguous process like product development.

There’s a fundamental problem–solution mismatch.

I don't know how to make that clearer. Even if models keep improving rapidly (which they will), the best-case scenario of spec-first agent factories is:

big design up front
big batches
delayed feedback
high ratio of unused features
“us vs them” fights
and a culture that confuses output with outcomes

🌶️ You don’t get AI-native product engineering. You get a faster waterfall.

The real multipliers come from the opposite shape:

human-in-the-loop as the mechanism (not “overhead”)
small diffs + fast course-corrections
progressive gates + guardrails + CI (an agent harness)
parallel agents, orchestrated by humans, converging early and often

Because in real product work, intent evolves through building. You don’t discover “correctness” by writing a longer spec. You discover it through tight feedback loops.

I wish more leaders understood this and stopped burning energy trying to recreate waterfall with robots.

I also get why they’ll try. It looks very seductive. It just doesn’t match the nature of the work.