What vibe coding gets right and what it gets dangerously wrong
The right take on vibe coding is not that it is dangerous or that it is a revolution. It is both, depending on where you look. AI coding tools have genuinely changed who can build software. A founder with a product idea and no engineering background can now produce a working web application in a weekend — something that would have required months of learning or thousands of dollars of contract labor five years ago. That is a real and significant shift. At the same time, the tools that make this possible are optimized to produce code that works in the happy path, and the ways in which they consistently fall short are specific, predictable, and fixable if you know to look for them.
What vibe coding genuinely gets right is the speed of the product-building loop. For a founder testing whether a problem is worth solving, the ability to put something real in front of users in days rather than months is a genuine competitive advantage. AI tools are excellent at generating boilerplate, scaffolding standard patterns like authentication flows and CRUD interfaces, integrating well-documented third-party services, and producing working UI components from a description. They are also good at iterating quickly on feedback: "make the button green" and "add a confirmation step before deletion" are both instructions that AI tools handle reliably. For the early-stage validation work that determines whether a startup is worth building, these strengths are exactly what matters.
What vibe coding gets dangerously wrong falls into three categories. The first is the invisible attack surface. AI tools generate code that satisfies the prompt, not code that is hardened against adversarial input. When you ask for a user dashboard, you get a dashboard — but the API routes that serve its data often lack session checks, the forms lack input validation, and the endpoints lack rate limiting. None of these omissions are visible in the UI. The app looks complete because the user-facing path works. The security gaps are only visible to someone who interacts with the app in ways the prompt did not describe.
The second category is database access control. Supabase is the default backend for most AI-built apps, and AI tools know how to write Supabase queries. What they do not automatically do is configure Row Level Security policies, because writing correct RLS requires understanding the app's authorization model — which user owns which data, which roles exist, what each role is allowed to see. The AI tool has no representation of this model unless you explicitly describe it and ask for it. In practice, most AI-built apps launch with RLS disabled on their Supabase tables, which means the public anon key — embedded in their client-side bundle — gives any visitor unrestricted read and write access to the entire database.
The third category is secrets management. AI tools write code that uses environment variables, which is correct. What they do not reliably distinguish is which variables are safe to expose to the browser and which must stay on the server. The NEXT_PUBLIC_prefix in Next.js bundles a variable into client-side JavaScript. AI tools frequently apply this prefix to all Supabase keys, including the service role key, because it makes the integration "just work" during development. In production, it means the most powerful credential in the system is downloadable by anyone who visits the site.
The right response to these gaps is not to stop building with AI tools. It is to treat security as the one layer that requires a separate, intentional check — not because AI tools are bad, but because security requires adversarial thinking that no code generator applies by default. Running a scanner before launch, enabling RLS from the start, and auditing your environment variable scopes are not difficult tasks. They take less than an hour combined. The founders who get hacked in the first month are not the ones who used AI tools to build — they are the ones who assumed the AI had handled everything.