- they started to realise they didn't have some of the domain knowledge (I specialise in maps/GIS), so couldn't steer it effectively
- they said that the changes it made started to become unstable: while making one change, it would break other things. It got harder and harder to make progress.
I suspect the second problem wouldn't happen as soon (or maybe not at all) with an experienced dev running the process.
I think that fast prototyping followed by a rewrite (in case the prototype confirmed the idea works) is the best use case for vibe coding.
A product person can quickly validate an idea and, once the project is a bit more concrete you can bring in the engineering team and start caring about security, maintenability, scaling and so. A rewrite is almost always the best thing, you can start with a solid foundation instead of spaghetti vibe coded stuff
It'll be interesting to see if that becomes a trend. Just what are people supposed to do with vibe coded codebases...