Problem is, that in everyones' experience, this almost never happens. The prototype is declared "good enough, just needs a few small adjustments", rewrite is declared too expensive, too time-consuming. And crap goes to production.
AI is emerging as a possible solution to this decades old problem.
It's better than houses, IMO - no one moves into the bedroom once it's finished while waiting for the kitchen.
We were deploying new changes every 2 weeks and it was too fast. End users need training and communication, pushback was quite a thing.
We also just pushed back aggressive timeline we had for migration to new tech. Much faster interface with shorter paths - but users went all pitchforks and torches just because it was new.
But with AI fortunately we will get rid of those pesky users right?
Well maybe they were happy but software needs to be updated to new business processes their company was rolling out.
Managers wanted the changes ASAP - their employees not so much, but they had to learn that hard way.
Not so fun part was that we got the blame. Just like I got down vote :), not my first rodeo.
How much is it a problem, really ?
I mean, what are the alternatives ?
How much of a problem it is can be seen with tons of products that are crap on release and only slowly get patched to a half-working state when the complaints start pouring in. But of course, this is status quo in software, so the perception of this as a problem among software people isn't universal I guess.
How about the tons of products we don't even see? Those that tried to do it right on the first try, then never delivered anything because there were too slow and expensive. Or those that delivered something useless because they did not understand the users' need.
If "complaints start pouring in", that means the product is used. This in turns can mean two things: 1/ the product is actually useful despite its flaws, or 2/ the users have no choice, which is sad.
Not saying this happens always, but that's what people want to avoid when they say they are okay with a quick hack if it works.
I would welcome seeing a lesser amount of new crappy products.
That dynamic leads to a spiral of ever crappier software: You need to be first, and quicker than your competitors. If you are first, you do have a huge advantage, because there are no other products and there is no alternative to your crapware. Coming out with a superior product second or third sometimes works, but very often doesn't, you'll be an also-ran with 0.5% market share, if you survive at all. So everyone always tries to be as crappy and as quick as possible, quality be damned. You can always fix it later, or so they say.
But this view excludes the users and the general public: Crapware is usually full of security problems, data leaks, harmful bugs that endanger peoples' data, safety, security and livelihood. Even if the product is actually useful, at first, in the long term the harm might outweigh the good. And overall, by the aforementioned spiral, every product that wins this way damages all other software products by being a bad example.
Therefore I think that software quality needs some standards that programmers should uphold, that legislators should regulate and that auditors should thoroughly check. Of course that isn't a simple proposition...
I think we'll need to see some major f-ups before this current wave matures.
But almost no-one really works like that, and those three separate steps are often done ad-hoc, by the same person, right when the fingers hit the keys.
The promise of coding AI is that it can maybe automate that last step so more intelligent humans can actually have time to focus on the more important first parts.
So we went full circle, again.
Just having requirements and a specification isn't necessarily waterfall. Almost all agile processes at least have requirements, the more formal ones also do have specifications. You just do it more than once in a project, like once per sprint, story or whatever.
Now that agile practitioners have learned that requirements and upfront design actually is helpful, the only difference seems to be that the loops are tighter. That might not have been possible earlier without proper version control, without automated tests, and the software being delivered on solid media. A tight feedback loop is harder when someone has to travel to your customer and sit down at their machines to do any updates.
My feeling is that software developers will need end up working this type of technical consultant role once LLM dominance has been universally accepted.