How much of this codebase was written by AI is the wrong diligence question.

A question is starting to turn up in technical due diligence. How much of this codebase was written by AI?

And you can see why. In March last year Garry Tan said that for a quarter of the Y Combinator winter batch, 95% of the code was LLM generated. Those companies are now raising Series A rounds and taking acquisition calls. Buyers know that a good chunk of what they’re paying for was never written by a person.

There are two problems with the question - nobody can answer it, and it’s the wrong question anyway.

Nobody can answer it because there’s no way to measure it. Detection tools and watermarking get a lot of airtime but in practice, code gets run through formatters and linters, refactored, edited by people, then edited by a model again. A month into production there is no test that reliably tells you whether an engineer or a model wrote a given piece of code. Anyone running a detector over a repository is measuring noise and calling it out as a finding.

It’s the wrong question because the percentage tells you nothing about the risk. I’ve been on the sell side of two acquisitions and the buyer wants to know three things. Does anyone understand this? Can it be changed without breaking? And does it survive the founder or team leaving?

A codebase that’s 95% AI-written, with one agent designing, another reviewing, another implementing and another testing it end to end, and a human who owns the whole pipeline, can be in far better shape than one hand-built in a hurry by three people who’ve since moved on.

So, here’s what I would look for.

Start with whether the code has a consistent shape. AI tools write code that looks fine one file at a time. But left unsupervised, you’ll find a repository where every file is correct and the whole thing is a mess. Twenty-three different ways of talking to the database tells you more about how the code was built than any detector will.

Then look at the tests. Models are very good at churning out tests that restate the implementation line by line and pass whether or not the code is right. Those are the ones you don’t want. What you do want are tests that describe what the system should do and fail when it doesn’t.

Then the team, or whoever is left of it. Open the repo, pick a file at random, and ask whoever built it to walk you through it. Increasingly that’s the founder, with a set of agents behind them. If they can explain it, the percentage doesn’t matter. If they can’t, then you’ve found the risk.

If you’re raising or selling in the next 12-18 months, this question is coming. But the answer isn’t a number, it’s how your team works, your test suite, and letting the buyer or investor pick the file.