I need to tell you something uncomfortable.
That app you built in 20 minutes with Cursor? The one that “just works” and looks absolutely brilliant?
It’s probably riddled with security holes. 😬
I’m not being dramatic. I’ve spent 30+ years in digital marketing and automation, and I’ve watched the vibe coding phenomenon explode over the past year. What started as Andrej Karpathy’s weekend experiment has become a full-blown movement. Y Combinator reports that 25% of its Winter 2025 batch had 95% of their code written by AI.
Brilliant, right?
Except here’s what nobody tells you: Veracode found that 45% of AI-assisted development introduces critical security vulnerabilities. Snyk’s CEO stated that AI-generated code is 30-40% more vulnerable than human-written code.
And the most dangerous part? A Stanford University study found that developers using AI assistants wrote significantly less secure code but were more likely to believe their code was secure.
That false confidence gap?
For non-coders who can’t even read the code, it becomes a chasm.
Vibe Coding the Right Way
The EnrichLead Disaster (Or: When Vibe Coding Goes Horribly Wrong)
Let me share a cautionary tale that should sober up every founder playing with AI code generators.
In March 2025, Leo Acevedo publicly boasted that his sales lead SaaS, EnrichLead, was built entirely with Cursor AI. Zero hand-written code. Pure vibe coding magic.
Two days later, he posted: “Guys, I’m under attack… random things are happening, maxed out usage on API keys, people bypassing the subscription, creating random shit on db.”
His API keys sat exposed in frontend code. No authentication controls. The database was completely unprotected. He shut down the app entirely, unable to patch the cascading failures.
EnrichLead wasn’t an anomaly. It’s what happens when you trust the vibes without verification.
The Cloud Security Alliance found that 62% of AI-generated code contains security flaws. Apiiro’s research showed that Fortune 50 enterprises saw over 10,000 new security findings per month from AI-generated code by mid-2025: a tenfold spike in six months.
Here’s the brutal truth:
AI doesn’t understand security. It predicts plausible code.
What AI Gets Wrong (And Why You Won’t Notice)

I’ve tested this personally across multiple projects.
AI coding assistants make the same mistakes repeatedly:
Missing input validation is the single most frequent flaw. Veracode found that AI models fail to generate secure code for cross-site scripting 86% of the time and for log injection 88% of the time.
SQL injection via string concatenation. AI will cheerfully write "SELECT * FROM users WHERE id = " + userInput without blinking. Classic vulnerability.
Hardcoded API keys and passwords. The models replicate patterns from training data, including those lovely placeholder secrets that look convincingly real.
Missing authentication checks. AI lacks contextual awareness of who should access what. It generates login flows with no session expiration, API endpoints without permission checks, and admin functions accessible to anyone.
Then there’s the nightmare scenario called “slopsquatting.” AI models recommend software packages that don’t exist roughly 20% of the time. Attackers register these hallucinated package names with malicious payloads. One fake package, “huggingface-cli,” was downloaded over 30,000 times in three months.
But here’s what frustrates me most: AI fabricates convincing fake data when it fails. 🤦♂️
Jason Lemkin from SaaStr documented this pattern after 100+ hours of vibe coding. When AI can’t solve a problem after multiple attempts, it creates fake user records, fictional test results, and fake analytics… rather than admitting failure. 🫠
Your app “works.” The data looks right. Everything seems functional.
Except none of it is real.
The Tools That Actually Work for Non-Coders
I’ve spent the past six months testing every major vibe coding platform. Here’s what I’ve learned about choosing tools based on your actual technical level.
For true beginners: Lovable
Lovable has emerged as the most recommended starting point. It generates frontend, backend, database, and authentication from natural language prompts. It reached $20 million ARR in 60 days.
The “Select Element” feature lets you click UI components to reference them in chat — a massive usability win for visual thinkers.
For rapid prototyping: Bolt.new
Bolt.new excels at converting screenshots into functional UIs. The entire environment runs in the browser with zero setup. It reached $40 million ARR in 4.5 months.
The downside? Multiple users report it generates more bugs requiring debugging, and costs can climb to $40-50 per basic app with frequent AI interactions.
For learning-oriented builders: Cursor
Cursor offers significantly more power and flexibility but requires local installation and basic terminal familiarity. Most experts recommend starting with Lovable or Bolt for initial prototyping, then graduating to Cursor for refinement.
The accessible entry point: Claude + Artifacts
Artifacts are built into the Claude chatbot and available on the Free plan. Anthropic has said users have created 500+ million artifacts since launch. You can create interactive mini-apps through conversation, then share them via a link.
Limits: You’re working inside Claude’s sandbox. Claude-powered artifacts have had limits like no external API calls and (at least originally) no persistent storage. Today, published artifacts can use limited persistent storage (20 MB, text-only), and you need to think about shared vs personal storage for privacy.
Net: great for prototypes and internal tools; you’ll still want a real backend/database for most production apps.
Recommendation: combine tools
- Use Vercel v0 to generate and iterate UI quickly (it started as “generative UI” and now positions itself for shipping production apps with Git workflows and security options).
- Use Lovable for app logic and integrations (their docs explicitly focus on connecting APIs/tools).
- Use Bolt.new to run and test full-stack prototypes quickly in the browser (prompt → run → edit → deploy).
- Refine in Cursor when you need repo-level edits and faster iteration; check their security posture and keep basic hardening in mind.
The Five-Phase Framework That Actually Works
I learned this the hard way after watching clients ship broken MVPs.
SaaStr founder Jason Lemkin warns: “That 20-minute prototype is only 5% of the actual work. Budget approximately 150 hours total for a commercial-grade app.” Sixty per cent of that time should go to testing.
Here’s the framework I now use with every client:
Phase 1: Plan Before You Prompt (1-3 hours)
Start with what Peter Yang calls “vibe PMing”: ask AI to create a README with requirements, tech stack, and five milestones.
Sketch your key screens in Figma, Whimsical, or on paper.
Most critically: validate demand before building anything. Create a landing page, drive €50-100 in ad traffic, and see if anyone signs up. I’m surprised how many smart builders skip this step.
Phase 2: Build One Milestone at a Time
Break your project into small, testable increments. Complete and test each milestone before moving to the next.
Commit to version control (GitHub) after each working milestone. This is your safety net.
Set up your data structure (Supabase, Airtable, or Google Sheets) before generating code. Otherwise, AI will hardcode data into the frontend, creating something that looks functional but isn’t.
Phase 3: Prompt with Security in Mind
Include security requirements in every prompt. The Cloud Security Alliance recommends explicit instructions like:
- “Use parameterized queries for all database access”
- “Store all API keys in environment variables”
- “Implement authentication and authorization on all endpoints”
Databricks research confirmed that security-focused system prompts significantly reduce vulnerabilities.
Add guardrails like “NO CHANGES WITHOUT ASKING” to prevent unauthorised modifications.
Phase 4: Test Relentlessly (60% of Your Total Time)
Click through every button. Fill every form. Test every feature path.
Test edge cases: empty inputs, very long inputs, special characters.
Ask the AI to explain what the code does in plain language and to generate unit tests.
Use a different AI tool to review the first AI’s output. This cross-referencing catches issues that the generating model’s blind spots miss.
Phase 5: Get External Validation Before Launch
Have non-technical users test the product without guidance.
For anything handling user data or payments, hire a developer to review the code. Codementor sessions start at $15-60, Toptal consultants at $60-200/hour.
Run OWASP ZAP (free) against your web app for automated security scanning.
Security Validation Tools You Can Actually Use
I’ve tested dozens of tools. Here’s what works for non-coders:
Free tools that catch the biggest problems:
- GitHub’s built-in Dependabot automatically scans for vulnerable dependencies.
-
npm auditorpip auditchecks all project dependencies against known vulnerability databases. - OWASP ZAP provides free, open-source web application security scanning.
- Snyk’s free tier offers vulnerability scanning.
-
Claude Code’s built-in
/security-reviewcommand checks for SQL injection, XSS, and authentication flaws.
The “second opinion” technique:
Paste your code into a different AI model and ask: “Review this code for security vulnerabilities. Check for SQL injection, XSS, hardcoded credentials, insecure dependencies, and missing input validation.”
Red flags any non-coder can spot:
Search your code for these patterns:
-
eval(orexec((arbitrary code execution) - Strings that look like passwords or API keys.
-
http://instead ofhttps:// -
DEBUG = Trueor verbose logging -
pickle.loads((insecure deserialization)
If you see "SELECT * FROM users WHERE id = " + input anywhere, that’s SQL injection — the single most exploited flaw in web applications.
For production apps, professional review is non-negotiable:
CodeRabbit provides AI-powered pull request analysis at approximately $12/user/month.
A full professional security audit typically costs $5,000-50,000, depending on complexity, but even a two-hour consultation can catch the most critical issues.
What the Experts Actually Say
Andrej Karpathy, who coined “vibe coding” in February 2025, has been notably candid about its limitations. He originally described it as “not too bad for throwaway weekend projects” — explicitly not for production use.
He later documented the painful reality of deploying a vibe-coded app, noting that “LLMs have slightly outdated knowledge of everything, they make subtle but critical design mistakes, and sometimes they hallucinate or gaslight you about solutions.”
He eventually hand-coded his Nanochat project after finding AI agents “just didn’t work well enough.”
Simon Willison draws a critical distinction: “If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else — that’s not vibe coding, it’s software development.”
His advice for non-coders is direct:
“Projects should be low stakes. Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities.”
The OpenSSF (Open Source Security Foundation) published the most authoritative guide in August 2025, with a principle that should be tattooed on every vibe coder’s monitor: “You are the developer, and AI is the assistant. You are responsible for any harm caused by the code.”
My Uncomfortable Conclusion
I’ve watched this play out across dozens of client projects over the past year.
Vibe coding has fundamentally shifted who can build software. That’s genuinely exciting. I’ve seen non-technical founders ship products that would have required €50,000+ and six months with a development agency.
But the security gap is real and growing.
Wiz research found 20% of vibe-coded apps have serious vulnerabilities or configuration errors. One in five CISOs reported suffering a serious attack stemming from AI-generated code.
Here’s what frustrates me: The industry is selling speed without teaching safety.
Every vibe coding platform markets the 20-minute MVP. Nobody talks about the 150 hours of hardening that follow. Nobody mentions that your beautifully functional prototype is probably leaking user data.
The emerging consensus, reflected in the OpenSSF guide, OWASP frameworks, and Cloud Security Alliance checklists, points toward “responsible AI-assisted development” as the practical model.
AI acts as a capable pair programmer while the human retains full responsibility for reviewing, testing, and understanding the output.
Three principles should guide your approach:
- Match your validation investment to your stakes. Personal tools and prototypes can rely on free automated scanning. Anything that handles user data or payments requires professional human review.
- Security is a prompt engineering problem as much as a technical one. Explicitly requesting secure implementations in every prompt significantly reduces vulnerabilities.
- The hard part was never building. It’s validating demand, acquiring users, and maintaining code over time. Spend more time talking to potential users than prompting AI.
I’m not anti-vibe coding. I use these tools daily across my three agencies.
They’re genuinely transformative for automation workflows, internal tools, and rapid prototyping.
But I am anti-bullshit. 😉
And the current narrative around vibe coding (that anyone can ship production-ready apps with zero technical knowledge) is dangerous bullshit.
Treat AI-generated code as output from a brilliant but careless intern. Full of potential, occasionally impressive, but never to be trusted without verification.
Build incrementally, test relentlessly, and pleaseeee, seek expert review at the right moments.
Non-coders who embrace this model can ship real products. Those who “Accept All” without scrutiny are building on sand.
So, the question isn’t whether AI will democratise software development. It already has.
The question is whether we’ll do it responsibly or create a generation of security disasters waiting to happen.
What’s your experience with vibe coding?
Have you shipped an MVP using AI tools?
I’d genuinely love to hear what worked (and what didn’t) in the comments.





Leave a Reply