A founder walked into our studio at lexx.in two Thursdays ago with a working prototype. He built the entire web application in seventy-two hours using an AI coding editor. The user interface was clean, Stripe checkout buttons worked, and user sign-ups saved neatly to a PostgreSQL database on Supabase.
He wanted us to help him scale the infrastructure for his public launch on Product Hunt. Before agreeing to touch his hosting setup, our lead developer ran an automated security scan across the repository.
We found his production Stripe secret key hardcoded into a client-side JavaScript bundle. Anyone opening Chrome DevTools could see his live balance and trigger refunds. His user profile endpoint accepted arbitrary user IDs without verifying the JSON Web Token, meaning any logged-in user could read another customer’s private account records simply by editing a number in the URL.
The code compiled without errors. The product felt fast. But underneath the hood, the application was completely unprotected.
This is the hidden cost of the vibe coding movement in 2026. Prompting an AI model to write software lets you move at breakneck speed, but LLMs generate code that works, not code that defends itself.
Also Read: Claude Opus vs GPT-5.6 Benchmark: Pricing & Real Winner
The common vulnerabilities in AI-generated code
| Vulnerability Type | How the AI Introduces It | Real-World Risk |
|---|---|---|
| Hardcoded API Secrets | Pastes keys into React components instead of .env | Exposed cloud credentials and drained API credits |
| Broken Object-Level Auth | Queries database by ID without checking session ownership | Users can access and alter other users’ private records |
| Unsanitized Database Input | Concatenates raw user input into direct database queries | SQL injection and unauthorized data modification |
| Permissive CORS Settings | Sets Access-Control-Allow-Origin to wildcard (*) to silence errors | Cross-site request forgery and external data exfiltration |
| Phantom Dependencies | Hallucinates npm package names that attackers can register | Supply chain poisoning and remote code execution |
Why coding models make basic security mistakes
Coding models are trained to satisfy user prompts. When you tell an editor agent to “connect user avatars to Amazon S3,” the model picks the shortest path to make the browser show an uploaded image.
It does not automatically add rate limiting to your bucket. It does not sanitize file names against directory traversal tricks. It does not check whether someone could upload a malicious executable file masked as a JPEG. Unless your prompt explicitly demands validation rules, the agent skips defensive code to keep response times fast and token counts low.
Industry research shows that 69% of enterprise repositories using AI coding tools have detected security flaws in generated snippets. The model will happily write code that passes your unit test while leaving the backdoor wide open.
The phantom package problem
Another risk unique to AI-assisted coding is package hallucination. During a refactoring session last month, an AI assistant suggested running npm install react-secure-token-guard to handle session refreshing.
Our developer inspected npm before running the command. The package did not exist. The model had simply hallucinated a plausible name based on thousands of similar libraries in its training weights.
Security researchers track these hallucinated package names. Malicious actors register empty npm and Python packages matching names that popular models frequently suggest. If an unsuspecting developer runs the install command without checking, they pull malicious payload scripts straight onto their local machine and into their deployment pipeline.
Four rules for safely building with AI
1. Never let an AI editor commit directly to production
Keep a human in the loop for every pull request. Even if you cannot write JavaScript from scratch, you can read diffs and verify that sensitive variables like AWS secret keys or database passwords remain in your server environment files.
2. Lock down your database with Row-Level Security
If you use PostgreSQL platforms like Supabase, Neon, or AWS RDS, enable Row-Level Security on every table. RLS enforces access rules at the database engine level, ensuring that even if an AI-generated endpoint forgets to check user authentication, the database rejects unauthorized queries automatically.
3. Run automated SAST scanners on every push
Set up free static application security testing tools in your GitHub Actions pipeline. Tools like Semgrep, Snyk, and GitGuardian scan your code for exposed API keys and common injection patterns in seconds before code deploys to staging.
4. Verify every third-party dependency manually
Before running any package manager install command recommended by an AI assistant, visit npmjs.com or pypi.org. Check that the package has an established release history, verified maintainers, and an active user base.
The verdict for founders and teams
Vibe coding is a legitimate shortcut for prototyping ideas and validating market demand. At lexx.in’s application engineering studio, our developers use AI tools daily to generate boilerplate and test mock data faster.
Treating an AI model as an unchecked software architect, however, creates technical debt that will surface the moment real users enter their credit cards. Use AI to draft the foundations quickly, but verify security configurations before opening your doors to the internet.
