AI Code Review, Built Into How We Ship
It started as a review pipeline for one enterprise codebase. It is now a gate in our own development loop: a change is challenged, simplified and independently reviewed, as many times as it takes, before anyone releases it.
The Challenge
The first version solved a throughput problem. We were reviewing an enterprise codebase by hand, each review took 30 to 60 minutes of focused reading, and the same class of issue would be caught by one reviewer and missed by another depending on the day. When an auditor asked for proof that a specific change had been checked for security problems before it shipped, there was a work item and nothing structured behind it.
So we built a pipeline: four security scanners, an AI reviewer that knew the codebase's own patterns, and a structured report for every change. In its first 10 weeks it produced 179 reviews.
Then the problem changed. AI started writing most of our code, and an agent can produce a change faster than a person can read it. The author of a change, human or model, is also the worst reviewer of it. Review stopped being something that happened to code after it was written and became the thing that decides whether code leaves the branch at all.
Our Approach
We moved review inside the development loop and made it a gate. Every unit of work now runs the same sequence: challenge, simplify, fix, code review, fix, challenge and simplify again, and another review pass if the fixes warrant one. That repeats until the verdict is Approved. Only then does a person own the change and release it.
Three rules hold the loop together. The reviewer is never the author: the code review runs in a separate session that did not write the code and has no stake in it. A fix is new code, so it goes back through the same passes as the original. And the passes do different jobs on purpose. Challenge looks for reasons to reject, simplify only cleans up, and the code review brings the scanners and a severity for every finding.
The last step is the one no tool can do. Before a change is released, the person shipping it has to be able to say what it does, why it is written that way, and what would break it. If they cannot, it is not ready, however clean the review was.
The Solution
Every change, in this order
- 1
Challenge
Adversarial pass on the change
- 2
Simplify
Four cleanup reviewers
- 3
Fix
Blocking findings first
- 4
Code Review
A separate session
- 5
Fix
Every finding answered
- 6
Challenge + Simplify
Again, on the fixes
- 7
Approved?
If not, another review pass
- 8
Own
Explain it before it ships
- 9
Release
Merge and deploy
Inside the code review
Security Scanning
- Snyk SAST
- Gitleaks Secret Detection
- NuGet SCA
- Roslyn Static Analysis
AI Code Analysis
- Architecture and Layer Separation
- Logic and Error Handling
- Security Beyond the Scanners
- Complexity Assessment
Challenge
- A hostile reviewer reads the change looking for reasons to reject it
- Hunts defects, and also scope creep, ignored shared code and states that should be unreachable
- Where it can, it runs its case instead of arguing it
- Blocking findings are fixed or defended before anything else happens
Simplify
- Four reviewers in parallel: reuse, simplification, efficiency and depth of fix
- Finds the helper that already exists and the check that cannot trigger
- Applies the cleanups, then the tests run again
- Quality only. It does not hunt for bugs, which keeps the two passes honest
Independent Code Review
- Runs in a separate session that never saw the code being written
- Reads the full change, not a summary of it
- Findings carry a severity, a file and line, and a concrete fix
- Four verdicts: Approved, Approved with Comments, Changes Requested, Veto
Security Scanning
- Snyk SAST for known vulnerability patterns
- Gitleaks for keys, passwords, tokens and connection strings
- NuGet SCA for vulnerable dependencies
- Roslyn analysis for C# quality and pattern enforcement
Repeat Until Approved
- Fixes go back through challenge and simplify, because a fix is new code
- Another review pass whenever the fixes are large enough to warrant one
- 87 of our review reports are second or later passes on the same change
- One change needed 12 passes before it was approved
Own and Release
- The last gate is a person, not a model
- Whoever ships the change answers what it does and what breaks it
- The questions and answers are kept with the plan
- Works on GitHub pull requests and Azure DevOps, Git or TFVC
Results
300+
Review reports on our own code
15
Repositories under the same loop
87
Repeat passes on a change already reviewed
12
Most passes one change needed before approval
4
Independent security scanners per review
179
Reviews in the first 10 weeks, on the original codebase
What It Catches on Our Own Code
- A content loader that would have run code at build time from a file's header. The review found it before the first file was ever published.
- A page title that could break out of a script tag and run as script. The reviewer built a copy of the site to prove it, then proved the fix.
- Text silently deleted from a published page with no error. The challenge pass reproduced it against the installed library.
- Six blocking problems in a classifier that had already passed its own 89 test cases. Each one was proven by running it.
What Changed
- Review is no longer a queue. It runs on every change as part of building it, so nothing waits days for a reviewer.
- Recurring findings become permanent tests, so the same mistake cannot come back unnoticed.
- Every change has a report behind it: what was scanned, what was found, what the verdict was, and on which pass.
- The loop is the same on a marketing site, a mobile app and an internal tool. The standards do not drop because a project is small.
“Writing code is no longer the slow part. Standing behind it is. A review that runs once, by the same model that wrote the change, tells you very little. A review that is independent, repeated on every fix, and ends with a person who can explain the result is what makes AI-written code safe to ship.”
Frequently Asked Questions
Is Anyone Reviewing What Your AI Writes?
If agents are writing code for you, the review process matters more than the model. Tell us how changes reach production today and we will show you where the gate should be.