How Zoraz AI Reviews Its Own Code Before a Human Does

We've written before about what happens in our human code review process, and about the one bug a security audit caught in AI-drafted code. This is the step that happens before either of those: what Zoraz AI itself checks before a pull request ever reaches a human reviewer's queue.

This isn't AI replacing review. It's AI doing the part of review that's mechanical, so the humans on our team can spend their attention on the part that isn't.

What the First Pass Actually Looks For

Zoraz AI's pre-review pass runs against every pull request before it's assigned to a human. It checks for things that are objectively verifiable - not matters of judgment:

• Style and formatting consistency with the existing codebase

• Obvious null-reference and undefined-variable risks

• Unused imports, dead code paths, and leftover debug statements

• Basic input validation gaps on new endpoints

• Missing or clearly inadequate test coverage on changed logic

• Dependency versions that conflict with what's already pinned elsewhere in the project

None of this requires understanding why the code was written a certain way. It requires pattern-matching against known failure modes, consistently, on every single change - which is exactly the kind of repetitive, easy-to-skip-when-tired task that benefits from not being done by a tired human at 6pm on a Friday.

What It Deliberately Does Not Decide

We've been specific about where the line sits. Zoraz AI's pre-review does not approve or reject a pull request, does not comment on whether an architectural decision is the right one, and does not evaluate whether the code solves the actual business problem it was meant to solve. Those are judgment calls, and judgment calls stay with a human reviewer who has context the AI doesn't - the client conversation that shaped the requirement, the tradeoff discussion from three weeks ago, the reason a workaround exists that looks wrong out of context but isn't.

This split matters. An AI that's allowed to approve its own kind of thinking, unchecked, is the failure mode we're actively avoiding - not the one we're building toward.

Why This Order, and Not the Reverse

We considered running human review first and AI review second, as a final check. We landed on AI-first instead, for a simple reason: mechanical issues are cheap to catch early and expensive to catch late. If a human reviewer spends their first pass flagging a missing null check, that's attention not spent on whether the underlying approach is sound. Catching the mechanical issues before a human ever opens the file means the human review that follows is entirely about substance.

What Changed Once We Measured It

After running this process for several months, the clearest shift wasn't in bug counts - it was in what human reviewers actually spent their time discussing. Review comments shifted away from formatting and toward architecture, edge cases, and whether a change actually matched the requirement. That's the outcome we were aiming for: not fewer human reviews, but human reviews that spend their time on the things only a human can evaluate.

Where We're Still Cautious

We don't let Zoraz AI's pre-review pass block a merge on its own, and we don't let it silently "fix" issues it finds without a human seeing the diff. Every flag it raises is visible in the pull request, attributed to the AI pass, and still requires a human to act on it. That visibility is deliberate - the moment an AI review step starts making silent changes is the moment it stops being a safety net and starts being a risk of its own.