Technical diligence used to mean a partner's engineer skimming the repository for an afternoon. It now opens with one question: how much of this was generated, and does anyone on the team understand it? A codebase built with Cursor or Claude Code is not a red flag on its own. A codebase nobody can explain is, and from the outside the two look identical.
Here is what a reviewer actually checks in an AI-assisted codebase, roughly in the order they check it, and what a good answer looks like for each item. Get ahead of the list and the conversation is about your product. Fall behind it and the conversation is about your valuation.
1. Secrets, in the code and in the history
The first thing a careful reviewer runs is a secret scanner over the whole git history, not just the current tree. A key that was pasted in during a "just make it work" session and deleted a week later is still a leaked key, because history is forever and so is the fork someone cloned in between.
A good answer has three parts: every environment file is ignored by git, any key that ever landed in history was rotated on a date you can name, and a scanner runs in CI so the next one never merges. If you have not done this yet, start with what to do when a key is already committed.
2. Every endpoint that touches private data checks who is asking
Assistants write route handlers that do the work and forget to ask who is calling. The reviewer will open a random API handler and look for the session or token check on the first lines. If it is not there, they will open five more, and the pattern becomes the story of the codebase.
A good answer is boring: authentication lives in one place, a base controller or a middleware that every private route inherits, and the exceptions are listed by name. Bonus points if you can also show ownership checks, meaning a user can only read their own records, not merely any records once signed in.
3. Data access that survives real data
Ten rows in development hide everything. The reviewer wants to know what the hot pages do at ten thousand rows: a query inside a loop, a whole table loaded to filter it in memory, a foreign key with no index. None of this shows in a demo and all of it shows on the first busy day.
A good answer is a list of the three or four pages that matter, with their query counts measured rather than guessed, and eager loading where it was missing.
4. What happens when the payment provider says no
Generated code is excellent at the happy path. The reviewer will read the charge flow and the webhook handler and ask three questions. What happens when the card is declined? What happens when the same webhook arrives twice? What happens when the provider times out halfway through?
A good answer names the exception that is rescued, shows the idempotency key on anything that moves money, and shows that a failure is logged with enough context to find the order again. An empty rescue around a charge is the single fastest way to lose a reviewer's trust.
5. Tests where money and identity live
Nobody expects full coverage from a seed-stage team. They do expect tests on payments, sign-in, permissions and webhooks, because those are the files where a regression costs money or trust. A generated codebase often has zero tests on exactly these files, because the prompt that produced them never mentioned testing.
A good answer is a short list of the critical files and a test for each that pins current behavior. Characterization tests, written before any refactor, count. They are the difference between "the tests pass" and "the tests would have caught it".
6. Runtimes and dependencies are pinned
A missing .ruby-version, .nvmrc or Python version means every developer, CI runner and deploy can pick a different runtime and hit different bugs. Dependencies that are years out of date carry known vulnerabilities with public exploits. This item takes an hour to fix and an hour to check, so it is a cheap way to look careless.
7. Signs that nobody owns the code
Three date-formatting helpers with three names. Two HTTP clients that disagree about retries. Forty lines of commented-out code that "might be needed". Each prompt started fresh, so the codebase has no shared conventions, and duplication is how that shows up.
The reviewer is not counting the duplicates. They are testing a hypothesis: if they pick a file at random and ask you to walk them through it, can you? The best preparation is not a cleanup, it is reading your own codebase before someone else does.
What a good answer looks like
Numbers beat adjectives. "We take quality seriously" is a sentence every founder says. "Our debt score was 41 six weeks ago, it is 68 today, here are the nine pull requests that moved it" is a fact. A baseline, a trend, and a sequenced plan turn diligence from an interrogation into a status update.
The reviewer's real question is never "is there debt". Every codebase has debt. It is "does this team know where it is, and are they paying it down in a way that will not stop them shipping".
Two weeks is enough
- Week one. Run a baseline scan. Rotate any secret that ever touched history. Put authentication on every private endpoint. Fix the P0 findings, and nothing else.
- Week two. Write tests for the payment, auth and webhook files. Fix the N+1 queries on your three busiest pages. Pin the runtimes. Write the one-page summary with the numbers.
Rotwise produces the baseline, the ranked list and the small pull requests, and the diligence report is the same numbers in a form you can hand over. But the checklist above works without any tool. What matters is that you run it before the investor's engineer does.