Preparing an AI-written codebase for review

Preparing an AI-written codebase for review comes down to four questions the reviewer will ask, and the artefact that answers each. This page is the founder's side. The reviewer's side, how they read a generated codebase and what they weigh, is on diligence on an AI-written codebase, and the pillar page on preparing for technical due diligence puts this page in sequence with the rest of the preparation.

The four questions:

1. What share of the code was written with AI tools?
2. What reviewed each generated change before it merged?
3. What test or evaluation run decided each change was safe to ship?
4. What does a security scan of the current code find?

Reveneau builds all of its software this way, with AI writing the code and an evaluation suite, derived from the specification, deciding whether each change ships, so the answers we prepare for our own clients' reviews are the ones below: the share is all of it, the review is the evaluation run on every change, the run history is kept, and the scan runs in the same pipeline. A company that builds differently can still answer all four; the artefacts are just different.

Why does the reviewer ask what share was generated?

Because the share tells the reviewer which review method to use, and because not knowing it is itself a finding. Stack Overflow's 2025 Developer Survey found 84 percent of respondents using or planning to use AI tools in their development process, from 33,662 respondents [12], so a reviewer assumes AI wrote some of the code in every company they look at. The question is how much, and where.

The same survey explains why the reviewer cares. Of 33,244 respondents asked about trust, 32.7 percent trusted the accuracy of AI tools and 45.7 percent distrusted it, and 66 percent of 31,476 respondents named solutions that are almost right as their top frustration [12]. A reviewer reads a generated codebase looking for the almost-right code, and wants to know that someone or something looked before they did.

Have the share ready as a number with a method. "We estimate 70 percent by lines, measured by tagging pull requests as generated or hand-written from March onward; before March we did not tag, and we assume most of it" is an answer. "A lot" is the finding. If you cannot measure it, say how you would and give a date.

What does the review trail need to show?

The review trail needs to show, for each generated change, who or what checked it and what the check found. The artefact is the pull request history, and the reviewer will read it whether or not you describe it, so describe it accurately.

Three shapes of trail, in increasing strength:

• A human reviewer per pull request. The reviewer's name, the comments, the changes requested and made. This is the minimum, and its weakness is that a reviewer reading a large generated diff approves faster than a reviewer reading a small hand-written one. METR's study of 10 July 2025, with 16 experienced developers completing 246 issues on their own large open-source repositories, found that the developers took 19 percent longer on tasks when allowed to use AI tools, while forecasting they would be 24 percent faster and believing afterwards that they had been 20 percent faster [11]. A reviewer who knows that study will ask how long your reviews take, and the pull request timestamps answer.
• An automated test run per pull request, green before merge. The test suite is the check; the run log is the artefact. Its weakness is the one every test suite has: it checks what somebody thought to test. Our post on how many tests AI-generated code needs covers the coverage question for generated code.
• An evaluation suite derived from the specification, run on every change, with the run history kept. This is the strongest, because it checks the code against what the code was meant to do rather than against what a developer thought to assert. What an evaluation suite is, and how it differs from a test suite, is on eval-driven development; what a reviewer does with one is on the eval suite as a diligence artifact.

Whichever shape you have, the reviewer's question is the same: show me one generated change, the check that ran on it, and what the check found. Pick three pull requests before the review and be ready to walk each.

What should the security scan show?

The scan should show the current code's findings, each with a severity and a status, and the reviewer will expect findings. Veracode's report of 30 July 2025 tested more than 100 language models across Java, Python, C# and JavaScript and found 45 percent of generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities, with Java at 72 percent, and cross-site scripting defences missing in 86 percent of relevant samples [9]. Its update of 24 March 2026, covering more than 150 models across 80 tasks, found the 45 percent failure rate unchanged, with Java passing 29 percent of tasks and cross-site scripting passing 15 percent [10].

Two things follow for preparation. First, run the scan before the review and fix what you can, because a generated codebase that has never been scanned will produce a list on the reviewer's first day. Second, wire the scan into the pipeline so that it runs on every change, and put the run history in the data room, because the reviewer's real question is whether the next generated change will be caught, and only a pipeline answers that. Our guide to AI-generated code to production covers the security argument in full, and our post on how to do a security review before launch covers producing the first scan.

What does an evaluation suite prove to a reviewer?

An evaluation suite proves that each change was checked against the specification rather than against a developer's expectation, and its run history proves the check was applied every time. That is the whole of its value in a review, and it is the reason we build with one.

The artefacts a reviewer wants from an evaluation suite are three: the specification the evaluations were derived from, the evaluations themselves with their expected results, and the run history showing each change's result. A reviewer reads those in order. Does the specification describe the product the deck sells? Do the evaluations cover the specification, and where are the gaps? Has every merged change passed, and what happened to the ones that failed?

The last question is the sharp one, and a failing run is a good answer to it. A suite that has never failed is either checking nothing or has never been run on a bad change, and a reviewer will say so. A run history with failures, each followed by a fix and a passing run, shows the suite doing its job. Our post on how to evaluate a vendor's eval suite is written for a buyer checking a supplier's suite, and every question in it applies to a reviewer checking yours.

What about generated code with no trail at all?

Say so, scope it, and put a plan on it. A common shape is a prototype written with AI tools in a week, with no review and no tests, which then became the product. A reviewer knows that code has no trail, and expects instead that you know which code it is, that it is separated from the code written with a process, and that the roadmap has a line for bringing it under the same checks.

The preparation is a table: each module, the share generated, the review shape it had (none, human, tests, evaluations), the scan status, and the plan. That table goes in the code and architecture folder of the engineering data room, and its "none" rows go on the index page as known problems. A reviewer who receives that table spends the review confirming it. A reviewer who does not receive it builds it, and builds it with less charity.

How does this change the rest of the preparation?

It changes one column in each of the other artefacts. The team map from what investors look for in a startup's codebase gains a column for whether the two people who can change a system could rewrite it without the tool. The dependency inventory gains a column for licence provenance, because generated code can carry fragments of licensed code, and the reviewer's view of that is on code provenance and licence exposure in AI-generated code. The roadmap gains a line for bringing untrailed code under the checks. And the one-sentence answers from what a technical review asks for gain, under code quality, the sentence this whole page exists to make true: "N percent of the code was generated; every change since DATE has passed the evaluation suite before merging, and the run history is attached."