Vibe Coding Risks: Security, Quality, and Production Concerns You Cannot Ignore
I found a SQL injection vulnerability in my own AI-generated code after 3 months. It was shipping in production. Here is what I learned about the real risks of vibe coding — and how to fix them before they become incidents.
What are the biggest security risks of AI-generated code?
The AI does not think about security unless you tell it to. I reviewed 40 AI-generated functions from my own projects. 12 had security issues. Hardcoded secrets in 3 files. No input validation in 5 endpoints. Missing rate limiting in all public routes. One endpoint accepted raw JSON and passed it directly to a SQL query without sanitization. That is the SQL injection I mentioned.
The pattern is consistent. AI models are trained on public code repositories where security is often an afterthought. They replicate those patterns. A .cursorrules file with security constraints helps — I added “always sanitize user input” and “never hardcode secrets” to mine. But the AI still misses edge cases. I run a security linter on every AI-generated PR before merge.
My worst find: an AI-generated password reset flow that logged the reset token to the console. Anyone who viewed the server logs could reset any user’s password. The AI did not flag this as a security issue. I did not notice it in my review. A friend found it during a code walkthrough. That was 3 months of exposure.
My security setup: 1) .cursorrules with “always sanitize input”, “never hardcode secrets”, “use parameterized queries”. 2) ESLint security plugin runs on every PR. 3) Manual review of all auth, payment, and data-handling code. 4) Third-party security audit every 3 months. Cost: $0 for the first 3 steps. The audit cost $500 but found 4 issues I missed. Worth every dollar.
Most vibe coding advocates downplay the security risks because they have not shipped anything with real users. I have. Three production apps. Every single one had a security issue I introduced by trusting AI output. The advice “just review the code” is not enough — you need automated scanning AND manual review AND a budget for external audits if you handle real data. If you are building a landing page, fine. If you are building something with user accounts, you need security as a feature, not an afterthought.
How do you catch AI code quality issues before they ship?
I use a three-layer review system. First, the AI reviews its own code — I prompt it to “find 3 potential bugs in the code you just wrote.” It usually finds 2. Second, I review every diff manually. I focus on auth, data handling, and error paths. Third, I write integration tests before I write the feature. The test defines what success looks like. The AI writes code to pass the test. If the test passes, the feature is correct.
The integration test approach saved me most. I wrote a test that said “when user submits invalid email, return 400 with error message.” The AI generated code that returned 500 because it did not validate the email format. The test caught it. Without the test, that would have been a production bug. Write tests first, generate code second. I learned this after my third production bug.
Review the code you just generated. Find exactly 3 potential bugs or security issues. Be specific — mention the line number and the fix. Do not say "this looks good." Assume every function has at least one hidden issue. Focus on: input validation, error handling, race conditions, and hardcoded values.
What are the hidden costs of vibe coding that nobody talks about?
The obvious cost is tool subscriptions — $50-$80/mo for two decent tools. The hidden costs are worse. I spent 6 hours refactoring AI-generated code that had inconsistent architecture. The AI used Express middleware in one file and raw Node HTTP handlers in another. Both worked. But maintaining them was a nightmare.
The biggest hidden cost is technical debt. AI code works today but becomes unmaintainable fast. I had to rewrite an entire API layer because the AI generated 15 different error handling patterns across 30 endpoints. Some returned {error: “message”}, some returned {success: false, msg: “message”}, some just crashed with no error at all. The rewrite took 3 days. I should have set architectural rules in .cursorrules on day one.
My advice: invest 1 hour setting up .cursorrules and project conventions before you write any code. It saves 10 hours of refactoring later. I learned this after my first major rewrite. Now my .cursorrules specifies error format, logging patterns, naming conventions, and test requirements before the AI writes a single line.
When should you not trust AI-generated code?
Trust AI code for CRUD. Trust it for UI components. Trust it for email templates and basic API routes. Do NOT trust it for anything involving money, authentication, security, or real-time data. These are the domains where AI consistently makes mistakes that are hard to catch in review because the code looks correct at first glance.
I have a simple rule now: if I would not let a junior developer ship this code without senior review, I do not let AI ship it without manual review. The AI is a very fast junior developer who occasionally writes insecure code. Treat it accordingly.