How we review code with AI

If you build with AI and nobody checks your code before it goes live, this is for you. It is how we review changes from a junior developer on our team, with Claude Code doing most of the checking. The video shows it in 45 seconds; the rest of this post is the detail you can copy.

A recent example. A change added a campaign banner meant only for full-time job listings, and the first round of review caught it on part-time jobs too. After the fix, Claude counted the employment type of every listing on the site, all 169, in about two seconds: 94 full-time, 75 part-time. Then it opened full-time and part-time pages at three screen sizes to confirm the banner followed that rule. Nobody opened a page by hand.

The interesting part is not that the AI reads the code. It is that it checks what reading the code cannot tell you: does the page look right, does it behave right, and does it match what the client asked for.

One honest note before we start: the AI never decides what goes live. It does the checking and writes it up, and a senior developer reads it and makes the call. When Claude runs the merge, it is because we told it to.

What you get at the end

One link. Behind it is a page that says whether the change is ready, shows what changed on desktop and on phone, explains each problem in plain words, and hands the developer a prompt to fix it.

Roughly 12 minutes on average. That is across our last nine reviews, from asking Claude to a published report, and it depends on the change: a small one took 3 minutes, seven pull requests checked together took 19, and the biggest single change, with five screen widths and recordings, took 29.

Our handbook makes an AI review the default check on every change. Because most of ours come from a junior developer, the review has two jobs: catch problems before the client sees them, and explain them well enough that the developer learns from the fix.

Step 1 · Scan it, then run it

Claude Code reads every changed file, starts the site and runs a sanity test: does it build, do the pages load, does anything throw an error. Then it uses the pages like a visitor, on desktop and phone sizes, clicking what the change touches and watching the console. If the project has its own tests, those run too.

The "before" is not always the base branch. The same checks run on the version from before the change, so an old problem is never blamed on the new one. On one fix, staging could not show the bug at all, so the "before" came from the live site.

Step 2 · Check it against the client's content — the step people rush

If a page shows content the client sent us, Claude compares it item by item: every name, address and link. When a change depends on data, like that banner, it checks every entry rather than a sample.

Step 3 · Show the change

Before-and-after screenshots for anything visual, on desktop and phone. When something you use changes — a filter, a search box, a sign-in flow — Claude also records the same steps on both versions.

Screenshots for what you see. A recording for what you use.

Step 4 · Write it up for the developer

Everything goes into one Claude artifact page, in Japanese and English. It opens with a verdict, then explains each finding with the screenshots next to it. Most findings come with a prompt the developer can paste straight into Claude Code, and every report ends with one they can reuse before their next pull request. The real one, word for word:

Before I create the PR, please self-review this change. Check the following and show me the results in a table:
1. Open the changed pages in a browser on the dev server. Are there any new Hydration warnings or errors in the console? (Check with Playwright or similar.)
2. Does it work as expected not only when opening the URL directly, but also when clicking buttons and links?
3. Do links and buttons have names a screen reader can tell apart (text or aria-label)?
4. Is there any invalid HTML (p inside p, a inside a, etc.), or more than one h1?
5. Do npm run lint:css-js and npm run lint:html show any new errors?
If there are problems, explain them before fixing anything.

When the fix comes back, every check runs again and the same page updates. One link, however many rounds it takes.

What it does not do

It does not decide what ships; a senior developer makes that call and owns it. It cannot tell whether a page is what the client wanted. It says what it did not test: when one new section's content was not in the CMS yet, the report said so and left a five-case test plan instead.

And it can be wrong. Once it called a change a blocker; we disagreed, and it took it back, because the empty section was the agreed spec, not a bug. That is why someone senior reads every report.

The same agent, other jobs

It started with one junior's pull requests. The same setup now does a few other jobs:

• After a merge. A staging check of several merged changes together, against the live site: 22 checks, all passed, before anything was released.
• Many pull requests at once. Claude merged them together in a test copy first, to catch conflicts between them, and ran a dev server for each one, seven at the same time.
• A bug fix. New tests that fail on the old code and pass on the fix, plus before-and-after recordings of the exact steps the user took.
• A report for the client. The new content matched word for word against the client's own document, with before-and-after screenshots, written for someone who does not read code.

The shape is the same every time: a real environment to run in, a list of checks, and one reader to write for.

Other teams are taking it in other directions, and we are looking forward to seeing where it goes. Anthropic's Code Review for Claude Code has several agents read the diff. Builder.io's Quality Review Agent tests each pull request in a browser and replays every bug as a video. alexop.dev's AI QA engineer runs a Playwright check whenever a pull request gets a label. Ours leans on two things we have not seen elsewhere yet: checking the page against the client's own content, and writing the report to teach the developer who made the change.

Why this matters more than the tool

Run it before you trust it. Code that reads fine can still put a banner on the wrong pages.

Show the change. A before-and-after screenshot settles in seconds what a paragraph cannot.

Write the fix down as a prompt. Hand the person fixing it something they can paste, with the reason right above it.

None of it needs a senior engineer watching every line. It needs the habit of checking, and an AI that does not get bored.

For developers

• AI review runs at Impl Review with our /code-review plugin, plus asvs-audit for anything security-sensitive, alongside CI (code review standard).
• Playwright at desktop and 390px, console hydration warnings, Biome, markuplint and git merge-tree, all compared against a baseline.
• When the repo has them: unit, integration and E2E suites, tsc --noEmit and a production build; a bug fix's new tests run on the old commit first to reproduce the bug.