Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.
Honestly, even if I did it that way and then threw it all away and wrote the whole thing manually it'd be worth using. Obviously I don't, because once I've figured out how to scope and coach to get the right result it'd be silly to throw it away, but the same value derives from that step regardless of how you follow it up.
In practice this can’t happen because 30 minutes into coding you will find something that nobody thought about.
Sure you can. Mapping out the unknowns (and then having a plan to make each one knowable) is the single most important function of whoever you have designing your architecture.
Up-front architecture isn't about some all-knowing deity proclaiming the perfect architecture from on high. It's an exercise in risk management, just like any other engineering task.
and
> isn't about some all-knowing deity
Seems like a big conflict of your own thoughts.
Or as they say....
> there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.
And pretty much your job as an engineer is to mitigate the risk that poses.
We don't build new architectures in a vacuum. We build on what has worked before in similar situations, and we adapt it to the problem at hand.
That adaptation is an ongoing process - but it's not the same as saying "fuck it, let's vibe-code our architecture"
If their job is basically to generate code to close jira tickets I can see the appeal of LLMs.