Your AI-Generated Codebase Is a Liability

If a quarter of Y Combinator startups have codebases that are over 95% AI-generated, we should probably talk about what that means when those companies get acquired, audited, or sued.

AI-generated code looks clean. It follows conventions. It passes linting. It often has reasonable test coverage. By most surface-level metrics, it appears to be high-quality software.

But underneath the polished exterior, AI-generated codebases carry risks that traditional codebases don’t. Security vulnerabilities that look correct. Intellectual property questions that don’t have clear answers. Structural problems that emerge only under stress. Dependency chains that nobody consciously chose.

Your AI-generated codebase might be a bigger liability than you think.

The Security Surface

AI models generate code by pattern-matching against training data. When the training data includes secure patterns, the generated code tends to be secure. When it doesn’t—or when security requires context that the model doesn’t have—the generated code can be vulnerable in ways that look perfectly reasonable.

Plausible Vulnerabilities

The most dangerous security issues in AI-generated code aren’t obvious bugs. They’re code that looks secure but isn’t.

Consider input validation. An AI might generate validation that checks for the most common attack vectors but misses less obvious ones. The code looks like it was written by someone who thought about security—it just wasn’t thought about deeply enough.

Or authentication logic. AI-generated auth code typically follows standard patterns, which is good. But security often depends on nuances: token expiration handling, session invalidation edge cases, race conditions in permission checks. AI code that handles the happy path correctly but misses edge cases creates a false sense of security.

Dependency Risk

AI tools are aggressive about installing dependencies. When you ask AI to solve a problem, it often pulls in a library rather than implementing a focused solution. Each dependency is a potential attack surface.

More concerning: AI tools don’t always choose the most secure or well-maintained dependencies. They choose the ones most represented in their training data, which may include popular-but-deprecated packages or libraries with known vulnerabilities that were discovered after the training cutoff.

Research shows that 54% of self-admitted technical debt in LLM-based projects stems from OpenAI integrations. The dependencies AI chooses aren’t always the dependencies you’d choose.

No Threat Model

Human developers writing security-sensitive code (ideally) work from a threat model. They ask: what are we protecting? Who might attack it? What are the attack vectors?

AI generates code without a threat model. It doesn’t know what threats you face, what compliance requirements apply, or what your risk tolerance is. It produces generically “secure” code that may not address your specific security needs.

The Intellectual Property Problem

This is the liability that most companies don’t think about until it’s too late.

Training Data Contamination

AI models are trained on vast amounts of code, including copyrighted and licensed code. When those models generate output, there’s an open question about whether that output might reproduce or closely resemble copyrighted material.

GitHub Copilot has been the subject of a class-action lawsuit over exactly this issue. The plaintiffs argue that Copilot reproduces copyrighted code from its training data without attribution or license compliance.

If your codebase is primarily AI-generated, you may be unknowingly incorporating code that originates from copyleft-licensed projects. If that code is detected during an acquisition audit or IP review, it could create significant legal complications.

License Compliance

Open source licenses have specific requirements. GPL code requires that derivative works also be licensed under GPL. MIT code requires attribution. Other licenses have their own terms.

AI tools don’t track the provenance of generated code. They don’t know whether a particular pattern was learned from GPL code, MIT code, proprietary code, or a combination. This means you have no way to verify license compliance for AI-generated sections of your codebase.

For companies planning an IPO, acquisition, or significant investment round—where IP due diligence is standard—this is a material risk.

Ownership Ambiguity

Who owns AI-generated code? The developer who prompted it? The company that employs the developer? The AI company that built the model? The authors of the training data?

Legal consensus hasn’t been established. Different jurisdictions are likely to reach different conclusions. In the meantime, companies building primarily on AI-generated code face uncertainty about whether they truly own their most important asset.

Structural Fragility

Beyond security and IP, AI-generated codebases tend to have structural problems that emerge over time.

Inconsistent Architecture

Each AI prompt gets an independent response. The model doesn’t maintain a persistent understanding of your system’s architecture across sessions. The result is code that’s locally consistent (each file or function follows reasonable patterns) but globally inconsistent (different parts of the system follow different patterns, conventions, and architectural approaches).

This is manageable when humans review and refactor. It’s a serious problem when most of the code ships without deep review—which is exactly what happens in heavily AI-generated codebases.

Hidden Coupling

AI-generated code often creates coupling between components that isn’t obvious from reading individual files. The model might use a shared global state, implicit conventions, or indirect dependencies that create fragile connections between otherwise-separate modules.

When you need to change one component, these hidden couplings cause unexpected breakages elsewhere. And because nobody designed the coupling intentionally, nobody knows where to look for it.

Untested Edge Cases

AI code tends to handle the common cases well and the edge cases poorly. The training data contains more examples of common patterns than edge case handling, so the model is better at generating one than the other.

The result: AI-generated codebases that work well under normal conditions but fail under stress, unusual inputs, or unexpected states. These failures emerge in production, not in development, because development testing typically covers common cases.

What to Do About It

If your codebase has significant AI-generated content, here’s what I’d recommend:

Conduct a Security Audit

Don’t assume AI-generated code is secure because it looks secure. Hire a security professional to audit your most critical paths—authentication, authorization, data handling, payment processing.

Pay special attention to input validation, session management, and dependency vulnerabilities. These are the areas where AI code most commonly falls short.

Assess Your IP Position

Before any major business event (fundraising, acquisition, IPO), get a professional assessment of your IP position. This should include:

• Analysis of AI tool usage in your development process
• Assessment of potential training data contamination risk
• Review of dependency licenses
• Documentation of your code’s provenance

This won’t eliminate risk, but it makes you aware of it and demonstrates good faith.

Invest in Structural Review

Periodically review your codebase for architectural consistency. Look for:

• Conflicting patterns across modules
• Hidden coupling between components
• Dependency sprawl (too many libraries doing similar things)
• Inconsistent error handling approaches

A quarterly architectural review can catch structural problems before they become crises.

Maintain Human Understanding

The most important mitigation is ensuring that your team understands the codebase. AI-generated code that’s understood by the team is manageable. AI-generated code that nobody understands is a liability.

Invest in code walkthroughs, documentation, and comprehension audits. Make sure at least one person on your team can explain every critical path in your system.

Track AI Usage

Know how much of your codebase is AI-generated. Track which tools were used, when, and for what purposes. This information is valuable for security audits, IP assessments, and architectural reviews.

It also helps you make informed decisions about where to invest review effort. Critical paths with high AI-generation should get proportionally more review attention.

The Due Diligence Perspective

If you’re an investor, acquirer, or technical evaluator assessing a company with a heavily AI-generated codebase, here’s what to ask:

1. What percentage of the codebase is AI-generated?
2. What tools were used, and what are their IP terms?
3. Has a security audit been conducted specifically for AI-generated code?
4. Does the team understand the code well enough to maintain and extend it?
5. What’s the dependency footprint, and has it been reviewed for vulnerabilities and license compliance?
6. Is there architectural consistency, or does the codebase show signs of patchwork generation?

Companies that can answer these questions clearly are managing the risk. Companies that can’t are flying blind.

The Balance

I’m not arguing against using AI to write code. I’m arguing against ignoring the risks that come with it.

AI-generated code is a tool output, and like any tool output, it needs quality assurance. The building looks great from the outside. But before you move in, you should check the foundation.

The companies that succeed with AI-generated codebases will be those that treat the output with appropriate skepticism—reviewing security, managing IP risk, maintaining structural coherence, and ensuring human understanding.

The companies that fail will be those that trusted the polished exterior without checking what’s underneath.