Technical Due Diligence in the AI-Code EraValuing What a Model Wrote

Technical due diligence has always rested on an unstated assumption: that a codebase is roughly proportional to the people and time that produced it. Nobody wrote that down, because it never needed saying. A hundred thousand lines implied a team and a history. Commit patterns implied working habits. A consistent architecture implied someone who held the whole design in their head. Reviewers sampled a codebase precisely because sampling worked — the sample was representative of a process.

That assumption no longer holds, and 2026 is the year it stopped holding at scale. A three-person team using modern AI coding tools can present a codebase that, by every traditional proxy, looks like the output of a thirty-person engineering organisation. It has breadth. It has structure. It has tests. What it may not have — and what no proxy will tell you — is anyone who has read it.

At Frenchy Digital, the Black-owned Los Angeles agency behind this guide, we sit on both sides of this: we run buy-side technical diligence for acquirers and investors, and we do the post-close remediation when the findings turn into work. That combination is the reason this guide contains effort estimates rather than only severity ratings. An assessment that cannot be converted into engineering months and dollars does not help anyone build a deal model.

The first workstream in an AI-era diligence is establishing provenance. Not to penalise AI-generated code — that would be both unfair and economically illiterate, since the speed advantage is real value — but because AI density tells you where to spend your limited review hours. A codebase that is 80% generated in its UI layer and 5% generated in its authorisation layer is a fundamentally different asset from the reverse, at identical overall percentages.

Very few targets can answer the provenance question directly, and the inability to answer it is itself a finding worth recording. Absent a straight answer, the signals stack up quickly:

• Commit velocity against headcount: Diff volume per engineer per week that materially exceeds human throughput, sustained over months. This is the crudest signal and usually the first one visible.
• Diff shape: Large, internally consistent, multi-file commits that land complete rather than evolving across a review cycle. Human features arrive in increments; generated features often arrive whole.
• Stylistic uniformity across authors: Comment density, naming conventions, and error-handling idioms that are identical across modules attributed to different engineers. Human teams are never that consistent without enforcement tooling — check whether that tooling exists.
• Platform artefacts: Configuration, scaffolding, and directory conventions characteristic of Lovable, Bolt.new, v0, Replit Agent, Cursor, or Base44. These are often left in place and are among the most reliable fingerprints.
• Test-suite shape: Exhaustive happy-path assertions with almost no edge-case, failure-mode, or concurrency coverage. Generated tests tend to test that the code does what it does, rather than what the business requires.
• Documentation absence or excess: Either no documentation at all, or unusually complete docstrings on trivial functions alongside no architectural documentation whatsoever. Both patterns indicate generation without editorial ownership.

The output of this workstream is a heat map: AI density by module, overlaid on system criticality. Anywhere those two are both high — generated code in the authorisation layer, the payment path, the data-isolation logic, the billing calculation — is where the rest of the diligence budget goes.

The critical insight for a reviewer is that AI-generated code does not fail more uniformly than human code — it fails in a different distribution. It is generally better than a junior engineer at syntax, at idiom, at boilerplate correctness, and at producing code that runs on the first attempt. It is meaningfully worse at the things that require holding a system's security model in mind: who is allowed to do what, what happens when two requests arrive simultaneously, and what the blast radius is when an assumption turns out to be false.

This matters enormously for diligence method, because the traditional sampled code read is calibrated to catch exactly the class of defect AI is good at avoiding, and to miss the class it produces. A reviewer skimming twenty files will find sloppy code if it exists. They will not find a permission check that is missing from one of forty endpoints, and they will not find an architectural decision that works fine at 500 users and falls over at 50,000.

The AI-code failure-mode matrix used in Frenchy Digital technical diligence, 2026.

Scanners find the defects AI is best at avoiding. Senior engineers find the ones it reliably produces. Any diligence that leans on automation for an AI-heavy codebase is thoroughly checking the wrong half.

— Frenchy Digital diligence principle

This is an area where the discourse runs well ahead of the data in both directions — vendors claiming the security problem is solved, sceptics claiming AI code is uniformly unsafe. The measured position sits between them, and it is worth stating precisely because it is what you will be asked to defend in an investment committee.

Veracode's 2026 GenAI Code Security Report, published 28 July 2026, found an average security pass rate of 56% across the models tested — statistically unchanged from 55% the year before, despite a year of substantial capability gains elsewhere. Roughly 44% of code-generation tasks introduced a risky vulnerability. The strongest model tested reached a 68% pass rate, which still means failing close to one security task in three. The per-category spread is the actionable part: SQL injection defences passed at 83% and cryptographic algorithm selection at 87%, while cross-site scripting passed at 15% and log injection at 12%. Models have learned the vulnerabilities that dominate training material and have not learned the rest.

On real-world impact rather than benchmark tasks, the most useful dataset is an Apiiro study of Fortune 50 development activity from December 2024 to June 2025, summarised in the Cloud Security Alliance's April 2026 research note: AI-assisted developers produced commits at three to four times the rate of their peers while introducing security findings at roughly ten times the rate. Note that those two multipliers are not the same number — the finding rate grew faster than the output rate. And the composition shifted toward the expensive end: privilege-escalation paths up 322%, architectural design flaws up 153%.

The same CSA note collects the field evidence. Georgia Tech's Vibe Security Radar confirmed 35 CVEs traceable to AI-generated code in March 2026 alone, and 74 across its tracking period, with an estimate of 400 to 700 exploitable flaws across public repositories once undercounting is accounted for. A scan by Escape.tech across roughly 1,400 applications built on vibe-coding platforms surfaced 2,038 critical vulnerabilities, more than 400 leaked secrets, and 175 instances of exposed personally identifiable information. These are not laboratory numbers. They are the population your acquisition target was drawn from.

One more piece of context worth carrying into an IC discussion: DORA's research on AI-assisted development finds that AI adoption correlates with higher individual effectiveness and with increased software delivery instability — what the report calls the instability tax — alongside a verification tax, the additional effort required to confirm that generated code is correct, secure, and architecturally coherent. For a diligence audience the translation is direct: if the target has not been paying the verification tax, you will inherit the bill, and it comes due during exactly the growth push you underwrote.

Here is the structure we run. Workstreams one, four, and five are the ones that did not exist in a 2020 diligence in this form; the other four are traditional workstreams whose method has changed.

The seven workstreams of a Frenchy Digital AI-era technical due diligence, 2026.

A note on sequencing that saves real money: run provenance first and let it direct the rest. On a deal with a compressed timeline, provenance plus security plus comprehension — workstreams one, two, and five — will surface the great majority of deal-relevant findings. Architecture review is where depth pays, but it is also the most senior-hour-intensive workstream, and it should be pointed at the modules the heat map identified rather than swept across the whole system.

Dependency review used to be a licence audit with a CVE scan attached, and it was one of the more mechanical parts of a diligence. AI-generated code changed its risk profile in a way most diligence providers have not yet updated for.

The mechanism is package hallucination. Research summarised in the CSA note found that approximately 20% of AI-generated code references packages that do not exist, and — the part that turns a nuisance into an attack — 43% of those hallucinated names recur consistently across generations. That consistency is exploitable. An attacker generates code until they observe which fake package names appear reliably, registers those names in the public registry, and waits for developers to install them. The technique is called slopsquatting, and it inverts the assumption underneath every dependency scan ever run: that the packages in your manifest are real things somebody chose.

• Legitimacy verification: For each dependency: does it have a credible maintenance history, a real maintainer, a repository consistent with its registry entry, and adoption beyond this codebase? A package with three total downloads that appeared last quarter warrants attention regardless of its CVE status.
• Install-time behaviour: Post-install scripts and build-time network calls, reviewed rather than assumed. This is where a slopsquatted package does its work.
• Licence audit against actual use: The traditional check, still necessary — with added attention to copyleft obligations in generated code that pulled in a dependency nobody evaluated.
• Transitive depth: AI-generated code tends toward more dependencies than a considered human implementation, which widens the transitive surface faster than teams notice.
• Lockfile integrity: Whether the lockfile is committed, current, and consistent with the manifest — and whether CI actually enforces it.
• IP and training provenance: For assets where code originality matters to the thesis, whether generated code reproduces identifiable licensed source. This remains legally unsettled in 2026 and belongs in the risk register rather than the findings list.

Classic technical diligence looks for key-person risk: the single engineer who holds critical knowledge and whose departure would be catastrophic. AI-heavy assets have produced the inverse failure, and it is worse. The risk is not that one person understands the system. It is that nobody does.

The test is straightforward, takes ninety minutes, and outperforms every automated tool in the diligence stack. Sit with the senior engineers, away from their screens, and ask them to walk you through the system's critical paths on a whiteboard. Not the architecture they intended — the one that is running.

• "Walk me through what happens when a user's permissions change.": Tests whether the authorisation model is understood as a model, or as a set of checks that were added where bugs appeared.
• "Where does money move, and what makes that idempotent?": Any payment, billing, or ledger path. If the answer is vague about retries and duplicate webhooks, assume a financial bug exists and price the investigation.
• "How is one tenant's data isolated from another's?": The single highest-severity question in any multi-tenant asset. An engineer who cannot describe the isolation mechanism cannot verify it holds.
• "What breaks first at ten times current load, and why?": Tests whether anyone has reasoned about the system's limits at all. "We'd add servers" is not an answer; it is the absence of one.
• "Show me a decision in this codebase you disagreed with and changed.": The most revealing question we ask. It requires having read code critically. Teams that accepted generated output wholesale have no answer, and the silence is the finding.
• "What would you rewrite before scaling, if it were free?": Honest teams answer instantly and specifically. It also gives you their own architecture-risk list, which is often more accurate than what you would assemble from the outside.

Score each critical path as understood, partially understood, or unowned. A single unowned critical path in a payment, authorisation, or data-isolation layer should move a deal from Green to Amber on its own — not because the code is necessarily wrong, but because nobody can tell you whether it is, and post-close you will be modifying it under commercial pressure.

Code you do not understand is not an asset with a defect. It is a liability with a user interface. The distinction matters because you cannot budget the first one and you must reserve against the second.

— Frenchy Digital diligence principle

Findings need to compress into a decision. This is the rubric we deliver, calibrated against the acquirer's planned first-year engineering budget rather than against an abstract quality standard — because the same set of findings is trivial for a buyer with a thirty-engineer platform team and disqualifying for a buyer planning to run the asset with the four people who came with it.

The Frenchy Digital AI-era technical diligence rubric, scaled to acquirer capacity.

Two conditions override the arithmetic and produce a Red regardless of remediation cost. First, secrets exposed in git history combined with no evidence of rotation — because the exposure window is the age of the commit, and you cannot bound what was taken. Second, a data-isolation defect in a multi-tenant system that has been live with real customers, which is a disclosure question and a regulatory question before it is an engineering one.

The question every investment committee eventually asks is what the findings are worth in dollars. Our position, argued on both sides of enough deals to have tested it: AI-generated code should not reduce valuation for being AI-generated. It should reduce valuation to the extent of measured remediation cost and elevated forward risk, and those are two separate numbers that behave differently in a negotiation.

• Remediation cost: Engineering months to close the findings, at the acquirer's loaded cost, with a confidence range rather than a point estimate. This is the defensible, arithmetic number and the one most likely to survive a counterparty's review.
• Elevated incident probability: The increased likelihood of a security or availability incident during the hold period, expressed as a reserve rather than a multiple adjustment. Sellers resist multiple changes and accept reserves far more readily.
• Velocity drag: The verification tax the target has not been paying, which will now be paid by your team — typically expressed as a reduction in effective engineering capacity for the first two to three quarters rather than as a cash number.
• Compliance exposure: Regulatory obligations the asset carries and has not met. Where an AI product sells into Europe, this now includes EU AI Act transparency obligations — see our companion guide on the Article 50 engineering requirements.
• Opportunity cost of the roadmap: The features not shipped during remediation. On a thesis that depends on rapid product expansion, this is frequently larger than the remediation cost itself, and it is the number most often omitted.

In practice, these land in the deal as a holdback or escrow tied to remediation milestones, or as a reset of the first-year engineering budget in the operating model, far more often than as a headline multiple change. Both structures are easier to agree than a price cut because both give the seller a path to earning the value back — and a seller who believes the code is fine will accept a milestone-based structure readily, which is itself useful information.

Deal timelines rarely accommodate the assessment you would ideally run. These are the three formats we operate and the honest guidance on when each is sufficient:

A screening pass is genuinely sufficient for a bid decision in a competitive process, and we will tell you when it is rather than upselling depth you do not need at that stage. It is not sufficient to support a remediation budget or a holdback negotiation — it lacks the effort estimates that make those conversations concrete. The most common sequencing error we see is running a screening pass, feeling reassured by the absence of catastrophic findings, and proceeding to close without the confirmatory work. A screen is calibrated to find deal-breakers, not to size a budget.

If you are a founder rather than an acquirer, everything above is your preparation checklist, and running it on yourself six to twelve months before a process is the highest-return engineering spend available to you. The findings will be the same whenever they surface. What changes is who controls the timeline and the narrative.

Findings you disclose with a completed remediation plan are a sign of engineering maturity. The identical findings discovered by a buyer's diligence team in week three of an exclusivity period are a price adjustment, and often a trust problem that colours the rest of the process. We have watched both versions of the same conversation, on assets with genuinely comparable code, end at materially different terms.

• Establish and document provenance yourself: Know what share of your codebase was AI-generated and where. Being able to answer the question immediately signals control; visibly not knowing invites a deeper and more expensive look.
• Close the security findings that become price adjustments: Authorisation gaps, exposed secrets, missing data isolation, unverified dependencies. These are the findings buyers convert directly into holdbacks.
• Build comprehension deliberately: Assign named owners to critical paths and have them document the system as it actually behaves. This is the finding that cannot be fixed in the two weeks before a data room opens.
• Make your test suite mean something: Run mutation testing and fix what it exposes. A coverage percentage that collapses under mutation testing is worse than no coverage claim, because a buyer will find it and then discount everything else you assert.
• Verify every dependency: Legitimacy, maintenance, licence. A slopsquatted or abandoned package found in diligence reframes your whole engineering process in the buyer's mind.
• Assemble the compliance file: Data flows, PII inventory, sector obligations, and — if you sell into Europe — your EU AI Act transparency position, which as of 2 August 2026 is an active obligation rather than a future one.

Pricing tracks codebase size, system count, and regulatory surface far more than it tracks deal size — which means diligence is proportionally cheaper on larger transactions and is, on small ones, the item most often cut precisely where the information asymmetry is greatest.

Cost bands for AI-era technical due diligence in 2026 — Frenchy Digital scoping guide.

Frenchy Digital prices senior-led diligence at $150 to $225 per hour against brand-name diligence firms at $250 to $450, on work where senior judgment is the entire product rather than a component of it. We deliver findings with remediation effort estimates as standard, because we do the remediation work too — and estimates from teams that only assess are, in our experience reviewing them, consistently and predictably optimistic.

Frenchy Digital is a Black-owned Los Angeles agency that both assesses and rebuilds software assets. Here is what an engagement actually looks like:

• Scoped to your timeline, honestly: Tell us the deal calendar and we will tell you which format fits — including when a 5-day screen is genuinely enough and depth would be waste.
• Senior engineers only: No junior reviewers on diligence. The findings that matter on AI-heavy codebases are architectural and authorisation-level, and neither is visible to someone who has not built systems at scale.
• Findings with effort estimates: Every finding carries a severity, an exploitability note, and an estimate in engineering months. A severity rating alone does not move a deal model.
• The comprehension interview, always: Ninety minutes with the target's engineers is the highest-signal input available and it is the workstream most often skipped.
• IC-ready deliverables: A summary your investment committee can read in ten minutes, backed by a technical appendix your engineers can act on the week after close.
• Remediation continuity, without the conflict: Findings and estimates are delivered before any remediation work is discussed or priced. If you want a different team to do the fixes, we will support their onboarding.
• You own everything: The report is yours to use in your process. Any code we write transfers in full at delivery. No lock-in. Ever.

Choosing a Black-owned agency in Los Angeles for buy-side technical diligence is a strategic decision with concrete advantages:

Why a Black-owned LA agency is the right choice for AI-era technical due diligence in 2026.

Diligence quality varies more than almost any other professional service, and the failure is invisible until after close. Here are the red flags we tell every acquirer to watch for — even if they ultimately hire someone else:

The Frenchy Digital red-flag checklist for technical diligence buyers, 2026.

Ask a prospective diligence provider one question: "How will you determine what share of this codebase a model wrote, and what will you do differently because of the answer?" A provider without a clear method for that question is running a 2019 playbook against a 2026 asset.

— Frenchy Digital buyer's principle