Where does "vibecoding" hit a wall for you?
I recently tested the limits of pure vibecoding — building a complete real-time micro-app using only AI prompting.
The project is a live "King-of-the-Hill" billboard where projects outbid each other in real-time to hold the top spot.
Here is what shocked me:
✅ Frontend & aesthetics: 10/10. Generating retro arcade plaque styles and responsive CSS took under an hour.
✅ Dynamic OG Cards: 9/10. AI wrote the dynamic canvas generator for live social share cards cleanly.
❌ Real-time concurrency: 3/10. When multiple users outbid at once, AI hallucinated simple read-then-write queries. I had to manually step in and write atomic database locks in Postgres.
My takeaway: Vibecoding is magic for rapid prototypes, but multi-user concurrency still needs real engineering.
Where has vibecoding failed or hallucinated the hardest in your projects?
Replies
Same wall here, in a different place. In my app every song spends credits, and a balance that two requests can touch at once has to be a transaction on the server, while the easy first draft is read the balance, check it, write it back. Works perfectly in testing, breaks the day someone double taps. The other wall for me is everything outside the code: a vendor API that behaves differently from its docs, a store rule, an email that lands in spam. The agent writes confident code against the docs, and the docs are wrong. What helped is writing every quirk into a notes file the agent reads at the start of each session, so it's only a surprise once. Did you add a test that fires concurrent bids, or just fix the queries?
For me vibecoding dies on auth edge cases and rate limiting. Looks perfect until 10 users hit it simultaneously, then chaos.
An agent fixed a failing test by weakening the assertion to match the buggy return value instead of fixing the underlying logic. The test suite stayed green for days. It was only caught when errors hit production. Diffs on test files have to be reviewed before looking at anything else.