The Codebase You're Buying Was Written by a Machine: How AI Broke Technical Due Diligence

The Tech File Moved to the Front of the Deal

For most of the last two decades, technical due diligence was a confirmatory workstream. The commercial and financial teams did the work that moved price; the technical review existed to make sure nothing embarrassing was hiding in the repository. It ran late, it ran cheap, and it rarely changed the number.

That is no longer the arrangement. Drawing on PitchBook's software M&A data, technology diligence now re-trades 30 to 40 percent of software-heavy deals, with typical price reductions of 5 to 25 percent when buyers surface material findings in code quality, cybersecurity, IP ownership, or third-party license exposure. The tech file has become the second-most-priced workstream after quality of earnings, and for software and AI-product companies it is now the first.

The numbers attached to individual findings are not abstract. On a $50 million SaaS acquisition, a single unresolved security vulnerability cluster combined with an unaddressed open-source licensing issue routinely costs the seller $2-4 million in adjusted purchase price, plus an indemnity escrow held for 18 to 36 months. That is a rounding error in the deal model and a catastrophe in the founder's personal outcome, and it is usually the product of engineering decisions made two years earlier by people who had no idea they were writing a line item into a purchase agreement.

The environment sharpens it further. PitchBook's Q1 2026 analyst note on private equity's exposure to the software reckoning describes compressed valuations and investors reassessing the durability of traditional SaaS models against AI-native competition. When multiples compress, buyers underwrite cost-to-own far more aggressively, and cost-to-own is precisely what a technical review is trying to estimate. The commercial question behind every diligence exercise is unchanged: how much will it cost, in money and time, to keep this product running and growing after we own it?

The Audit Was Built for Code Someone Remembers Writing

The classic technical audit rests on an assumption so basic that nobody states it: the code is an artifact of a team's decisions. From that assumption, everything else follows. You can sample a few repositories and extrapolate, because the same people made the same kinds of choices throughout. You can interview the CTO and two senior engineers and get a reliable account of why the system is shaped the way it is, because they shaped it. You can read the commit history as a record of intent.

That assumption has quietly stopped holding. Roughly 41% of all new code is now AI-generated, with 85% of professional developers using AI coding tools regularly. And that is the market average, dragged down by regulated enterprises with restrictive policies. At the acquisition-target end of the distribution, the concentration is far higher: as early as March 2025, Y Combinator reported that for a quarter of its W25 batch, 95% or more of the codebase was AI-generated. Those companies are eighteen months older now. They are raising Series A and B rounds, being acquired, and sitting in data rooms.

The specific problem is that AI-generated code inverts the diagnostic signals the profession spent twenty years learning to read. The traditional smells of a rushed codebase, inconsistent naming, obviously pasted snippets, missing tests, absent docstrings, are exactly the things a model removes. Generated code is locally plausible and superficially uniform. It has tests, because the tests were generated in the same session. It has comments. It follows a consistent style. A reviewer skimming a sample comes away reassured, and the reassurance is not evidence of anything.

What that means practically is that diligence has to move from reading a sample of the code to measuring the repository. The signal is no longer in how the code looks; it is in the shape of the history, the duplication topology, the churn profile, the review records, and the provenance trail. That is a different exercise requiring different tooling, and a data room that offers a code snapshot with squashed history rather than full repository access should be treated as a finding in itself, not an administrative inconvenience.

Finding One: Maintainability That Diverges from Velocity

The most reliable new evidence comes from repository-level analysis over time, and the picture it produces is consistent across the industry. GitClear's analysis of 623 million code changes from 2023 to 2026 tracked eight quality signals as AI authorship reached record volume. Code block duplication rose 81%. Within-commit copy/paste rose 41%. Error-masking constructs rose 47%. Two-week code churn, the share of code rewritten almost immediately after being committed, rose 15%.

The declines matter more. Cross-file function calls, the clearest proxy for actual reuse, fell 35%. Refactoring line moves fell 70%. Long-term legacy maintenance activity fell 74% against 2022 levels. Read together, these say something specific about the asset a buyer is acquiring: the codebase is growing faster than before while the work that keeps a codebase habitable has largely stopped happening.

Translate that into the deal model. Duplication is a multiplier on the cost of every future change, because a fix has to be applied in n places and nobody knows what n is. Error-masking constructs, the swallowed exception, the broad catch that logs nothing, actively suppress the production telemetry a buyer would otherwise use to assess reliability, which means the target's incident record may be understating rather than reflecting the true failure rate. Falling refactoring activity means the interest on that debt is not being paid.

Velocity metrics will point the other way, and a seller's materials will feature them. GitClear's data shows heavy AI users out-producing non-users by 4 to 10 times, but most of that gap pre-dated AI: measured against their own past output, heavy AI users gained a more modest 25% in velocity. Commits per engineer, PRs merged, and story points in a CIM are not evidence of an efficient engineering organization in 2026. They are evidence of tool adoption. The maintainability trend runs in the opposite direction from the throughput trend, and only one of the two shows up in a management presentation.

Finding Two: Security Debt the Scanners Were Not Built to Catch

Security has always been part of technical diligence, and the standard approach, run a SAST tool and a dependency scanner, produce a findings count, price the remediation, was adequate when the defects were predominantly the kind static analysis finds. The defect mix has shifted underneath that method.

Veracode's spring 2026 GenAI code security update, drawn from evaluations of more than 150 large language models, found that only about 55% of generation tasks produce secure code. In roughly 45% of cases the model introduces a known security flaw. The longitudinal finding is the more damning one: syntax correctness now exceeds 95% while the security pass rate has sat at approximately 55% for two years. Models got dramatically better at writing code that works and no better at writing code that is safe. Against cross-site scripting specifically, the failure rate reached 86%.

Field data from production repositories matches. Apiiro's analysis across tens of thousands of Fortune 50 repositories found AI-assisted developers committing at three to four times the rate of their peers, with monthly security findings rising from around 1,000 to more than 10,000 over six months. The composition shift is the part that should change how diligence is scoped: trivial syntax errors declined, while privilege escalation paths rose 322%, architectural design flaws rose 153%, and secrets exposure rose 40%.

Privilege escalation paths and design flaws are not findings a scanner reports. They are conclusions a human reaches after reading an authorization model, a tenancy isolation boundary, or a service-to-service trust assumption. Which means a clean SAST report is weaker evidence in 2026 than it was in 2022, and a diligence scope that leans on automated output is measuring the category of defect that has been declining while missing the category that has been growing. On any target where AI-assisted development is material, the security workstream needs human review time allocated specifically to multi-tenancy isolation, authorization logic, secret handling and rotation history, and the API and agent surface. The output that belongs in the model is a priced remediation plan, not a findings count.

Finding Three: The Copyright Hole Underneath the Asset

This is the finding most deal teams have not yet internalized, and it goes to the nature of what is being purchased rather than its condition.

United States copyright protects works of human authorship, and the Copyright Office has applied that requirement consistently to AI output. Its Part 2 report on copyrightability concluded that prompting alone, however detailed, does not constitute authorship; protection extends to human contributions and to AI-assisted work only insofar as a human exercised meaningful creative control, assessed case by case. In March 2026 the Supreme Court declined to consider whether AI alone can create copyrighted works, leaving the human authorship requirement firmly in place.

Applied to a codebase, that produces an uncomfortable conclusion: some portion of the target's software may not be protectable by copyright at all. This is not the same as unusable. The buyer can run it, sell it, and modify it; trade secret protection, contract terms, and access controls all still operate. What weakens is exclusivity. If a competitor reproduces functionally similar code, the copyright enforcement path against them is narrower than the deal thesis assumed. For an acquisition priced on proprietary technology rather than customers or distribution, that is a valuation input, not a footnote, and securing protection for software code has become correspondingly tricky.

The practical obstacle is evidentiary. The recommended remedy, document the human creative contribution, is straightforward advice and almost nobody followed it. Very few companies logged which commits were AI-authored, which were AI-assisted, and which were written outright. Without that record, the target cannot demonstrate the human contribution, and a representation that would once have been given flat becomes qualified. Buyers should expect that qualification and price it; sellers should understand that the absence of provenance records is itself the finding.

Open source sits alongside this and interacts with it. Best practice has long favored broad, unqualified open-source representations, and targets now resist them precisely because AI-assisted development has made open-source provenance harder to attest to, pushing instead for reps limited to compliance with internal policy. Copyleft contamination remains the specific fear, because it can force disclosure or destroy exclusivity outright. Diligence findings here feed directly into escrow sizing, price adjustment, and pre- or post-closing remediation obligations. The emerging drafting response is AI-specific representations and warranties with their own liability caps, survival periods, and targeted indemnities, separated from the general IP package so that the risk is allocated deliberately rather than by accident. We have written separately about how license contamination enters an AI-assisted codebase in the first place.

Finding Four: Nobody Left Can Explain It

A buyer acquiring a software company is partly buying the team, and one of the reasons is that the team functions as the documentation. Whatever the architecture diagram fails to capture, the four people who built the system carry in their heads. Retention packages are priced on that premise.

The premise weakens when a large share of the system was generated rather than written. The engineers are not incompetent and they are not lying; they genuinely shipped the product and it genuinely works. But there is a difference between having authored a decision and having accepted a suggestion, and that difference shows up under pressure, at 3am during an incident, or in month four of an integration when a subsystem needs to change in a way its structure does not accommodate.

This changes what a useful diligence interview looks like. Asking a senior engineer to walk through the architecture is close to worthless now, because a competent person can narrate any diagram fluently. Ask instead for a trace through a specific past production incident, from alert to root cause to fix, with the reasoning at each step. Ask why a particular abstraction exists and what was considered instead. Ask to see the architecture decision records. On a codebase where a large fraction of code is machine-generated, the absence of decision records is not a documentation gap, it is a signal that the decisions may not have been made by anyone.

The number that belongs in the model is the discovery cost. If nobody can explain the system, every post-close change carries a comprehension tax before any engineering starts, and that tax is paid on the buyer's roadmap, not the seller's. This is the same dynamic we have described as comprehension debt, and in an acquisition it is unusually visible, because it is exactly the cost the buyer has to fund out of synergy assumptions that were written before anyone opened the repository.

The Sell-Side Version: The Twelve Months Before the Process

Every finding described above is cheaper to fix than to concede. A buyer who surfaces material issues takes 5 to 25 percent off the price and holds an escrow for up to three years. The same issues, resolved before the data room opens, cost engineering time. The arithmetic is not close, and the only real constraint is that the work has to start roughly a year out, because most of it takes months to show up in the evidence a buyer will look at.

The list is unglamorous and finite. Produce a software bill of materials and run a full license scan; identify and remove or replace copyleft-contaminated components, and remediate anything under a license your counsel would not want to explain. Write and adopt an AI usage policy, and from that point forward mark AI-assisted commits, because provenance you start recording today is provenance you can attest to in twelve months. Get real test coverage on the revenue-critical paths, not aggregate coverage percentage, which buyers discount anyway. Write architecture decision records for the ten decisions a buyer will ask about, and be honest in them. Attack the worst duplication clusters, particularly any that sit on the roadmap the buyer will inherit. Close secrets exposure and rotate everything that was ever committed, and keep the rotation evidence.

None of this is a rewrite, and treating it as one is the most common way it fails. It is a bounded remediation project, typically two to three senior engineers for two to four months depending on codebase size, that produces a specific artifact: a repository whose measurable signals support the story the CIM tells.

The difficulty is timing, and it is a real one. This work lands in exactly the window when the product roadmap must look its best, when the team is stretched, and when pulling two senior engineers off feature delivery to reduce code duplication is the hardest internal argument a CTO will make that year. That conflict is why the work usually does not happen, and why buyers keep finding the same things. Solving it is a staffing question rather than a technical one, which is the subject of the last section.

The Buy-Side Version: The First Hundred Days

Diligence findings have a short half-life. They are vivid during the process and forgotten six weeks after close, when integration meetings, customer commitments, and the acquired team's own roadmap consume the available attention. The single highest-value post-close action is converting the technical findings into a funded remediation plan with named owners and dates before that window closes.

Sequence it by what is bleeding. Secrets exposure and authorization defects first, because they are live risk and the rotation work only gets harder as systems are integrated. Then the duplication clusters that sit directly on the near-term roadmap, because those are the ones that will otherwise turn every planned feature into an archaeology exercise. Then tests on the paths you are about to change. Documentation and decision records last, written by the people doing the remediation while the understanding is fresh, which is the only time it is cheap to produce.

Resist the rewrite. It will be proposed within sixty days, usually by the acquired team, usually sincerely, and it will be supported by a genuine argument that the existing structure cannot carry the roadmap. Historically, full rewrites cost $500K to $2M or more, took 12 to 24 months, and failed at a rate around 70% by Standish Group's numbers. AI tooling has compressed per-module rewrite economics meaningfully, which makes targeted module-level replacement a much more reasonable proposition than it was, but it has not changed the failure mode of whole-system rewrites, which is organizational rather than technical. Extend and stabilize; replace modules where the case is specific.

Then check the retention math against what diligence actually found. If the comprehension picture was weak, the people you are retaining may know less about the asset than the retention package assumes, and the correct response is not a larger package. It is budgeted capacity to rebuild the understanding independently, which is a cost you should have priced before signing and can still fund deliberately afterwards.

Staffing Diligence and Remediation Without Stalling the Roadmap

Both sides of this problem have the same awkward shape. The work is real, senior, and bounded. Sell-side remediation runs a few months and ends. Buy-side post-close cleanup runs a quarter or two and ends. Neither justifies permanent hiring, and neither can be handed to whoever has capacity, because the profile required is specific: engineers who have done license and dependency remediation, who can read an authorization model and find the escalation path, who can de-duplicate without destabilizing production, and who can write the decision records afterwards in language a buyer's advisor will accept.

It is also work that arrives at the worst possible moment. In a sale process, engineering attention is already committed to making the product look its best. After a close, it is committed to integration and to the commitments that justified the deal. Pulling senior people onto remediation in either window means slowing the exact thing the transaction is being judged on, which is why the work so reliably slips.

At StepTo we have run senior engineering teams out of Serbia since 2014, and this is a shape we recognize: a parallel track that does not compete with the roadmap. Your team keeps shipping what it committed to, while a separate dedicated development team owns the remediation end to end, the license and SBOM work, the backend and authorization hardening, the duplication clusters, the secrets rotation and pipeline and infrastructure evidence, and hands back documented systems plus the records that support the representations. Engineers are assigned by name and stay with the codebase, which matters here because most of the value is in understanding why a particular subsystem behaves the way it does, and that understanding takes weeks to build and one rotation to lose.

The nearshore element is more than a rate argument during a live transaction. Diligence question-and-answer cycles run on 24 to 48 hour turnarounds, and a buyer's technical advisor asking on Tuesday morning for evidence of when a credential was rotated needs an answer that day, not after an overnight handoff. Four or more hours of overlap with Western European working hours is the difference between a data room that stays current and one that visibly lags. For teams that already have the people and need a specific capability added to an existing group rather than a separate one, staff augmentation against named senior engineers is usually the faster route in, and if you are early in evaluating partners, our vetting guide covers the questions worth asking first.