How We Review AI-Written Code (and Why Claude's Built-In Review Isn't Enough)

AI coding tools write a working feature in minutes. The problem isn’t that the code is bad. The problem is that nobody is checking how it all fits together. Every change looks fine on its own. Six months later, the app is slow to change, risky to touch, and nobody knows why.

We fix that with a review system that runs in three parts. This post explains it twice: first in plain English for founders, then in full detail for developers.

The Plain-English Version (for Founders)

Think of your app like a building. AI is a very fast builder. It will put up walls all day, but it doesn’t check whether the walls line up with the plan.

Our review system is the inspector. It does three jobs:

1. It checks every change before it goes live. Each time a feature or fix is finished, the review looks for bugs and checks the change against our 13 architecture rules — things like “every change to a customer’s data must confirm it’s really their data.” If something breaks a rule, it gets fixed before it ships.

2. It checks the whole app once a week. Small problems hide in code nobody touched recently. Once a week, the review reads every file, runs every test, and double-checks each problem it finds so you don’t chase false alarms. It also remembers last week’s list and tells you what got fixed and what’s still open.

3. It tells you how your app should be structured. Most apps built fast have no clear structure. The review names the structure you have today, flags “god files” — single files that do far too much — and recommends a simple structure for each part of your app. Simple screens stay simple. Risky parts like billing and logins get extra protection.

What you get: one report, problems ranked from most to least serious, each with the exact file and the fix. No jargon dump. If the same mistake keeps showing up, the report says so and suggests a new rule so it stops happening.

Why it matters: fixing a problem the week it appears costs minutes. Fixing it after six months of code is built on top costs weeks.

The Technical Version (for Developers)

Why Claude’s Built-In Review Isn’t Enough

Claude Code ships with its own /code-review. It’s good at what it does: it reads your diff and finds correctness bugs. But it has three gaps:

• It doesn’t know your rules. It finds bugs, not violations of your architecture. It won’t flag a route doing database work directly, or an UPDATE with no ownership check, unless that happens to cause an obvious bug.
• It only sees the change. Problems in code you didn’t touch this week stay invisible.
• It has no memory. It can’t tell you the same mistake showed up in four places this month.

Our system keeps the built-in review’s strength and closes those three gaps.

Check 1: pr-review — Every Change

Runs on the current branch or diff before merge. Full walkthrough: The PR Review Skill. In order:

1. Bug pass. A fresh subagent reviews the diff for bugs, regressions, broken behavior, and missing tests.
2. Architecture pass. A second subagent checks the diff against all 13 rules. These are the same rules we explain in How to Stop AI from Vibe-Coding Your Next.js App into a Mess — routes only coordinate, validate at every boundary, every UPDATE/DELETE carries a user_id predicate, read-then-write runs in a transaction with FOR UPDATE, and so on.
3. Specialist passes. Error handling and silent failures, test gaps, and type design when new types appear. If migrations or the schema changed, a schema audit and a domain-model audit run too. If files were deleted or renamed, a dead-code check runs.
4. One report. Everything merges into a single file with a verdict: Ready to merge — Yes, No, or With fixes.
5. Test fixes. Missing tests found in the review get written, not just listed.

Check 2: full-review-weekly — The Whole App

Diff reviews can’t see what’s already there. Once a week, this check reads every file. Full walkthrough: The Weekly Review Skill.

• Tool checks. Lint, type check, tests, migration check, and npm audit. Any failure is logged as a finding.
• Slices. The codebase is split into folders. Each slice gets a full-file bug pass and a full-file 13-rule pass.
• Verify pass. A separate agent re-opens the code for every critical and important finding and marks it confirmed or false alarm. Only confirmed findings count.
• Specialists. Security, data ownership and locking, query scale (N+1, missing indexes, unbounded selects), schema, module borders, API and JSON boundaries, null handling, error contracts, types, test gaps, and dead code.
• Follow-up. Last week’s confirmed findings are re-checked: fixed or still open. Anything open two runs in a row gets bumped to critical.
• Pattern tally. When the same category of mistake shows up across several parts of the app, the report suggests the exact wording of a new rule — or a new automated check if a rule isn’t enough.

It saves progress after every step, so a long run that gets cut off resumes where it stopped instead of starting over.

Check 3: Architecture Fit — What Structure Should This App Have?

This is the part most reviews skip. Rule checks tell you what’s wrong. They don’t tell you what shape the app should be.

The architecture-fit step does four things:

1. Finds your declared pattern, if you have one written down. If you do, it only checks for drift from it.
2. Names the shape you have today — with folder paths as proof.
3. Flags god files. A file gets flagged when it hits two of these: 400+ lines, 15+ exports, or mixing two or more of UI rendering, database queries, outside API calls, and business rules. Each one comes with a plan to split it safely.
4. Recommends a structure per business area when none is set — the simplest one that fits.

The options, from simplest to heaviest:

Structure	Good for
Plain CRUD	Simple screens that read and save data
Layered	Keeping UI, logic, and database code apart
Vertical slices	One folder per feature, everything it needs inside
Modular monolith	One app split into business areas (billing, outreach, admin)
Clean / Hexagonal	Walling core logic off from vendors like Stripe or your email provider
Domain-driven design	Many business rules that change often
Event-driven / CQRS	Real queues and heavy write load
Microservices	Almost never for a small team

For most small SaaS teams, the answer is a modular monolith: plain CRUD for simple screens, and Clean/Hexagonal only where money, logins, AI, or outside vendors live. The report ends with the first three small, safe moves to get there.

What a Finding Looks Like

Every finding uses one line, so nothing gets lost in prose:

severity | category | file:line | issue | fix

For example:

critical  | ownership      | lib/invoices.ts:88    | UPDATE has no user_id check (R12)       | add user_id to WHERE
important | simplification | app/dashboard/page.tsx:1 | god file: 920 lines, mixes UI + DB + Stripe | split with refactor plan

Categories come from a fixed list — correctness, security, ownership, locking, validation, error handling, type safety, scale, and so on — so trends can be counted week over week.

Which Check When

Situation	Use
Finished a feature or fix	pr-review
Quick bug check on a small change	Claude’s built-in /code-review
Weekly health check	full-review-weekly
Inherited or AI-built app with no clear structure	full-review-weekly — read the architecture-fit section first

---

Get the Kit Free

We give the whole review system away. It’s a free Claude Code plugin: both reviews, the 13 rules, and every check they call. In Claude Code, run:

/plugin marketplace add kbventures/ingenix-code-review
/plugin install code-review-kit@ingenix

Then run /code-review-kit:pr-review after your next change, or /code-review-kit:full-review-weekly for a whole-app check. Source and instructions are on GitHub.

---

Want This Run on Your App?

If your app was built fast with AI and you’re not sure what’s hiding in it, we’ll run the full review and walk you through the report — what’s broken, what’s risky, and the first three fixes that matter most.

Book a Free Discovery Call