Originally published at systemtrails.com.
Technical due diligence on an AI-built codebase in 2026 asks five questions: does anyone on the team understand the code, is it secure today, can it be restored after a bad day, can it be maintained by someone who did not write it, and what breaks if the founder leaves. Reviewers no longer ask whether AI wrote it. They ask for evidence that a human made it hold, and that evidence takes two to three weeks to prepare.
In short
Five questions a 2026 review asks of an AI-built product, and the evidence that answers each:
- Comprehension over provenance: someone walks the reviewer through auth, payments and data access from the code
- Security posture: row-level security, secrets out of the bundle, a dependency scan, findings already fixed
- Separation and recoverability: staging and production are different databases, and a restore has a date
- Maintainability: tests, CI, low duplication, changes that touch a few files
- Key-person risk: a new senior engineer could ship in week one from the docs alone
How a reviewer walks your codebase
The review is a sequence, not a scan. Each step opens the next; a "no" at any step becomes a finding in the memo.
Why the question changed
In March 2025, Y Combinator managing partner Jared Friedman said that for a quarter of the W25 batch, 95% of the codebase was AI-generated, and that those founders were technically capable of writing it themselves (TechCrunch, 6 March 2025). Eighteen months later that is the default, and reviewers have adjusted.
The current framing from due-diligence practitioners is blunt: the first question is no longer "is the code good?" but "does anyone here understand it?" A two-person team can now ship a codebase with the surface area of a fifty-person organization, which breaks the old assumption that team quality predicts code quality (Justin McKelvey, Technical Due Diligence in 2026, 10 August 2026).
The five questions, and the evidence for each
Comprehension over provenance
Who can explain the auth, payment and data-access paths from the code, without the AI chat history.
Evidence: an architecture map and a 20-minute recorded walkthrough of the three paths.
Security posture
What the app does when nobody is logged in. Row-level security, secrets, dependencies.
Evidence: RLS proven by a test, service-role key absent from the bundle, a dated scan, and the findings you already fixed.
Separation and recoverability
Whether staging and production share a database, who holds production write access, and when you last restored.
Evidence: an environment diagram with credential boundaries and a restore log with a date and a duration.
Maintainability
How expensive the next change is: tests, CI, duplication, files touched per change.
Evidence: CI green on main, a tenant-isolation test, and the duplication you already consolidated.
Key-person risk
What happens if the founder leaves. The tools do not remember why.
Evidence: a README that is true, the map, a deploy-and-restore runbook, a decisions log.
Time to prepare
Two to three weeks for a product that already works and has users. No rewrite. Every step produces a document the reviewer asks for anyway.
1. Comprehension: can you walk me through it?
The first hour of a good technical review is a conversation. The reviewer picks three paths, typically sign-in, the money path, and "show me how user A cannot see user B's data," and asks the person who built it to explain them from the code.
AI-built codebases fail this in a specific way. McKelvey's list of tells is exact: five different patterns solving one problem, comments that describe rather than explain, and authentication that "works until two people log in."
Before: The founder explains what the app does and opens the AI chat to find how. Three patterns for one problem, no map, nobody can say where the session is validated.
After: The founder opens the repo, points at the middleware that validates the session, the query that scopes by tenant, and the webhook that reconciles payments. One page architecture map on the table.
Dan's free architecture map template is a format reviewers accept.
2. Security posture: what does the code do when nobody is logged in?
The base rate is not on your side. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models in four languages and found that 45% of generated code samples introduced an OWASP Top 10 vulnerability; for cross-site scripting the failure rate was 86%, and Java samples failed 72% of the time (Veracode, 30 July 2025). A reviewer therefore assumes generated code was not secure by default and looks for proof that someone checked.
The reference incident: CVE-2025-48757
Lovable-generated apps called Supabase directly from the browser and relied entirely on row-level security, which was often missing. Researcher Matt Palmer found 303 endpoints across 170 projects exposing usernames, emails, phone numbers, payment status and API keys. Discovered 20 March 2025, disclosed 29 May 2025 (disclosure, Superblocks write-up). Reviewers know this case. The first thing they try on a Supabase-backed app is a read with the anonymous key.
| What the reviewer tries | What proves you are fine |
|---|---|
| Reads a table with the anonymous key | RLS enabled on every table, and a test that fails if it is not |
Searches the client bundle for service_role
|
The key is server-side only; the bundle search comes back empty |
| Asks for the last dependency scan | A scan output with a date, and the fixes committed |
| Asks what you found yourselves | A short list of three real findings you already fixed, with commits |
A team that found and fixed three real issues reads as competent. A clean scan with no history reads as untested.
3. Separation and recoverability: what happens on the bad day?
On 18 July 2025, during a documented code freeze, Replit's agent deleted the production database of a SaaStr application holding records on about 1,200 executives and companies, then reported that rollback was impossible when it was not (The Register, 21 July 2025). The founder's own diagnosis afterwards is the one a reviewer gives: nothing may overwrite a production database, and preview, staging and production must be cleanly separated.
Before: One database for preview and production. The AI tool and the deploy pipeline both hold production write credentials. Backups exist in theory; nobody has restored one.
After: Staging and production are different databases with different credentials. No agent holds production write access. A restore was run on a known date and took a known number of minutes.
If you have never restored, do it once before the data room opens: half a day of work that turns the most uncomfortable question in the review into a paragraph.
4. Maintainability: how expensive is the next change?
Investors price the next twelve months of engineering, and AI-generated code has a measurable signature. GitClear's analysis of 211 million changed lines from 2020 to 2024 found copy-pasted code rising from 8.3% to 12.3% of changed lines while refactored code fell from 25% to under 10% (GitClear, 2025). In practice: the same validation logic in six places, and one rule change touches all of them.
| Signal the reviewer checks | Weak | Strong |
|---|---|---|
| Tests | None, or not run anywhere | Run in CI on every push, cover the money path |
| Files touched by a small change | Ten to fifteen | Two or three |
| Ways to do one thing | Five patterns for validation | One, reused |
| Duplication | Same logic copy-pasted across modules | Consolidated, with the commits that did it |
An enterprise security questionnaire and a new engineer's first week fail on exactly the same missing pieces.
5. Key-person risk: what if you leave?
The team is usually one or two people, and the tools do not remember why. Developers themselves are cautious here: Stack Overflow's 2025 survey of over 49,000 developers found 84% using or planning to use AI tools, while 46% distrust the accuracy of the output and 66% name "almost right, but not quite" solutions as their top frustration (Stack Overflow Developer Survey 2025). Reviewers apply the same caution to a codebase whose only documentation is a chat transcript.
The question is simple: could a senior engineer you hire next month ship a real change in week one using only what is in the repo? If the answer depends on you being in the room, that is the finding.
A README that is true
How to run it, how to deploy it, where the secrets live, what is deliberately not done yet.
The architecture map
Systems, data stores, external services, and the boundaries between them, on one page.
Deploy and restore runbook
The exact steps, the last time each was run, and how long it took.
The decisions log
Why Supabase, why this auth provider, what you skipped and why. The part no chat transcript keeps.
This is the trail a senior architect leaves after a hardening pass, and the same trail that keeps your first hire.
The three weeks before the data room
Nothing above requires a rewrite. For an AI-built product that already works, the preparation is a fixed-scope hardening pass:
| Week | Work | Document it produces |
|---|---|---|
| 1 | Fix the top security findings; prove isolation with a test; get the service-role key out of the client | Findings-and-fixes list with commits |
| 2 | Separate staging from production; rotate credentials; run and time a restore | Environment diagram, restore log |
| 3 | Consolidate the worst duplication; get CI green; write the map, README and runbook | Architecture map, runbook, decisions log |
If you do one thing today
Run a restore from your most recent backup into a scratch database and write down the date and how long it took. It is the cheapest sentence in the whole data room, and almost nobody has it.
The same preparation answers the other four trigger moments: the enterprise pilot's security questionnaire, the first engineering hire, the first real incident, and the first week of scale pain all ask for this evidence in a different order.
If you want senior eyes on your actual code before an investor's, that is what the free teardown is: three concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.
Sources
- TechCrunch, "A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated", 6 March 2025: https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
- Justin McKelvey, "Technical Due Diligence in 2026: Checklist + the AI-Code Question", 10 August 2026: https://justinmckelvey.com/blog/technical-due-diligence
- Veracode, "2025 GenAI Code Security Report", 30 July 2025: https://www.veracode.com/blog/genai-code-security-report/
- Matt Palmer, "CVE-2025-48757" disclosure, 29 May 2025: https://mattpalmer.io/posts/2025/05/CVE-2025-48757/
- Superblocks, "Lovable Vulnerability Explained: How 170+ Apps Were Exposed": https://www.superblocks.com/blog/lovable-vulnerabilities
- The Register, "Vibe coding service Replit deleted user's production database", 21 July 2025: https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/
- GitClear, "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones" (211M changed lines, 2020 to 2024): https://www.gitclear.com/ai_assistant_code_quality_2025_research
- Stack Overflow, "2025 Developer Survey: AI": https://survey.stackoverflow.co/2025/ai
- SystemTrails, "The Architecture Map Every AI-Built Startup Needs": /resources/architecture-map-template/
Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.
