AI wrote the code. Due diligence asks who understood it.

Something quietly changed in the last two years. AI went from a novelty in your engineering team to the default way code gets written. Ninety per cent of technology professionals now report using AI at work. If your team says they do not, they either have not noticed or are not telling you.

That is not a problem. Fast is good. The problem is that AI has made it possible to produce a codebase far larger than the understanding behind it — and technical due diligence is built almost entirely around testing understanding. A reviewer does not read every line. They pick a few, ask your engineers to explain them, and watch what happens.

So the real risk is not AI-generated code. It is AI-generated code nobody owns. The gap between "we shipped it in a weekend" and "we can defend it in a data room" is where valuations get re-cut and deals occasionally die. The good news is that the gap is measurable, and you can close most of it in a few weeks — long before anyone asks to see your repository.

AI-assisted is now the baseline, not the exception

Ninety per cent of technology professionals report using AI at work, and 84% of developers surveyed by Stack Overflow use or plan to use AI tools. No investor will be shocked that your product was built with AI. What they will notice is a team that cannot say which parts were, or pretends none of it was. Stop treating AI usage as something to hide and start treating it as something to document.

The bugs changed shape, not volume

It helps to separate two things that look identical from the outside. AI-accelerated engineering is a team using AI to write more code, faster, inside a system that still catches mistakes: pull requests reviewed by a human who could be woken at 3am and asked about them, tests running automatically, security scanning in the pipeline, someone owning each part of the system. Unreviewed AI output is code that shipped because it worked when someone clicked the button. Both produce working software and both demo beautifully. The difference only shows up under load, under a security researcher's attention, or under diligence.

The research is unusually clear about where that difference lives. Apiiro's analysis of Fortune 50 repositories found AI-assisted code had 76% fewer syntax errors and 60% fewer logic bugs — genuinely better on the things that used to cause most day-to-day pain — but 322% more privilege-escalation paths and 153% more architectural design flaws. The mistakes a compiler or a junior engineer would catch went down; the mistakes that require someone to think about how the system fits together went up, a lot. Those are precisely the mistakes that do not surface in testing or in a demo, and do surface in diligence.

Veracode points the same way. Across more than 100 large language models and a standardised set of coding tasks, when a model could choose between a secure and an insecure way to do something it chose the insecure option 45% of the time — and this did not improve as models got larger. Functional quality climbed; security stayed flat.

Reviewers are asking a new question

Technical due diligence used to test architecture, team and scalability. It now includes a provenance layer: how much of this was AI-generated, who reviewed it, and can the team explain it. Founders imagine a line-by-line audit, but nobody has time for that. A reviewer samples. They pick two or three non-obvious parts of the system and ask an engineer to explain them, because confident, specific answers are the strongest signal in the whole process and hesitation is the loudest alarm.

Then they look at the shape of your history — not the code, the git log. Are changes reviewed? Are there approvals from someone other than the author? Do commits look like considered work, or like fifteen thousand lines landing at once with the message "updates"? That takes ten minutes and tells them almost everything about your engineering culture. They also look for architectural coherence, because AI is very good at producing four different ways of doing the same thing in four different files. And they test where risk concentrates: if one person is the only one who understands payments or customer data, that is a valuation issue rather than a staffing one.

One further DORA finding is worth sitting with. AI adoption continues to have a negative relationship with delivery stability — not because AI writes unstable code, but because it increases the rate of change, and a higher rate of change exposes whatever is weak in your testing, version control and feedback loops. AI is an amplifier: it magnifies what your organisation already is. From the outside, a stable team and a fragile one both look like "we ship quickly", right up until the incident log is requested. The evidence you need is your test coverage, your review history and your incident record — not a story.

Provenance is the quiet deal-killer

For years, open-source licence compliance was a solved problem in principle: list your dependencies, scan the list, know your obligations. AI broke that. Coding assistants are trained partly on public repositories, including code under GPL, LGPL, AGPL and MPL licences. When a model reproduces a recognisable chunk of that code inside your application, it arrives as your source code — no entry in your package file, no manifest scanner to flag it, and the obligation both real and invisible.

This is not theoretical. Black Duck's audit team analysed 965 commercial codebases, the great majority during acquisitions, and found 56% contained open-source licence conflicts — the highest level they had recorded. Eighty-one per cent contained high- or critical-risk vulnerabilities, and 90% contained components more than four years out of date. In an acquisition, an unmanaged copyleft obligation discovered late is one of the few findings that can genuinely stop a deal, because the remedy may be releasing your proprietary source code. At Series A the consequence is softer — a warranty you would rather not give, a remediation condition, a slightly worse price — but it is still a consequence. Manifest scanning alone no longer proves your licence position; you need code-level scanning too.

The playbook

1. 1
   Write down your AI policy — one page, this week.

   Name the tools your team is allowed to use, what must never be pasted into them (customer data, credentials, private keys), and the review rule: no AI-generated code merges without a named human reviewer. A one-page policy dated six months before your raise is worth far more than a perfect one written the week diligence starts.

2. 2
   Make review history your evidence.

   Turn on branch protection so nothing reaches your main branch without a pull request and an approval. This costs an afternoon and produces the single most persuasive artefact in diligence: a git history showing every change was seen by a person who could be asked about it.

3. 3
   Find out your actual test coverage, then defend the money paths.

   Ask your lead engineer for the current number and do not react to it. Chasing a high overall percentage is theatre. What matters is coverage on the paths that move money, handle authentication and touch personal data. Get those to a level your team would bet the company on, because you are.

4. 4
   Run the three scans everyone else will run.

   A dependency scan for known vulnerabilities, a secrets scan across your full git history rather than just current files, and a licence scan that inspects code rather than only your manifest. All three exist as free or cheap tooling in your build pipeline. Findings you discovered are a maturity signal; findings a reviewer discovered are a negotiating lever.

5. 5
   Do a ten-minute explain test on your riskiest module.

   Pick the part of the system you would least like to lose — billing, authentication, the core algorithm — and ask an engineer to walk you through it without opening the file. If they cannot, that is not a performance issue; it is a concentration risk, and it is exactly what a reviewer will find in week two.

The instinct many founders have is to minimise how much AI they used. That is the wrong move, and transparently so to anyone technical, because the code tells on you. The stronger position is ownership: yes, a large share of this was AI-assisted, here is our policy, our review process, our coverage on the critical paths, our scan results and what we have fixed, and who owns each part of the system. That answer turns AI usage from an unexamined liability into evidence that you run a disciplined engineering organisation at speed, which is exactly what an investor is trying to find out.

The question that decides your round is not how much of your code AI wrote. It is whether a human can still explain it.