DEV Community: ridhika Goel

5 Security Holes Every Vibe Coded App Ships With (and the Fix)

ridhika Goel — Wed, 03 Jun 2026 06:15:32 +0000

Vibe coded apps do not fail because the AI writes broken code. They fail because the AI writes the happy path and silently skips the adversarial one. Here are the five holes I see most, mapped to what they actually are and how to close them.

1. Wide open data access (broken object level authorization)

Builders that sit on Supabase or similar often ship with row level security off or permissive. The UI scopes per user, the database does not.

Wrong: rely on client side filtering to keep data private.

Right: enable RLS and write policies so user_id = auth.uid() is enforced at the database, not in the query.

2. Missing function and object level authZ (IDOR)

Authentication is present, authorization is not. The classic tell is an endpoint that trusts a path or body parameter without checking ownership.

Wrong: if (loggedIn) return record(id)

Right: if (loggedIn && record.owner === user.id) return record(id) on every route, including the ones you think nobody will find.

3. Secrets in the client or in git

API keys land in client bundles or get committed. Once public, they are scraped within minutes.

Wrong: keys in frontend env vars shipped to the browser, or committed .env files.

Right: secrets live server side only, in a secrets manager, with the key rotated if it was ever exposed. Proxy third party calls through your backend.

4. Unvalidated input and prompt injection

User input flows straight into the model or the data layer. That is prompt injection on the AI side and injection or XSS on the classic side.

Wrong: concatenate user text into the prompt or query and trust it.

Right: validate and constrain input, parameterise queries, and separate system instructions from user content so user text cannot override your rules.

5. No rate limiting or spend cap (denial of wallet)

Unmetered AI endpoints are a billing time bomb. One script can cost you thousands overnight.

Wrong: assume organic, human traffic.

Right: per user and per IP rate limits, plus a hard spend cap and alerting, configured before launch.

The throughline

Every one of these is the gap between "works when used nicely" and "holds when attacked." No builder closes them for you. They are architecture and ownership decisions, which is the part no 20 minute demo makes.

Full prompt to production checklist coming next.

Ridhika | Prompt to Production

I Tested 5 AI App Builders for What Actually Ships (Not Demos)

ridhika Goel — Tue, 02 Jun 2026 07:10:01 +0000

The "build an app in 20 minutes" demos are real. The problem is they stop at the exact point engineering begins. So I gave five AI builders the same brief and graded them on production reality, not on the first pretty screen.

The brief: signup and login, per user private data, a subscription payment, and an AI feature that must not hallucinate. The four things every demo skips and every real app needs.

What I actually checked under the hood:

Auth. Not "is there a login screen" but is it real authentication and authorization. Can user A reach user B's rows.
Data layer. Is the schema sane. Are there constraints, or just a table the model guessed at.
AI correctness. Is there any grounding, or does the model freely invent facts.
Security. Input validation, secrets handling, and the one everyone forgets, prompt injection.
Cost. What does one request cost, and what happens to that number at a thousand users.

The results, demo score versus ships score, with the builder truth a demo hides:

Lovable 10 / 4. Built on Supabase. The trap: row level security is frequently left permissive or off, so the happy path works while every authenticated user can query every other user's rows. First thing a builder audits is the RLS policy. Edits are also not surgical, a small request can regenerate whole files and silently revert your manual fixes.
Bolt 9 / 4. Runs in WebContainers, a browser based runtime, not your target server. Native deps and some backend behaviour differ from a real deploy, so passing in Bolt is not passing in prod. Token burn is high.
v0 8 / 3. Outputs idiomatic React, Next, Tailwind and shadcn. Genuinely good handoff code, which is exactly the point, it stops at the component boundary. Server actions, data layer and auth are yours to wire.
Replit 7 / 7. Real Postgres, a secrets manager, a shell, readable logs and one click deploy. The closest thing to a real environment. Watch the always on deployment cost and the agent checkpoint usage, neither is free at scale, and defaults are not tuned for load.
Cursor 6 / 8. A VS Code fork operating on your actual repo and git, so every AI diff is reviewable and revertable. Context is manual, it only sees the files you feed it, and rules files matter. No database, hosting or deploy, that stays your stack.

The pattern: demo score and ships score are almost inversely correlated. The tools optimised to impress are not the tools optimised to survive.

The part that matters most: stop the model inventing facts

Wrong: let the LLM decide the answer and hope the prompt holds.

Right: compute the answer deterministically in your backend, then let the LLM only phrase it.

On one product I shipped, the backend calculates the real result and the model is reduced to a narrator. It physically cannot hallucinate the core output. No builder gives you this for free. It is an architecture decision, and architecture is the thing no 20 minute demo makes for you.

The takeaway for engineers: none of these tools ship your app. They generate a starting point. Auth, data integrity, evals, security, cost control and a safe rollout are still yours. I have shipped more than one AI product, and the builder was never the hard part. Use the tool for the 5 percent. Own the 95 percent.

Ridhika | Prompt to Production

How LLMs Actually Work: The Explanation Nobody Else Gives You

ridhika Goel — Mon, 01 Jun 2026 06:55:00 +0000

How to make LLMs deterministic, in plain English. The version I share with founders and product teams before they make decisions worth real money.

You use AI tools every day. But can you explain what happens when you hit send?

Most people cannot. And that gap is costing them. Bad prompts. Broken products. Decisions made on the wrong assumptions.

The Hard Truth

Every LLM explainer out there is written for researchers or so basic it tells you nothing useful. Neither helps you build better products or work with AI more effectively.

This is the version I share with senior leaders, founders, and product teams before they make decisions worth real money.

1. It Is Not a Search Engine. It Is Not a Database. It Is a Prediction Machine.

When you type a prompt and hit send, the LLM is not finding an answer from somewhere. It is predicting the most likely words to follow your input. Based on patterns it learned from billions of documents.

That is the whole process.

Wrong: "The AI knows the answer."

Right: "The AI predicts the most likely answer based on what it has seen."

This changes everything about how you use it. When an AI gives you a wrong answer confidently, it is not broken. It is doing exactly what it was built to do. Predict. Not verify.

2. The Autocomplete Comparison (And Why It Only Gets You Halfway)

You have probably heard the phrase "autocomplete on steroids." It is not wrong. But it misses something important.

Your phone autocomplete learned from your messages. An LLM learned from most of the written internet. Books. Research papers. Code. Billions of examples.

At that scale, the patterns start to look a lot like real thinking. Not because the model understands in the way you do. Because it has seen so much that it can predict what a good answer looks like.

When I was building AstroNayak I fed Vedic astrology principles into the system prompt. The LLM produced interpretations that genuinely surprised me. It did not know Vedic astrology. It had seen enough of it to predict what a good interpretation would sound like. In practice, that is very useful.

3. The Same Question Can Give You Different Answers

Here is something most people never realise. An LLM is not deterministic. That means you can ask it the exact same question twice and get two different answers.

This is by design. When the model predicts the next word, it is not always picking the single most likely one. It often picks from a range of likely options, with a little randomness added. That randomness is what makes the writing feel natural instead of robotic.

But it has a real cost when you are building products.

Wrong: "I tested it once and it worked, so it will always work."

Right: "It gave a good answer once. I need to test it many times to trust it."

This is why you cannot test an AI feature the way you test normal software. Normal code gives the same output every time. An LLM does not. If your product breaks when the answer comes out slightly different, you have a problem you need to design around from day one.

I fixed this for AstroNayak readings. Here is how.
Most AI astrology tools ask an LLM to guess your chart. AstroNayak does not as the Vedic astrology rules are deterministically coded in the backend, so the AI only interprets what the engine has already calculated. No hallucinated planets. No invented predictions. That is where you constrain a model and change it from probabilistic to deterministic.

4. Context Window: The Most Misunderstood Idea in AI

The context window is everything the model can see at one time. Think of it as short term memory, not long term memory. When a conversation goes past the limit, earlier parts disappear completely.

This is why:

LLMs forget things you said earlier in long conversations
You need to give the model your documents directly if you want it to use them
Bigger context windows cost more because every word gets processed

Wrong: "The AI should remember what I told it last week."

Right: "Memory does not exist by default. It is something I have to build in."

Every AI product that broke because "it forgot the instructions" is a context window problem. Not a model problem.

5. Why It Makes Things Up (And Why That Will Not Change)

Everyone calls it hallucination. A better way to think about it is this. The model made a confident prediction without real facts to back it up.

The model is built to produce clear smooth text. It has no built in signal that says "I do not know this." So when you ask about something it has not seen enough of, it produces the most likely sounding answer anyway.

The fix is not a better model. The fix is how you build around it.

Give the model the facts you need it to use
Ask for structured outputs so it cannot wander away from the answer
Add checks that catch wrong answers before users see them

This is the difference between a prototype and a real product. A prototype trusts the model. A real product does not.

6. What This Means When You Are Building With AI

Five questions I ask before any AI product decision:

What happens when the prediction is wrong? Plan for it now.
What happens when the same question gives a different answer? Test for it. Evals, evals, evals.
What does the model need in front of it to give a good answer? Put that there.
Am I asking it to find something or reason through something? These need different approaches.
Have I defined what a good output looks like? Clear formats reduce almost every failure.

AstroNayak works because I stopped treating the LLM as a mystery box and started treating it as a very capable prediction engine that needs good inputs and clear guardrails.

The Takeaway

LLMs are prediction engines. Not knowledge stores. And they will not give you the same answer twice. Build with that understanding and half your AI product problems disappear before you write a line of code.

Next issue: RAG explained simply. Why every serious AI product uses it and whether you need it.

Ridhika | The AIPM Lab | astronayak.com