Agree...

Look at “Managing the Development of Large Software Systems” (Royce 1970) Figure 10 on scanned page 338:

https://www.praxisframework.org/files/royce1970.pdf

Whatever you do, do not stop on Figure 2's infamous waterfall!

Understand Royce understood Figure 4, and in Figure 7 proposed prototyping with code to inform the product (and iterate the product).

This was elaborated in the Spiral Model (Boehm 1988):

https://en.wikipedia.org/wiki/Spiral_model#/media/File:Spira...

And then '90s DSDM (under various stripped-down flavors clustered around agile claiming to be True Agile™) turned into basically WGLL spanning 2 decades going into LLMs:

https://en.wikipedia.org/wiki/Dynamic_systems_development_me...

Note that DSDM purports to "fix" cost but not through estimation per se, but rather by flexing the backlog cutoff:

“DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and will not haves to adjust the project deliverable to meet the stated time constraint.”

Cost is just headcount, quality should be in your + user's success criteria, and time is (generally) driven by some real-world requirement (event, opportunity, runway, competition, whatever). Varying scope means you didn't plan and roadmap every task up front.

Most everything since are variations on this, tailoring to the needs of the variant's author.

Doing all of this in text-as-code (Markdown, Mermaid, etc.) makes it machinable. Any number of shops were already doing this in text-as-code before the LLMs, giving them a spec-driven LLM context leg up.