Articles · Code review and hardening
How We Review AI-Built Codebases: Six Questions and File-Line Evidence
Automated scanners flag syntax patterns while missing broken authorization, silent failure paths, and client-trusted state. Here is how a Codeneath Review inspects an application from entry route to database row.
The six questions, and where each one looks first
- Does it work?User journeys and state changes
- Is it secure?Auth, ownership checks and secrets
- Is it fast?Queries in loops and payload size
- Does it scale?Pagination, indexes and rate limits
- Does it survive failure?Timeouts, retries and idempotency
- Can someone else maintain it?Duplicated helpers and dead files
On this page
AI coding assistants let a solo founder or lean team assemble a working web application in days. That speed is real, and we encourage teams to keep it.
The risk is rarely that the code fails to compile. The risk is that nobody on the team has read what sits underneath the happy path: who can call a mutation, what happens when a payment webhook arrives twice, or which database query loads an entire table into memory.
Automated scanners cover part of that gap: they flag known vulnerable dependencies and risky patterns. What they can't tell you is whether User A can read User B's invoices.
At Codeneath, every review and technical breakdown asks the same six questions, backed by exact file:line evidence.
1. Does it work?
Before inspecting security headers or query plans, we trace the application's core state transitions from the route entry point to storage.
AI-generated code frequently builds a convincing user interface around an incomplete state machine. Forms show a success banner even when a downstream mutation fails, or checkout flows unlock paid features on a client redirect before the payment provider confirms the charge.
We map each critical user journey and verify that the state stored on the server matches what the screen tells the user.
2. Is it secure?
Static scanners look for known CVEs and regex patterns. Real business-logic vulnerabilities hide in the gap between authentication ("who is signed in?") and authorization ("does this user own the record they are mutating?").
// Vulnerable pattern common in AI-generated Server Actions:export async function updateProjectTitle(projectId: string, title: string) { const session = await getSession(); if (!session) throw new Error("Unauthorized"); // Missing ownership check: any signed-in user can mutate any projectId return db.project.update({ where: { id: projectId }, data: { title }, });}Fixing this requires scoping the query to the authenticated principal on the server:
// Hardened pattern: scope the mutation by both record ID and owner IDexport async function updateProjectTitle(projectId: string, title: string) { const session = await getSession(); if (!session) throw new Error("Unauthorized"); return db.project.update({ where: { id: projectId, ownerId: session.user.id }, data: { title: title.trim().slice(0, 120) }, });}During a review, we inspect every route handler, server action, webhook endpoint, and storage bucket policy for missing ownership boundaries, exposed secrets, and unvalidated inputs.
3. Is it fast?
Performance defects in young applications rarely come from micro-optimizations. They come from architectural choices generated by default:
- N+1 database queries inside a loop rendering a dashboard list.
- Fetching full row payloads—including large JSON columns—when a view only renders titles and dates.
- Shipping heavy client-side JavaScript bundles for pages that could render as static HTML.
We trace the critical rendering path and the slowest database queries so you know which bottleneck dominates response time.
4. Does it scale?
An application that works for ten test accounts can stall long before it reaches real traffic. We check what happens when tables grow by an order of magnitude:
| Area | Common AI-Generated Pattern | Production Consequence |
|---|---|---|
| Pagination | Unbounded .findMany() sorted in JavaScript | Memory exhaustion as row count grows |
| Indexes | Foreign keys and filter columns without composite indexes | Full table scans on every dashboard load |
| Rate limits | Public auth or AI-generation endpoints with no per-user cap | Runaway API bills or credential stuffing |
5. Does it survive failure?
Networks drop, third-party APIs time out, and webhook providers retry delivery. When an AI tool scaffolds an integration, it often writes only the sunny-day path and wraps errors in a generic catch block that logs to the console and returns 200 OK.
We check for idempotency keys on payment and email handlers, transaction boundaries around multi-step writes, and explicit timeouts on outbound network calls.
verifySignature → insert(event.id)Records evt_123 in a unique column and grants credits once.duplicate key on event.id → skipReturns 200 OK cleanly without adding credits a second time.6. Can someone else maintain it?
Eventually, you or another engineer will need to change the codebase under deadline pressure. If three different authentication helpers, duplicated validation schemas, and dead files coexist in the same repository, every change risks a regression.
Every Codeneath Review concludes with a plain-language tour of the repository, scoped fix prompts for the AI coding tool you use, and an ordered hand-off sheet any developer can execute.
A Codeneath Review reads your repository line by line. From $499, in about 5 working days.
See how a Review works →Want this check on your codebase?
A Codeneath Review from $499: six answers at file:line, fix prompts and a developer hand-off sheet.