I don’t know. The edge cases become very clear when coding, because there are explicit and precise guarantees of how the code will behave that you can reason about (or when there aren’t, you know that you are in trouble and code defensively around it, and you can reason about that defensive code), which isn’t the case when vibe coding. When coding, you can prove the code correct in your head, and the edge cases are revealed by that process. But that process isn’t possible with vibe coding, because what exactly a prompt will produce isn’t predictable, and doesn’t have guarantees attached that you can reason about.
Completely agree. My point is that they will start realising it not when vibe coding (as you say, nobody will ask them for clear specifications) but as soon as they will try to use it for more than one happy path demo. Then they will "patch" one case and break another and so on. And then they will probably complain LLM-s are crap at coding, same way some lazy product manager complained before when asked questions that they did not think about ...
I see. Some people have the opinion that the things that are hard about hand-coding remain essentially the same when LLM-coding. They argue that this ensures their employment despite the shift from hand-coding to LLM-coding, and that the necessary expertise and diligence (e.g. appropriate architecture and test coverage) remains the same, and in consequence quality doesn’t suffer. I thought that you were arguing in that direction.