Here's the problem nobody warns you about when you turn on AI code review: the bottleneck doesn't disappear, it moves. Teams adopting AI coding tools ship far more pull requests, but each one now waits longer in review — you generate code faster, so more code piles up at the gate. AI-assisted review is the obvious lever to pull. The real question is whether it pulls in the right direction.
I've run both GitLab Duo Code Review and Google's Gemini Code Assist against production merge requests — not demos, not synthetic benchmarks. This is what actually held up, what created noise, and where I still won't let a model make the call.
What does AI code review actually catch?
Start with what it's genuinely good at, because that's where the time savings are real. Both tools shine at the boring-but-important layer: a function that ignores a nil return, an off-by-one in a loop bound, a missing error check on a file handle, an obvious injection vector in a query string. Gemini Code Assist on GitHub tags every comment with a severity level — Critical, High, Medium, or Low — which matters more than it sounds, because it lets you set a threshold and suppress the rest.
The second win is summarization. When a teammate opens a 600-line MR touching twelve files, a near-instant summary of what changed and why is the difference between reviewing it now and reviewing it "later" (read: never). That alone shortened our triage step measurably.
The adoption data backs this up. The 2025 Stack Overflow Developer Survey of roughly 49,000 developers found that 84% are using or planning to use AI tools in their workflow, with more than half using them daily. AI review has moved from pilot curiosity to default infrastructure. But notice the framing — assisted, not replaced. The tools earn their keep on volume and consistency, not judgment.
What does it miss — and where is human judgment still irreplaceable?
AI review reads a diff. It does not read your roadmap, your incident history, or the Slack thread where someone explained why the "redundant" retry logic exists. So it misses the things that aren't visible in the patch.
Architectural drift is the big one. A change can be locally correct and globally wrong — a new service-to-service call that quietly creates a circular dependency, a data model tweak that breaks an assumption three repositories away. Single-repository review tools have a structural blind spot here, and pretending otherwise is how teams accumulate debt. There's also a subtler trap we see often in client work: AI-generated code tends to carry more quiet duplication than human-written code, yet because it reads cleanly, reviewers wave it through more readily. The surface plausibility lowers everyone's guard. The model won't catch that. You have to.
The other thing it can't weigh is cost-of-being-wrong. "This works" and "this should ship to the payments service on a Friday" are different sentences, and only one of them is a human decision.
How does AI change code review culture on a team?
This is the part the feature pages skip. When a bot posts the first round of comments, the social dynamics of review shift. The nitpicks — formatting, naming, the missing null check — get handled before a human ever looks, so senior reviewers stop spending their attention on trivia and start spending it on design. That's healthy.
It can also go wrong fast. If the tool is noisy, developers learn to scroll past AI comments by default, and once that habit forms it generalizes to the real findings too. In practice, a large share of AI review alerts simply get ignored — automation generating noise instead of signal. Alert fatigue isn't a minor annoyance; it's how a security flag gets dismissed alongside the fiftieth style nag.
According to Anatoliy Poberezhnyk, Sales Executive — DevSecOps & GitLab Solutions Expert at Cloudfresh, the teams that succeed treat the AI as the first reviewer, never the last: "In our client work, the projects that get real value set explicit team standards in config and let the model enforce them, so human reviewers are freed to argue about design instead of semicolons. The ones that struggle bolt the tool on, never tune it, and within a month everyone's ignoring it. The technology is the easy part — the discipline of curating what it's allowed to comment on is what makes it stick."
If you're standardizing this across an engineering org rather than one repo, the configuration and rollout discipline is where most of the value — and most of the pain — lives, which is why some teams bring in GitLab implementation partners to get the guardrails right before turning it on org-wide.
How do you configure these tools for the best signal-to-noise ratio?
Out of the box, both tools comment on everything they notice. That's the wrong default for any mature codebase. Three concrete moves got our noise under control.
First, set a severity floor. In Gemini Code Assist on GitHub, configure a minimum severity threshold so it stays silent below, say, Medium. You'd rather miss a stylistic quibble than train the team to ignore the panel.
Second, write the rules down where the tool can read them. GitLab Duo Code Review pulls per-file-pattern guidance from a custom review instructions file at .gitlab/duo/mr-review-instructions.yaml — Ruby conventions on *.rb, Go conventions on *.go, stricter checks on anything under your auth directory. Since GitLab 19.0 you can template these at the group level so every project inherits the same baseline instead of drifting apart. Gemini has an equivalent in its style guide configuration, a plain-Markdown styleguide.md describing how you want reviews structured.
Third, point the model at the concerns linters can't reach. A static analyzer already catches unused imports; don't spend AI review on that. Aim it at test coverage for edge cases, error-handling patterns, and the conventions that live in your team's head rather than in a rule file. That's where it produces comments a human would have written — and would have respected.
Which one should you reach for?
Honest answer: it tracks your platform, not a leaderboard. If your team lives in GitLab, Duo Code Review runs natively in the merge request with no external integration, reads your CI pipeline and issue context, and prices reviews predictably — a flat charge per MR rather than token math. If your repositories are on GitHub, Gemini Code Assist assigns itself as a reviewer the moment a PR opens and posts a summary plus severity-ranked comments.
One operational caveat worth flagging before you commit: Google is consolidating its developer tooling into a platform called Antigravity, and the individual-tier Gemini Code Assist IDE and CLI stop serving requests on June 18, 2026, with the consumer GitHub review version sunsetting July 17, 2026. The enterprise GitHub review product continues — but if you're evaluating on a free individual tier, build your pilot on the path that will still exist next quarter.
The takeaway
Treat AI code review as your fast, tireless first-pass reviewer and nothing more. Let it clear the mechanical layer so your people can spend their scarce attention on architecture, trade-offs, and the cost of being wrong. Tune it hard — severity floors, written rules, concerns the linter can't reach — because an untuned reviewer trains your team to stop reading. Get those two things right and you reclaim real hours. Get them wrong and you've added a bot nobody trusts to a backlog that's already too long.
Written by Anatoliy Poberezhnyk, Sales Executive — DevSecOps & GitLab Solutions Expert at Cloudfresh.
