600,000 Lines of AI-Generated Code: What We Found Inside a Production SaaS

We recently reviewed a codebase that was built almost entirely by AI. Not a prototype. Not a side project. A live, paying SaaS platform with real users, Stripe billing, and an enterprise feature set.

The numbers:

• Over 600,000 lines of TypeScript
• Over 25,000 GitHub commits
• Nearly 16,000 messages to the AI builder
• Over 8,000 AI-generated edits
• 100+ database tables
• 100+ serverless functions
• 500+ database migrations
• Built in under 6 months by a solo non-technical founder

By any measure, this is impressive. One person built a production SaaS that would have taken a traditional team 12-18 months and six figures. The UI is polished. The feature set is comprehensive. Users are signing up and paying.

Then we looked under the hood.

The platform dependency nobody talks about

The biggest issue wasn't a bug. It was architecture.

The platform's core product is AI-powered - content generation, analysis, translation, recommendations. Over 30 serverless functions handle AI operations.

Every single one routes through the no-code platform's proprietary AI gateway.

Not OpenAI directly. Not Anthropic. Not any API the founder controls. A gateway URL owned by the platform the app was built on.

This means:

• If the founder ever leaves the no-code platform, all 30+ AI features break instantly
• No control over which models are used, rate limits, or per-request cost
• The platform can change pricing, throttle access, or shut down the gateway at any time
• Zero direct API calls exist anywhere in the codebase. No fallback.

The founder built an entire business on infrastructure they don't control and can't replicate. The AI features ARE the product - without them, the platform is an empty shell. That's not a technical limitation. That's a business risk most founders don't know they're carrying.

Security: the patterns AI always leaves behind

We've reviewed dozens of AI-generated codebases. The same patterns show up every time.

Passwords generated with Math.random()

Two functions generate temporary passwords using Math.random(). Not cryptographically secure - the output is predictable. The fix is one line (crypto.getRandomValues()), but the AI chose the simpler option.

Row-level security that started wide open

The database had RLS enabled with nearly 500 security policies - impressive. But for the first two months, critical tables had policies set to USING (true), meaning any authenticated user could read, modify, or delete any row. The AI eventually generated a security fix migration, but the platform was live with open policies for weeks.

Wildcard CORS on every endpoint

Every serverless function uses Access-Control-Allow-Origin: *. Any website can make requests to the API. For a SaaS handling user data and payments, this should be locked to the platform's own domain.

No payment webhook verification

The platform charges users via Stripe with a checkout flow and customer portal. But there's no Stripe webhook handler to verify payments completed. Credits reset monthly on a cron job regardless of whether Stripe collected the payment. If a card declines, the user could still get their credits.

The testing gap

Over 600,000 lines of code. 2 test files.

Two.

One tests accessibility. One tests a styling utility. Zero tests for:

• Authentication flows
• Payment processing
• Credit deduction logic
• Any of the 100+ serverless functions
• Database operations
• User permissions and role-based access

The AI builds features when you ask for features. It doesn't write tests unless you specifically ask. Most non-technical founders don't know to ask.

Performance: death by fonts

The app loads 11 Google Font families on every page. Roughly 500KB of font files before any content renders. Most pages use one or two. The rest are loaded and never used.

Classic AI pattern - the founder asked for a font change, the AI added it, previous imports were never removed. Multiply by hundreds of iterations.

The 3,000-line function

One serverless function is over 3,000 lines. Another exceeds 1,500. A well-structured function is typically 50-200 lines.

The AI doesn't refactor. It adds. Over thousands of iterations, functions grow into monoliths that no one can safely modify without breaking something else.

What the AI got right

It would be dishonest to only cover what went wrong. The AI built genuinely impressive things:

• Complete multi-role auth with session management and audit logging
• Sophisticated credit-based billing with organisation-level pooling
• Comprehensive RBAC with granular permissions
• A security fix migration that identified and replaced its own overly permissive RLS policies
• Clean component architecture with proper separation of concerns
• Over 120 custom React hooks
• Full internationalisation support

The founder built a platform that competes with products that took years and millions to develop. The AI made that possible.

The uncomfortable truth

AI-generated code is consistently good at the visible (UI, features, user flows) and consistently weak at the invisible (security, performance, testing, architecture, vendor dependencies).

A founder looking at their working app sees a product ready to scale. A developer looking at the same codebase sees a list of things that will break under pressure.

The 600,000 lines work today. The question is whether they'll work when:

• A security researcher finds the wildcard CORS
• A card payment fails and credits still reset
• The no-code platform changes its AI gateway pricing
• A user discovers they can access another user's data
• The 3,000-line function needs a bug fix and changing one line breaks three features

We've seen every one of these happen in production.

What to do about it

Right now (free, takes an hour):

1. Connect your project to GitHub if you haven't already
2. Search your codebase for Math.random in any security context - replace with crypto.getRandomValues()
3. Check your database policies - search for USING (true) and understand which tables are wide open
4. Check if your serverless functions use wildcard CORS - lock it down to your domain

Before you scale:

1. Get an independent security review - not from the AI that wrote the code
2. Verify your payment flow end-to-end. Does a failed payment actually prevent access?
3. Identify your platform dependencies. Can you leave your current provider without losing core features?
4. Add tests for critical paths: auth, payments, and anything that touches user data

Before you raise funding or sell:

1. Any technical due diligence will find these issues. Fix them before investors look under the hood
2. A codebase audit costs a fraction of what these findings would cost you in production

The AI got you to market. That's the hard part. Now make sure what you built can survive contact with the real world.

We audit AI-generated codebases every week. Full version of this article with additional details: inigra.eu/600k-lines-ai-generated-code-what-we-found