It seems to me that most people (myself included) never experienced the actual Waterfall elsewhere than in school curriculum descriptions.

It's a bit funny to see people describe a spec written in days (hours) and iterations lasting multiple weeks as "waterfall".

But these days I've already had people argue that barely stopping to think about a problem before starting to prompt a solution is "too tedious of a process".

To add to this: I've worked on projects that came out of waterfall process, and on projects that came out of too hasty agile iterations.

They both have issues but they are very different. A waterfall project would have inscrutable structure and a large amount of "open doors" just in case a need of an extension at some place would materialize. Paradoxically this makes the code difficult to extend and debug because of overdone abstractions.

Hasty agile code has too many TODOs with "put this hardcoded value in a parameter". It is usually easier to add small features but when coming to a major design flaw it can be easier to throw everything out.

For UI code, AI seems to heavily tend towards the latter.

Preparation is waterfall!!! Just code without instructions, bruv!!!

Documentation gets out of date quickly!!!

I did professional waterfall development and SDD is exactly waterfall. The problem with waterfall was never the time that it took, it is that the spec locks you into a small niche and iterative changes force enormous complexity to keep spec and code consistent.

The problems with waterfall come when much of the project is done and then you discover that your spec doesn't quite work, but the changes to your spec require half the requirements to subtly change, so that it can work at all. But then these subtle changes need to be reflected in code everywhere. Do this a couple of times (with LLM and without) and now your code and spec only superficially look like one another.