DEV Community: Paschal Ugwuanyi

I Scanned Hundreds of AI-Generated Codebases. Here's What Keeps Showing Up.

Paschal Ugwuanyi — Sun, 29 Mar 2026 11:40:33 +0000

I Scanned Hundreds of AI-Generated Codebases. Here's What Keeps Showing Up.

There's a moment every vibe coder knows.

You've been building for six hours straight. Cursor has been finishing your sentences. The app actually works , you can click through it, the data saves, the auth flow runs. You push to production feeling like you've unlocked a cheat code for software development.

Then a user emails you.

Or worse , they don't. They just leave.

I've spent the last several months doing something most developers skip: scanning AI-generated codebases before they ship. Not after. Before. AI analysis followed by human engineers who know exactly what to look for. And the same vulnerabilities keep appearing not occasionally, not in bad codebases, but constantly, across projects built by smart people using the best tools available.

This isn't a piece about AI being bad. I use AI tools every day. This is about a specific, predictable blind spot one that's costing founders users, trust, and in some cases, their entire product.

Let me show you what I keep finding.

The Problem Isn't That AI Writes Bad Code

That's the misconception worth killing first.

AI coding tools Cursor, Bolt, v0, GitHub Copilot, Claude write remarkably functional code. That's exactly what makes this dangerous. The code compiles. The tests pass if you wrote any. The happy path works beautifully.

But Veracode found that 45% of AI-generated code introduces security vulnerabilities. CodeRabbit found that AI co-authored projects have 2.74× more security issues than human-written code. Forrester projects $1.5 trillion in technical debt by 2027 from AI-generated code alone.

These aren't fringe cases. These are the statistical outcomes of a tool optimized for plausible, functional output not defensive, adversarial-resistant output.

The distinction matters. A lot.

What I Actually Keep Finding

1. SQL Injection The Classic That AI Keeps Reinventing

I see this in probably 60% of codebases with a database layer. Here's what AI generates:

const user = await db.query(
  `SELECT * FROM users WHERE email = '${req.body.email}'`
);

It works perfectly until someone sends ' OR '1'='1 as their email address and reads your entire users table. That string interpolation isn't a style choice. It's an open door.

The parameterized version isn't even harder to write:

const user = await db.query(
  'SELECT * FROM users WHERE email = $1',
  [req.body.email]
);

AI knows this pattern exists. It just doesn't consistently choose it unless you specifically ask and most people don't know to ask.

2. Secrets in Source Code

This one is quiet and catastrophic.

const stripe = require('stripe')('sk_live_424242...');
const db = new Client({ connectionString: 'postgresql://admin:prod-password@...' });

AI completes code based on context and comments. When your comment says // Connect to Stripe and your variable is named stripeKey, it fills in something that looks right. Sometimes it pulls from patterns in your own codebase including things you typed once and deleted.

The secret is now in your source. If it reaches your git history, it's effectively permanent. Secret scanners run on public repos constantly. This is how API keys get harvested within hours of a push.

The .env pattern isn't complicated. It's just not what AI defaults to.

3. Unprotected Admin Routes

app.get('/admin/users', async (req, res) => {
  const users = await db.query('SELECT * FROM users');
  res.json(users);
});

AI generates the route. It works. You test it. You move on.

What's missing: any check that the person hitting /admin/users is actually an admin. Or even logged in. It's not that AI doesn't know about auth middleware it's that you didn't ask for a protected admin route, so it gave you a route that works.

I've seen full user databases exposed this way. Real email addresses. Real data. In apps that had been live for months.

4. File Upload Path Traversal

This one is subtle enough that even experienced developers miss it:

filename = file.filename
file.save(f'./uploads/{filename}')

Looks reasonable. Works in testing. But what if filename is ../../etc/passwd? Or ../app.py? The AI gave you the functionality you asked for. It didn't model what an attacker would do with it.

5. Missing Input Validation Everywhere

app.post('/transfer', async (req, res) => {
  const { amount, toAccount } = req.body;
  await transfer(amount, toAccount);
  res.json({ success: true });
});

What happens when amount is -10000? Or null? Or a string? Or 999999999999?

AI generates the optimistic path the code that works when users do what you expect. It doesn't naturally generate the pessimistic path the code that survives what users actually do.

Why This Keeps Happening (And Why Being More Careful Isn't the Answer)

Here's the structural reality: LLMs are trained to predict what code should look like, not to think like an attacker.

Security thinking is fundamentally adversarial. It requires asking: what could go wrong here? what would someone malicious do with this input? what happens at the edges? These aren't questions an autocomplete model naturally asks. They're questions that come from experience watching things break in production.

The instinct most developers have "I'll just be more careful" doesn't scale. Not when you're shipping fast. Not when you're using an AI tool that generates 200 lines in the time it takes you to review 20.

You need a different layer in your process.

What That Layer Looks Like

After scanning enough codebases to see these patterns become statistical certainties, I built Assayer to do this properly not just with AI, but with the combination that actually works.

Here's how it works:

You connect your GitHub repo. The AI scanner maps your codebase , your stack, your patterns, your actual vulnerabilities and flags every finding with the exact file and line number. Then a human senior engineer reviews what the AI found.

That last part matters. AI catches things fast. Humans understand context. Together they catch what either alone would miss.

You get two paths depending on what you need:

Path A — Review: Full report with exact fix instructions. You implement them.

Path B — Review + Fix: The engineers do the work directly. You ship.

It's not a linter. It's not a generic SAST tool. It's the layer between your AI-built codebase and your real users , staffed by people who think adversarially about code for a living.

The scan is free. Connect your repo here →

(Beta ends April 5 — after that, scans move to a credit system.)

The Checklist (For Right Now, Before You Read Further)

If you have something shipping soon, run through this before you push:

[ ] All database queries use parameterized inputs — no string interpolation
[ ] Passwords are hashed with bcrypt or argon2 — never compared in plain text
[ ] Secrets live in .env files — never hardcoded in source
[ ] Every admin route checks authentication AND authorization
[ ] File uploads sanitize filenames and validate file types
[ ] Every external input is validated before it touches your database
[ ] Error messages don't expose stack traces or internal details to users
[ ] Rate limiting exists on auth endpoints

Most AI-generated codebases fail three or more of these. Not because the developer is careless , because the tool optimizes for different things than this list does.

The Bigger Point

Vibe coding isn't going away. The speed is too good, the leverage is too real. We're not going back to writing everything by hand.

But we're entering a phase where the gap between "the AI wrote it and it works" and "the AI wrote it and it's safe" is becoming expensive. Users are smarter. Attackers are faster. The standards for what a launched product means are going up.

Build fast. That's the point. Just put something between your AI tools and your users that thinks adversarially about what they built.

Your users shouldn't be your QA team.

If you're building on Cursor, Bolt, v0, Replit, Windsurf, or any AI stack run the free scan at Assayer.dev before April 5. Takes about two minutes to connect your repo.

Drop questions or your own AI code horror stories in the comments , genuinely curious what patterns others are seeing.

https://assayer.dev/blog

5 Mistakes That Make Your No-Code Apps Insecure AF

Paschal Ugwuanyi — Sun, 25 Jan 2026 19:57:18 +0000

"You're not a real developer if you use no-code."
Cool. While you're debating that on Reddit, I just launched three products this month.
Here's what nobody tells you: No-code isn't easier—it's faster. But most people use it wrong and wonder why their apps break, get hacked, or never launch.
After 45+ products with Lovable, FlutterFlow, and n8n, here are the mistakes that kill no-code projects.

Mistake #1: Building Without Understanding Basics
The biggest killer.
People think no-code means you can skip fundamentals. Nope.
What people don't know:

Frontend vs backend (where code actually runs)
What APIs do (how apps talk to each other)
Authentication vs authorization (who you are vs what you can access)
Database relationships (how data connects)
Where business logic should live

Why this breaks everything:
Your app is slow because you're loading entire databases on every page. Users can see other people's data because you put all security checks in the frontend. Your authentication breaks because you don't understand sessions.
Real example:
Someone built a dashboard that fetched 10,000 records on every page load. Then wondered why it was slow.
What to learn before building:

Client-server model
Database basics (tables, keys, relationships)
How authentication works
API requests and responses
Basic security principles

You don't need to write code. But you MUST understand how things work.

Mistake #2: Zero Security Planning
No-code doesn't mean no-security.
Common disasters:

API keys visible in frontend code
No row-level security in database
Anyone can call any API endpoint
Client-side validation only
Admin functions exposed to everyone

Real story I fixed:
Someone built a user profile editor. Anyone with browser dev tools could edit ANY user's profile including admin accounts. Why? They thought a hidden button meant security.
Frontend checks aren't security. They're suggestions.
Minimum security checklist:
✅ Use auth providers (Supabase Auth, Clerk, Auth0)
✅ Enable row-level security in your database
✅ Never expose API keys in frontend
✅ Validate everything on the backend
✅ Test with different user roles
The rule: Assume someone will try to break it. Build accordingly.

Mistake #3: Vibing Instead of Planning
Fast tools don't mean zero thinking.
What people do:

Jump straight into building
No data model, just vibes
Change everything halfway through
Rebuild the same thing 3 times

My 90-minute planning template:

Core Problem (15 min)

What's the ONE thing this solves?
Who is it for?
What do they use now?

User Flow (20 min)

Sketch the main path
What happens when things break?

Data Model (40 min) Example for a fitness tracker:
Users: id, email, name
Workouts: id, user_id, exercise, reps, date
Goals: id, user_id, target_weight, deadline
MVP vs V2 (15 min)

What MUST ship first?
What can wait?

Planning saves you from 3 rebuilds.

Mistake #4: Terrible AI Prompting
"I'll just tell AI to build my app."
That's like telling a contractor "build me a house" and expecting your dream home.
Bad prompt:
Build a task manager app
Good prompt:
Build a task manager:

DATA MODEL:

Tasks: id, title, description, status, user_id, created_at
Users: id, email, name

FEATURES:

Add task form (title, description)
Task list showing user's tasks only
Mark done checkbox
Delete button
Filter: all/done/todo

AUTH:

Supabase Auth
Row-level security
Users see only their tasks

UI:

Clean, minimal
Tailwind CSS
Mobile responsive
Primary color: blue-600 The difference: First prompt → AI builds something random Second prompt → AI builds what you actually need 80/20 rule: 80% specific planning, 20% AI generation. AI amplifies your understanding. If you don't know what you want, AI will guess wrong.

Mistake #5: Happy Path Testing Only
What people test:

Perfect user behavior
Everything works scenario

What actually happens in production:

Empty form submissions
50,000 character text inputs
Clicking submit 10 times
Refreshing mid-process
Mobile chaos

Quick testing checklist:
Auth:

Invalid emails?
Wrong passwords?
Accessing protected pages while logged out?

Data:

Empty fields?
Extremely long text?
Special characters?
Multiple form submissions?

Security:

Can users access other users' data?
Can they call admin APIs?
Can they bypass authentication?

The rule: If a user CAN break it, they WILL break it.
Test like your users are chaos agents. Because they are.

How to Actually Build Right
Week 1:

1-2 days planning (data model, flows, MVP features)
Build core feature only
Add authentication
Basic security

Week 2:

Test everything
Break your own app
Fix critical bugs
Mobile responsive

Week 3:

Launch to 10-20 users
Watch what they actually do
Fix urgent issues

Week 4:

Add ONE feature based on feedback
Iterate based on data
Scale gradually

Ship small. Ship secure. Ship fast.

The Truth About No-Code
No-code isn't easier. It's faster.
You still need to understand:

System architecture
Data modeling
Security basics
User experience
Error handling

The difference? You ship in weeks, not months.
While developers are:

Setting up their environment
Configuring Webpack
Debating TypeScript vs JavaScript
Installing 500 npm packages

You're:

Shipping your MVP
Getting real users
Making money
Validating ideas
Iterating fast

Just do it right: Learn the basics. Plan before building. Secure from day one. Test everything.
Next time someone says "no-code isn't real development," ask them:
"How many products did you ship this month?"
Because while they gatekeep, you're building.

Paschal Ugwuanyi Founder @ FlexSphere
No-code Developer
What's your biggest no-code challenge? Drop it in the comments. 👇