There is a reason it is called vibe coding and not vibe architecting or vibe systems design. I have had better results when I come up with the overall architecture first. Then I'll vibe code to stub out classes and methods, and then vibe code the tests, then vibe code to fill in those stubs, making sure the tests pass. You have to handhold the AI like you would an intern or junior dev.

Trying to vibe code a gcc plugin. That A"I" is worse than the most simple tutorial and I end up reading the gcc docs and headers myself. Ah well, at least I got some training now.