AI changed the mechanics of M&A due diligence. It did not change its purpose. That distinction sounds small until you watch a deal team confuse the two, and then it gets expensive.
The mechanics improvement is real and worth naming plainly. A team can now read every contract in a data room instead of a stratified sample. Extract clauses, rank documents by risk, produce a first-pass overview in hours instead of weeks. And the overview is often clearer than the human version, not just faster, because one machine reading all the documents produces a more even picture than five associates who each read a different slice and each apply slightly different judgment on what to flag. Coverage stops being a budget question.
The Bain 2026 M&A report says AI use among M&A practitioners more than doubled to 45% in 2025, with due diligence the heaviest use area. The same report notes one in five strategic dealmakers walked away from a deal over AI’s anticipated impact on the target. So AI is now both the tool and, increasingly, the subject of the diligence. Fun times.
But the core of the work stayed human. Four things in particular.
1. The question
A model answers what it is asked. It will not raise the thing nobody thought to ask, and diligence is mostly a hunt for unknown unknowns: the clause someone forgot to mention, the dependency nobody documented, the customer concentration that only shows up if you cross two spreadsheets nobody thought to cross.
I wrote about this more generally in Answers Are Cheap. Questions Are the Work. Diligence is that essay’s argument with a wire transfer attached. The person framing the questions is doing the real job. The model is doing the reading.
2. Verification
A confident summary of a clause that isn’t actually in the contract reads exactly like a correct one. Same tone, same structure, same crisp bullet points. This is the failure mode that scales worst, because AI-assisted diligence feels thorough right up until the moment a specific claim gets tested.
The legal profession is already learning this in public. A US federal judge in Oregon imposed $110,000 in fines and fees on two lawyers who filed briefs containing AI-fabricated cases. Courts have rejected, repeatedly, the defence that the AI made the mistake. The signature is on the human. Every material finding in a diligence report needs a person who opened the source document and confirmed it says what the summary claims it says. There is no shortcut here that survives contact with a dispute.
3. Guidance and materiality
Ranking risk is not the same as judging whether a risk is worth the price. Whether a change-of-control clause is a footnote or a deal-breaker depends entirely on the investment thesis. Is the buyer keeping the founders? Rolling the entity into an existing platform? Planning a carve-out in eighteen months?
The thesis lives in a human head. The model doesn’t know it, and honestly you probably don’t want to put it in the prompt anyway. Materiality is judgement work.
4. Responsibility
Signature and liability sit with a person. There is no arrangement, contractual or technical, in which the model is accountable for the number in the model. Reps and warranties are signed by humans. This isn’t philosophy, it’s just how the paperwork works.
The technical diligence part has actually changed the most
Here is where I think buy-side M&A due diligence needs to update fastest, and where a lot of software due diligence templates are stuck in 2021.
AI now writes a large share of new code at many targets. The evidence so far is that it raises variance rather than quality. GitClear analysed 623 million code changes from 2023 to 2026 and found duplicated code blocks up 81%, copy/paste up 41%, cross-file function calls down 35%, refactoring collapsing from 21% of changed lines to 3.8%, and error-masking constructs up 47%. Read that list twice. Less reuse, more duplication, less refactoring, more swallowed errors. That is the shape of a codebase that looks finished on the outside and is expensive on the inside.
Which means the technical questions in a code quality assessment have shifted. The ones I keep coming back to:
- How much of this codebase was AI-generated, and over what period?
- Can the remaining engineers actually explain the parts they didn’t write by hand? Ask them to walk you through a non-trivial module cold.
- Does it build from a clean checkout on a fresh machine, first try? You would be surprised.
- What does the commit history say about churn? Are the same files being rewritten every few weeks?
- What breaks under growth: N+1 queries, unbounded fan-out, cache assumptions that only hold at current scale?
- What breaks under attack: dependency hygiene, secret management, input validation, auth boundaries?
- What breaks when one specific person leaves? Bus factor is not a meme, it’s a line item.
A clean-looking repo with thin tests, generated boilerplate nobody understands, and absent security controls is a post-close rebuild cost. The buyer pays it, whether they price it in or not. That is the acquisition risk that AI-generated code review is actually trying to surface, and it doesn’t go away because the target’s engineering leader says “we use Copilot, we’re very productive.” Productivity of what, exactly.
Post-merger integration risk compounds this. Two codebases with high AI-generated content and low refactoring discipline don’t merge, they collide. The technical debt shows up as integration debt six months in.
What’s unresolved
I don’t have a clean answer for measuring AI-generated share of a codebase after the fact. Commit patterns hint at it. Style consistency hints at it. Interviewing engineers hints at it strongest. But there is no reliable static analyzer for “was this written by a person who understood it.” If you have one, tell me.
Working with me
I do independent technical due diligence for M&A, buy-side and sell-side, as a fractional CTO. I am based in Eindhoven, the Netherlands, and available worldwide on request. If you’re evaluating a technology asset or preparing one for sale and want a second pair of eyes on the code, the architecture, and the team, I’m reachable via robinverlangen.nl.