How to assess code quality

When investors hear "code quality" they often picture clean, elegant code. Quality in the context of a deal means something more practical: can the team change this software quickly and safely, or does every change risk breaking something. If the answer is the second one, the roadmap being funded will be delivered far slower than the plan promises.

What does code quality mean in a deal?

Code quality in a deal means the software can be changed at the speed the thesis assumes, with a low chance of each change breaking production. That definition is about behaviour rather than appearance, and it can be measured from the outside. Software that is easy to change lets the team release features, fix bugs, and respond to the market. Software that is hard to change turns every small request into a slow, risky project.

So the question to answer in diligence is: how fast and how safely does this team release a small change today. A team that can put a fix into production in a day, with confidence it will not break something else, has good quality by the only definition that matters to the deal. A team where a one-line change takes a week has a problem, no matter how tidy the code looks. This connects directly to assessing technical debt, because debt is the main thing that makes change slow and risky, and to the main guide, which presents every finding as a cost against the thesis.

Reveneau's code quality assessment asks for the target's delivery numbers for the last twelve months before it asks for the code, because a team that can produce those numbers has already told the reviewer most of what a style review would, and a team that cannot produce them has told the reviewer something too.

Which numbers tell you whether code is safe to change?

The DORA delivery metrics tell you. DORA, the research programme that has published an annual study of software delivery from 2014 to 2025, defines five measures, three of throughput and two of instability. They are the closest thing the industry has to a standard set of measures, and a target that tracks them can provide them in an afternoon.

DORA metric	DORA's definition	What it tells the deal team
Change lead time	The time for a change to go from committed to version control to deployed in production	How long a roadmap item waits between "done" and "live"
Deployment frequency	The number of deployments over a period, or the time between deployments	Whether the release process is routine or an event
Failed deployment recovery time	The time to recover from a deployment that fails and needs immediate intervention	How long customers wait when something breaks
Change fail rate	The ratio of deployments that require immediate intervention	How often a change breaks production
Deployment rework rate	The ratio of deployments that are unplanned and happen as a result of an incident	How much release work is emergency repair rather than planned roadmap work

DORA's research overview also records its own main findings: high-performing organisations do better on all of the delivery measures at once, so speed and stability rise together rather than one improving at the cost of the other, and its 2023 study found teams that prioritise user needs achieve 40 percent higher organisational performance. Ask for the five numbers, ask how they were measured, and ask for the trend over twelve months. A team whose lead time is growing and whose deploy frequency is falling is a team whose code is getting harder to change.

What should you look at in the repository and the release process?

Look at four things: whether automated tests exist and run, how changes are reviewed, how large changes are, and what a release involves. Each can be checked in a working session with an engineer rather than by reading the code line by line.

Tests. Ask what share of the code is covered by automated tests, then ask to watch the suite run. A suite that passes in front of you is evidence. A suite that "usually passes" or "needs a few environment fixes" is a finding. A codebase with no tests is a codebase where every change is a risk, and the how many tests does AI-generated code need post covers what coverage means for a modern codebase.

Review. Google's published engineering practices state that reviewers should approve a change once it "definitely improves the overall code health of the system", even if it is imperfect, and that a change should not wait days or weeks for perfection. Look at the pull request history for that pattern: named reviewers, comments that show reading, approvals that take longer than the change could have been read. Approvals arriving seconds after a large change was opened tell you the review is only a formality.

Change size. Google's guidance on small changes states that 100 lines is usually a reasonable size and 1,000 lines is usually too large, because small changes are reviewed more quickly, reviewed more thoroughly, and less likely to introduce bugs. A repository where most changes are thousands of lines is a repository where review cannot have caught much.

Release. Ask what happens between "merged" and "live". A scripted pipeline that deploys many times a week is a good sign. A release that needs a named person, a weekend, and a rollback plan drawn on a whiteboard is a cost to price.

How do you judge quality without reading code?

Judge it from behaviour, because quality is visible in how the company operates. Most investors are not engineers, and the review does not need them to be.

1. Ask for a walkthrough of one recent feature. A strong team tells you the options, the choice, and the trade-off in plain language. A team that answers with jargon either does not understand its own code or is hiding careless choices.
2. Ask what a one-line change costs. How long from idea to production, and who has to be involved. The honest answer is a lead time, and it is the same number DORA measures.
3. Ask about the last time a release broke something. How was it found, how long did recovery take, what changed afterwards. This is the change fail rate and recovery time, described in the team's own words.
4. Talk to someone who inherited the code. The most revealing reference question is how the work performed after it was released: did small changes stay cheap, or did they become slow and hard. Software that is fast to build and expensive to change is a common form of poor quality that is hard to see.

The assessing the engineering team page covers assessing the people in more detail, and the same logic applies to any external team you evaluate, as in how to choose the right external development team.

What changes when the code was written by AI?

The standard changes from "who wrote this" to "what checked this". Most codebases reviewed in 2026 contain code that a model wrote, and penalising a company for it would rule out most of the teams building well. The finding is generated code with no review record and no verification method, because that means the company cannot fully explain its own system.

Three figures describe the risk. Stack Overflow's 2025 survey of more than 49,000 developers found 84 percent using or planning to use AI tools, 46 percent distrusting the accuracy of AI output against 33 percent trusting it, and 66 percent naming solutions that are "almost right" as their biggest frustration. Google's October 2024 DORA report associated a 25 percent increase in AI adoption with a 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability. Veracode's July 2025 study of more than 100 language models found 45 percent of generated code samples failed security tests.

So the question for the review is what catches the almost-right code before production. Look for specifications that are still kept up to date, for a test or evaluation suite that runs in the pipeline and fails when it should, and for a pull request history that shows human reading. Our AI-generated code to production hub covers the full argument and the security figures, the eval-driven development hub explains the evaluation suite a reviewer should ask to see, and the diligence on an AI-written codebase page covers the review itself.

How does quality connect to the team?

Most of what people call code quality depends on who wrote it and who reviewed it. Experienced engineers have seen which quick solutions cause costs later, so they avoid them without being told. Across a review, weak code and a junior team tend to appear together, and strong code and a senior team do too. When you find good quality, check that the seniority behind it is still at the company. When you find weak quality, the fix is usually as much about the team as the code. Stripe's 2018 developer survey, by its own account, found the average developer spending 17.3 hours of a 41.1-hour week on maintenance work such as debugging and refactoring, and 13.5 hours on technical debt; a team that reports numbers in that range is describing a codebase that is hard to change.

How do you put the finding in the deal?

Price it. Poor quality is a cost rather than an automatic reason to leave the deal. Estimate what it takes to get the code to where the roadmap needs it, and raise that number in the deal negotiation.

Finding	Typical repair	Where it goes
No automated tests, but a senior team	Build a suite around the main functions first	First-hundred-days plan
Long lead time, rare releases	Pipeline and release automation	First-hundred-days plan
Large unreviewed changes, approvals that are only a formality	Review policy, smaller changes, a reviewer who reads	First-hundred-days plan, and a team finding
AI-written code with no verification method	Specification recovery, an evaluation suite in the pipeline	Price, because the risk is unmeasured
Team cannot change its own software safely and does not know it	Senior hires or a partner team	Terms, and a warning sign

The technical due diligence checklist lists the code quality questions in a form you can take into a review, and the report structure and template page shows how a priced finding is written up.