Due diligence on a codebase the founders barely wrote

A new kind of target started showing up in our due diligence work this year: a product with real revenue, a team of three or four, and a codebase largely written by coding agents. The founders directed the work, reviewed some of it, and shipped at a pace that would have taken a team of fifteen a few years ago.

Buyers and funds keep asking us the same question about these deals: is an AI-generated codebase a red flag. Our answer is no. AI-written code is how software gets built now, including by us. The red flag is different, and sharper: nobody on the team understanding the system they are selling. Authorship does not matter. Comprehension does.

What changes when the codebase is AI-generated

Reading a generated codebase is a different exercise, and the first surprise is that it often looks better than hand-written code. Consistent naming, tidy structure, docstrings everywhere. The signals we normally read for care and discipline are now produced by default, which means they no longer carry information. You have to look elsewhere.

The commit history reads differently too. Where a hand-built repo shows the archaeology of decisions, small commits with arguments in the messages, a generated one shows large coherent blocks landing fully formed. The delivery record is still there, but the question it answers changes: not "who wrote this" but "who decided this, and did anyone push back".

The structural risk we look for is incoherence between features rather than within them. Each generated feature is locally clean. Across features, the same problem may be solved three different ways, because each session started fresh and nobody held the architecture in their head. At current size that is cosmetic. At twice the size it is where the bugs will live.

The comprehension test

The core of our audit on these targets is a comprehension test, run with the team, in front of their own code.

We ask an engineer to walk us through a module on the critical path: not what it does, but why it is shaped that way, what invariants it protects, what would break if you changed it. We ask where the trickiest logic in the system lives, and how they know it is correct. When access allows, we go one step further and debug something together: take a real bug from their tracker and watch how they navigate.

The two outcomes are unmistakable. One kind of team navigates instantly. They directed the agents, reviewed the output, rewrote the parts that mattered, and own the system in every sense. The generated code is a productivity story, and a good one. The other kind of team gets lost in their own repository, greps for strings they hope exist, and re-asks an agent to explain the code they are selling. That team has shipped a system it cannot operate, and the gap surfaces at the worst possible moment: the first production incident that the agent cannot solve from the error message.

Test reality and review discipline

Generated codebases usually arrive with excellent test coverage numbers, and the numbers mean less than ever. Agents write tests fluently, but left unsupervised they tend to write tests that assert what the code currently does rather than what the business requires. Coverage is high; the safety net has holes exactly where the requirements were never stated.

So we sample the tests and ask of each: if this behavior were wrong, would this test know. We look for tests that encode business rules in their names and their fixtures, and for the failure cases: what happens on the malformed input, the timeout, the double submission. Then we look at the pipeline around the code, because with agents the process is the quality system: review gates, static checks, the guardrails in CI that make agent speed mergeable. A team generating most of its code with no machine-enforced gates is running on luck, and the security findings tend to confirm it, a pattern we cover in the security profile of AI-generated code.

What it means for the deal

When the comprehension test comes back healthy, we say so, and the generated codebase should not cost the target anything in the negotiation. Velocity with a small headcount is exactly what a buyer wants to acquire.

When it comes back unhealthy, the finding is priced like concentrated technical debt with a twist: the asset includes a system nobody fully understands, and the remediation is not a refactor but a period of supervised learning, the team building the mental model it skipped. That takes months, it competes with the roadmap, and it must survive the departure of whoever holds the largest share of context. On these targets key person risk mutates: the key person is not the one who wrote the code, it is the one who knows which prompts produced it and why.

The overall frame stays the one we apply everywhere in diligence, separating findings that change the deal from cosmetic ones, as laid out in the red flags that actually matter. A generated codebase is neither; it is the new default, and the audit has to test the thing that was always the point: whether the team can operate, extend, and debug the system the valuation is built on. That comprehension test is now a standard part of our technical and AI audit, because within a few years there will be no other kind of codebase to audit.