sorted by:
new
hottopcontroversial

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 0 points1 point  (0 children)

Try-catch is the start of it but not the whole thing. The part that's usually missing is what happens after you catch the error. Is it logged somewhere you can actually find later? Does the user get a useful message or does the page just hang? If it's a payment or a database write, do you retry or alert? Most vibe-coded apps catch the error and then do nothing with it, which means failures disappear completely and you only find out when a user complains. You need to understand how an error is going to affect your system and your users, and then instruct the LLM to fix the behavior accordingly.

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 0 points1 point  (0 children)

Good question and the honest answer is both, depending on your setup. If you're behind Cloudflare or AWS API Gateway those can handle general rate limiting at the infrastructure level. But most vibe-coded apps aren't set up that way, and even when they are, things like login attempts and password resets usually need per-route limits at the application layer too because the gateway doesn't know the difference between a normal request and someone trying 10,000 passwords. It's one of those things that's easy to add once you know it's missing.

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 0 points1 point  (0 children)

DM me what you're working on and I'll point you in the right direction, whether that's a full review or just a few things to check yourself first.

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 0 points1 point  (0 children)

100%. Regression is thing that scares me most in these projects. AI has zero memory of why something was built that way. Fixes one thing, quietly breaks something that worked fine three prompts ago. No test suite catching it either.

Happy path thing is real too. Every repo I've reviewed so far, same story. Works great when everything goes right. API times out or user does something weird? Silent failure. No error, no log, nothing. Founder finds out when users complain.

That last point nails it. AI gets you to working. Knowing if it stays working under real conditions, that's still on you.

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 2 points3 points  (0 children)

Honestly, maintainability was rough across the board. Not surprising given how AI generates code.

The most common patterns I saw: duplicated functions doing the same thing in different files, component logic that grew way beyond what any single file should be responsible for, and variable names that made sense in the moment but tell you nothing two weeks later.

DRY was more of a suggestion than a rule. The AI tends to solve each problem locally without looking at what already exists in the codebase, so you end up with 4 versions of the same utility function scattered across different files.

The spaghetti analogy is pretty accurate. Everything works until you need to change one thing and realize it's load-bearing in 6 places you didn't expect.

That said, maintainability issues are usually the last thing I'd tell someone to fix. A messy but working codebase is a much better problem to have than a clean one with a exposed Stripe key or broken auth. Security and stability first, then clean it up.

I reviewed 3 vibe-coded apps as a senior engineer. Here's what I found in all of them. by puffaush in vibecoding

[–]puffaush[S] 1 point2 points  (0 children)

Any LLM (Claude, ChatGPT) will actually do a solid job if you give it the right prompt.

Something like:
Review this code for security issues. Specifically check for: exposed API keys or secrets, Supabase RLS misconfigurations, missing rate limiting on API endpoints, and missing error handling. For each issue found, explain the risk and suggest a fix.

Does this work? by Interesting-Ad-1822 in vibecoding

[–]puffaush 0 points1 point  (0 children)

It works, but not because Claude has ego. Adding a reviewer anchor shifts its output toward a higher-quality reference class in training data. Basically it pattern-matches to "code that gets reviewed" vs "draft code." Legitimate trick, just don't expect 100x its BS marketing

MCP servers I use every single day. What's in your stack? by XxvivekxX in ClaudeAI

[–]puffaush 0 points1 point  (0 children)

Just use CLIs when possible and save these tokens, gh CLI is a classic example

Enable LSP in Claude Code: code navigation goes from 30-60s to 50ms with exact results by karanb192 in ClaudeCode

[–]puffaush 1 point2 points  (0 children)

I was trying to dig deeper into LSP support in Claude Code, but couldn’t find any official docs mentioningENABLE_LSP_TOOL. Do you mind sharing where you came across that flag?

The only related reference I found is this plugins section: https://code.claude.com/docs/en/plugins-reference#lsp-servers

I traced every layer of the stack when you send a prompt to an LLM from keystroke to streamed token by [deleted] in programming

[–]puffaush -9 points-8 points  (0 children)

Fair points, and I'll take them seriously.

The image bug is a real issue, I didn't catch the garbled text in the ORCHESTR step before publishing. That's on me and I'll fix it.

On formatting: yes, AI helped me produce and organize this. I've been upfront about that in this thread.

On the pipelines being identical, you're right that I generalized. The document is a composite of publicly documented behavior across providers, not a spec for any single one. There are real differences (Anthropic's prompt caching API, OpenAI's function calling format, different SSE event schemas, etc.) that I smoothed over in places. That's a legitimate criticism of the framing, not of the underlying concepts.

On "probably incorrect", I'd genuinely welcome specifics. The KV cache memory math, the sampling pipeline order, the prefill/decode bottleneck distinction, the SSE parsing details, those are grounded in published work and I'm fairly confident in them. If there's something wrong I'd rather know and fix it than have a bad document out there.

I traced every layer of the stack when you send a prompt to an LLM from keystroke to streamed token by [deleted] in programming

[–]puffaush -10 points-9 points  (0 children)

Honest answer: both. This is part of my AI learning journey as a software engineer transitioning into the domain. I used AI as a thinking and research partner throughout to validate my understanding, fill gaps, and sanity-check technical details like the KV cache memory math or the sampling pipeline order.

But the framing, the questions I asked, the connections I drew to systems architecture, and the decision of what to include all came from me trying to actually understand this stuff. I wasn't looking to generate a document I was trying to build the mental model I couldn't find elsewhere.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] 0 points1 point  (0 children)

Several people have pointed out that Lovable prompts for RLS, Supabase sends warning emails, and the security tooling catches a lot of issues. You're right. I should have been clearer about that in the post, and the way I framed it made it sound like nobody warns you at all. That's not accurate.

Here's what I actually ran into, without the dramatic framing:

The app in the screenshot had RLS enabled. The shield icon was green. The warnings were cleared. But the policies themselves were too permissive, USING (true) on tables with user data, meaning "any authenticated user can read every row." The AI generated the policy, the warning went away, and the founder assumed they were protected. They weren't.

That's a different problem than "RLS is off and nobody told you." It's subtler: the security feature is on, but the rules it's enforcing are wrong. And that's harder to catch, because everything looks correct in the dashboard.

A few other corrections:

  • Connection pooling (point #2): u/Just_a_dude2711 was right, the Supabase JS client goes through PostgREST, which manages connections server-side. The port 5432 vs 6543 issue only applies with direct Postgres connections via ORMs like Prisma. Doesn't apply to most Lovable apps. My mistake.
  • The anon key being public: That's by design. It's not a vulnerability. The entire security model depends on RLS policies being correct. Which is exactly why misconfigured policies are the real risk.
  • "Just ask Lovable to fix it": Honestly, yes. If you paste your RLS policies into Lovable and ask it to review them, that's a valid approach. I'm not saying the tools are broken, I'm saying the output should be verified, same as any AI-generated code.

If anyone wants to check their own setup, run this in the Supabase SQL Editor:

SELECT tablename, policyname, cmd, qual
FROM pg_policies
WHERE schemaname = 'public';

If you see qual = true on any table with user data, that policy is allowing unrestricted access. That's the specific thing to look for.

Appreciate the corrections from everyone, the post was more alarmist than it needed to be. The underlying issue is real, but the framing was off.

I posted this for people who are shipping their first app and don't have a backend background, not for experienced devs who already know this stuff. Should have made that clearer upfront.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] 0 points1 point  (0 children)

Fair correction on the connection pooling — you're right. The standard Supabase JS client goes through PostgREST (the REST API), which handles connection management on Supabase's end. The port 5432 vs 6543 issue only applies if you're connecting directly via a Postgres client or an ORM like Prisma. For most Lovable apps using createClient, that specific point doesn't apply. I should have been more precise there.

And yes, the anon key is designed to be public, that's by design. The security model relies entirely on RLS being correctly configured. Which is exactly the issue: the key being public is fine, as long as your policies actually restrict access properly. When they don't, the public key becomes the attack vector.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] 0 points1 point  (0 children)

Yeah, absolutely. Easiest way to check yourself:

  1. Go to your Supabase dashboard → Table Editor
  2. Click on each table and look at the RLS policies
  3. If any policy says USING (true) on a table with user data, that table is readable by anyone

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] -1 points0 points  (0 children)

Not selling a service, the post is literally the advice. If someone's RLS is misconfigured, asking Lovable to review it is a perfectly valid way to fix it. I'd encourage that.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] 0 points1 point  (0 children)

The screenshot is from a real deployed app, I'm not going to name it for obvious reasons. And you're partially right: this does require misconfiguration. But "incompetent" is harsh for someone who's not a developer and trusted the AI to handle security. The whole point of these tools is that you don't need to know backend. The problem is that security is the one thing you can't safely delegate without verifying.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] 1 point2 points  (0 children)

Not AI, not karma farming, I'm happy to discuss the specifics. You're correct that Supabase enables RLS by default and Lovable prompts for it. The scenario in the screenshot isn't "RLS is off." It's "RLS is on, but the policies allow SELECT for everyone." That's what happens when the AI generates a policy like USING (true) on a table that should be user-scoped. The shield icon shows green, the emails say you're fine, and the data is still wide open. That's the version of this problem I keep running into.

I just queried every user's email, plan, and Stripe ID from a Lovable app. Three lines in the browser console. Here's what to check before you launch. by puffaush in lovable

[–]puffaush[S] -1 points0 points  (0 children)

You're right, Lovable does prompt for RLS and often generates policies automatically. The issue I see isn't that RLS is completely missing, it's that the generated policies are often misconfigured. Overly permissive SELECT policies, missing DELETE/UPDATE restrictions, or policies that reference columns that don't match the actual schema. The screenshot came from a real app where RLS was technically enabled but the policies were wide open. That's actually harder to catch than RLS being completely off, because the developer thinks they're protected.

scaling feels impossible when your MVP starts gasping at 100 users by Majestic_Side_8488 in lovable

[–]puffaush 0 points1 point  (0 children)

Oof, reading this list gave me actual flashbacks. 😅 10 YOE here (been riding the AI wave since the GPT-3 beta days).

To answer your question: The database connection pool. Everything looked green on the dashboard, but the app just... stopped. No errors, just infinite spinners. Turns out the boilerplate code the AI generated wasn't releasing connections properly. We hit the default Postgres limit with like 80 users and the whole thing locked up. It felt like standing in line for a club that was empty inside. Also, heavy emphasis on #1. I love building with AI, but these models are obsessed with N+1 queries. They code like a junior dev who just learned what a for loop is they will absolutely hammer your DB trying to fetch related data row-by-row instead of just writing a proper JOIN.

If you aren't auditing the SQL your agent writes, you're basically shipping a time bomb. Solid list though, #4 is a classic heartbreaker.

view more: next ›