Due diligence on a product written largely with AI

More and more of the software companies that come to market were written largely with AI coding tools. Sometimes a founder built the first version alone by describing features to a model. Sometimes a small team used assistants for most of the typing. The product works, customers pay, and the growth chart looks like any other.

For a buyer or an investor, the question is not whether AI was used. It almost always was, to some degree, and that alone says nothing. The question is whether anyone understands the code, whether anyone checked it, and whether the parts that carry money and personal data do what they appear to do. Generated code can look tidy and confident while hiding exactly the problems a review exists to find.

This is how we read such a product, and what it means for the deal.

What changes when much of the code was generated

The six layers of a review stay the same. What changes is where the weight falls and how much the reviewer can take on trust.

In a product written line by line by engineers, code usually reflects what its authors understood. Its quality tracks the team's skill: a weak team writes code that looks weak. Generated code breaks that link. A model produces fluent, well-named, well-commented code whether or not the person who asked for it understood the problem. Surface quality stops being evidence of anything. The reviewer has to read for behavior, not for style.

Volume changes too. A founder with a model can produce in a month what a small team once wrote in a year. More code means more to read, and a larger share of it that no person ever read before it shipped. This tends to make a review slower and more careful, not faster. It is a mistake to assume that a codebase produced quickly can be assessed quickly.

This article is about products whose code was generated. It does not cover companies that sell AI as the product, which we treat in AI diligence: is it a product or a wrapper?, or reviewers who use AI tools to read code, covered in AI tools in technical due diligence.

What is not a problem

A capable team that uses assistants for routine work, reviews every change, keeps tests on the paths that matter and can explain its own system is simply a productive team. Its code is not riskier because a tool typed part of it. Some of the best-run repositories now contain instruction files for coding agents, review rules and tests written before the feature. Those are signs of a process, not of a shortcut.

The line a reviewer draws is not between human and generated code. It is between code that a responsible person understood and checked, and code that nobody did. A report that marks a product down only because AI tools appear in its history is reporting a preference, and the seller will be right to push back.

Where generated code tends to fail

The failures are not new kinds of defect. They are ordinary defects that appear more often, in larger quantity, and with fewer people who can find them.

Nobody can explain it

The most important finding is often a missing person. Knowledge that would normally live in an engineer's head lives in old chat sessions nobody kept. When the founder, or the one contractor who ran the tool, is asked why a module is built the way it is, the answer is a reading of the code on the spot. That belongs to layer 06, Team & knowledge, and works like the risk described in our note on key-person risk, except that sometimes there is no key person at all.

Duplicated and inconsistent code

Each session solves its problem from scratch. The result is three ways to call the same external service, two date libraries, validation rules repeated with small differences in a dozen places, and error handling that changes style from file to file. Each copy works. Together they make every later change slower, because a fix in one place leaves the same bug alive in the others.

Security that looks right

Models write what they are asked for, and nobody asked about access rules. A common pattern is authorization enforced only in the interface: the button is hidden for users who should not see a record, but a direct request to the server returns it anyway. Hosted backends make this worse when database access rules are left switched off, so anyone who finds the endpoint can read the table. Other patterns recur: input checked on the client and not on the server, password reset flows that leak whether an account exists, file uploads accepted without type or size limits. The code often contains a comment saying the check is done. The check is somewhere else, or nowhere.

Dependencies added without thought

Accepting a suggestion that installs a package takes one click. Generated products tend to carry more dependencies than they need, some abandoned, some overlapping, and occasionally one whose name a model invented and someone later registered. Each package is code the buyer now owns, with its own vulnerabilities and license terms.

Secrets in the code

API keys, payment credentials and database passwords are often pasted straight into source files to make something work during a session, sometimes into code that runs in the browser where any visitor can read them. Removing them from the current files is not enough if they remain in the version history and were never rotated.

Tests and review that exist only on paper

Some generated products have no tests. Others have many tests that a model wrote to match the code it had just written, so they confirm the implementation instead of the business rule. A coverage number can look healthy while nothing guards the billing logic. Likewise, a repository may have pull requests that were opened and merged by the same person within a minute.

Signals, and how the reviewer checks them

No single signal proves that code was generated without care, and none needs to. The reviewer looks for patterns, then confirms them in the systems and in conversation with the team, under the usual access protocol: read-only, named accounts, no copies of personal data.

The walkthrough matters most. A capable team that used AI heavily can still say why a module is shaped the way it is, what it would change, and where the weak spots are. A team that cannot is telling the reviewer where the real risk sits, whatever the code looks like.

Ownership and license: points for counsel

Generated code raises questions that a technical reviewer can surface but not answer. We give no legal advice. These are the facts we gather so that counsel can.

• Which tools, under which accounts. Company accounts on business plans, or personal accounts of founders and contractors. The terms of each tool differ on who owns output and how submitted code may be used.
• What was sent to the tools. Whether customer data, credentials or a client's confidential code went into prompts, and whether settings allowed the provider to keep it.
• Open-source matches. Generated code can reproduce fragments of published code, including code under licenses such as GPL or AGPL that carry obligations. A license scan of the repository, not only of the declared packages, shows where matches appear.
• Human authorship. The copyright position of material produced mostly by a model, with little human contribution, is not settled. How much of the core was written, edited or directed by people may matter to counsel's view of what the company owns.
• Who ran the tools. If contractors generated the core, the usual question of assignment applies, covered in our note on ownership gaps in a software acquisition.

How these points shape representations, warranties or insurance is a matter for counsel and the deal team. Our report states what was seen and where.

How findings are rated

Generated origin is never a finding on its own. Each finding is rated on our severity scale by what it does to the business, exactly as it would be for code written by hand. Customer records readable without authorization are Critical whoever wrote the query. Duplicated logic that slows every change is usually Medium. Chat-style comments are Low.

What generated code often changes is the confidence of the estimate. When nobody can explain a module, the cost to fix carries a wider range, because the work includes understanding before changing. The report says so. A generic, fictional illustration:

Customer records can be read through the hosted database interface without an access rule. Layer: Security & access. Severity: Critical. Evidence: database rules read in the provider console with read-only access, rules disabled on three tables holding customer contact and billing status; the front-end bundle carries the public key that reaches them; the team confirmed rules were never configured. Impact: personal data exposed to anyone who finds the endpoint; possible notification duties, a point for counsel. Cost to fix: roughly 2 to 5 engineer weeks, assuming one engineer who knows the platform writes rules table by table and tests each with test accounts. The high end assumes the application relies on open access in places nobody has mapped. Time: before closing, or as a closing condition, to be decided by the deal team.

Severity and cost are separate. That Critical item may be cheap to fix. A Medium finding about duplicated business logic across a large codebase may cost far more. How rated findings become cost ranges is covered in how technical debt is measured and put into a deal.

Keep, fix or rebuild, from the buyer's side

Founders face this question about their own product. Our engineering partner PERETZ covers that side in You Built an MVP With AI. Keep It, Fix It or Rebuild It?. A buyer faces the same question with different stakes: it is paying for the product now and will own the answer after closing.

The answer depends on what the buyer plans to do with the product, which is why the reviewer needs that plan.

• Keep. The team understands the code, the paths that move money and data are tested and reviewed, and the findings are ordinary hygiene. The product goes into the usual first-year plan.
• Fix. The structure can be explained and the problems are local: access rules, secrets, missing tests on critical flows, duplicated modules to consolidate. The work is real and has to be planned, but each step leaves a working product. Most AI-heavy products land here.
• Rebuild. Payments or personal data sit on a base with no access control, the data model cannot hold the planned growth, or every change breaks something else and nobody can say why. The buyer is then paying mainly for the customers, the data, the proven flows and the brand, and should model the rebuild as a cost with its own time line and risk.

Even a rebuild keeps a great deal: user behavior already observed, screens people understood, data collected, features nobody used. The reviewer's job is to show which case applies with evidence and to price the route with stated assumptions. Whether that belongs in the price, an escrow or a closing condition is for the deal team and counsel; we neither negotiate nor value the company. Some fixes, such as rotating exposed keys, usually make sense before money moves. Our note on the 100-day plan covers the order after closing.

A checklist, and what to do next

Questions worth putting to the seller, and to any technical report, when the product was written largely with AI tools:

• Which tools were used, by whom, under which accounts and plans?
• Can someone on the team walk through billing, login and data access and explain the design choices?
• Is every change reviewed by a second person before release, and does the history show it?
• Are authorization checks enforced on the server and in the database, not only in the interface?
• Has the full history been scanned for secrets, and were exposed ones rotated?
• Do the tests on money paths fail when the rule they guard is changed?
• Can the team explain why each major dependency is there?
• Has the repository been scanned for open-source matches, not only declared packages?
• Does the report rate findings by business effect, and state which plan it rated against?
• Where nobody could explain a part, does the report widen the cost range and say why?

If you are buying or investing, share your plan for the product with the reviewer before the work starts, and expect the review to take the time the codebase needs. Our technical due diligence reads AI-heavy products across all six layers, with walkthroughs of the paths that carry money and data, at a fixed fee agreed in writing before we start. If time is short, a red-flag memo looks first at access rules, secrets and the comprehension gap, the findings most likely to change the deal.

If you are selling a product built this way, the same checks run in reverse: find the gaps, close the cheap ones and show a plan for the rest before a buyer's reviewer finds them.

Questions