Does the review need repository access?

For the offline checks, no: paste the file or function and the report is produced in the browser. A human reviewer works from the link or snippet you attach to the request.

Can the checks match our own house rules?

The automated pass covers a published rule set with severities you can read. House conventions that go beyond it are exactly the kind of judgement a named reviewer is there for.

Should every generated diff be reviewed by a human?

Not every diff. Route routine changes through the deterministic pass and escalate where a wrong answer is expensive: authentication, payments, data deletion, anything customer-facing.

Engineering

AI code review aimed at how generated code fails.

Assistant-written code is usually readable. That is why it slips through review: it looks like the work of someone careful. The defects live in the assumptions, not the syntax.

Run a free check Request a human review

The work is the evidence that it held.

Generated code fails at the edges

A model is strongest where logic is linear and weakest where the real world intrudes: input arriving malformed, a promise rejecting, a network call hanging. The middle of the function reads well; the boundary is where the bug is.

Reviewing generated code therefore means reading for what is missing rather than what is wrong. Empty catches, defaults returned in place of errors, optimistic assumptions about every external system.

The patterns worth searching for

These recur often enough that a search finds them faster than a careful read, and a search does not get tired at paragraph four hundred.

Credentials in source, including the ones in comments and example files.
eval, new Function and innerHTML used to avoid writing a parser.
Empty catch blocks and bare except clauses that turn failure into a default value.
Calls to methods that do not exist on the library version you actually have.
Loose equality, truthiness checks that break on zero, and off-by-one loops.
Debug residue: console.log, debugger, TODO and FIXME left from prompting.
Copy-paste duplication where one copy has since rotted.

From findings to a signed sign-off

The offline pass produces a scored report of every finding with the line that triggered it. When the change is going into production and the risk is real, a senior engineer reads the file with those findings in front of them, requests fixes and signs the verdict.

Both artefacts travel with the pull request, so the next reviewer inherits the reasoning instead of repeating it.

What the checks look for

Secret handling
Literals where configuration belongs, and no rotation note when one is found.
Error paths
Failures swallowed, retried without limit, or converted into plausible-looking data.
Rendering safety
Untrusted strings reaching HTML, URLs or SQL without an escape or a parameter.
Dependency truth
Imports that resolve to nothing, and APIs invented for a version that never had them.
Boundary handling
Missing nulls, empty arrays, timeouts and partial responses.

Read the method

Questions this page usually raises

Does the review need repository access?: For the offline checks, no: paste the file or function and the report is produced in the browser. A human reviewer works from the link or snippet you attach to the request.
Can the checks match our own house rules?: The automated pass covers a published rule set with severities you can read. House conventions that go beyond it are exactly the kind of judgement a named reviewer is there for.
Should every generated diff be reviewed by a human?: Not every diff. Route routine changes through the deterministic pass and escalate where a wrong answer is expensive: authentication, payments, data deletion, anything customer-facing.

AI code review

Run the checks, then decide who needs to sign it.

The automated pass is free, needs no account and uploads nothing. Escalate to a named reviewer only where being wrong is expensive.

Run a check Request a specialist