I used Lovable, Supabase, and Claude to build a 1,334-challenge coding platform in a few months. Most posts about this kind of build are highlight reels. This one isn't. Here's what actually broke, what the AI confidently got wrong, and the three things I had to rebuild in raw code because no tool would touch them.
The RLS disaster I didn't see coming
Lovable generates Supabase tables fast. What it doesn't do is think about Row Level Security.
I had user progress data leaking across accounts for two weeks before I caught it. Every user could query every other user's challenge completions. The AI had created the tables, the policies even looked right at a glance — but using (true) was the condition on every policy. Wide open.
I stopped building entirely, audited every table, and rewrote all the RLS by hand. Three days. The AI kept regenerating the same broken pattern that caused the problem in the first place.
Lesson: never let a vibe coding tool near your security layer. Write RLS by hand or don't ship.
The curriculum structure I rebuilt twice
1,334 challenges sounds like a lot. The problem is organizing them so users progress logically and completion tracking doesn't fall apart under load.
My first schema had challenges flat in one table. Simple. Wrong.
Around 200 challenges the ordering logic became a mess and queries slowed down. I rebuilt with a node/edge structure — challenges as nodes, dependencies as edges. That's not something Lovable generates naturally. I wrote the migration SQL myself.
Four days gone. Lovable kept suggesting more columns instead of a better structure.
The edge functions the AI refuses to get right
Every time I asked Lovable or Claude to write a Supabase edge function, it produced code that worked in isolation and failed in production. Wrong CORS headers, incorrect Deno import patterns, env variable access that broke on deploy.
I have twelve edge functions running in production. All twelve were rewritten by hand. The AI gave me a useful starting point maybe 40% of the time. The rest it actively misled me — confidently, quickly, and wrongly.
My rule now: write edge functions in raw Deno, test locally with supabase functions serve, and never trust a generated function until it has passed three real deploys.
What vibe coding actually is after doing it at scale
It's not "describe what you want and get a working app." It's closer to: AI writes the 70% that's predictable, you own the 30% that requires real understanding of your stack.
The 30% is always the same three things:
- Security (RLS, auth logic, service role access)
- Data structure decisions that affect everything downstream
- Anything crossing a boundary — frontend → edge function → external API
If you're building something small and throwaway, vibe coding is great. If you're shipping to real users with real data, plan to own those three layers yourself from day one.
What broke in your last AI build? Drop it below — curious whether people are hitting the same walls.
Top comments (0)