Two reports, one story: what Faros and our research say about code review in the AI era

In August we published our research - The State of Code Review 2026. We went through 77,949 merged pull requests in 261 public GitHub repos and checked how code review changed between 2019, 2022 and 2026.

Our research had one weak spot: it's public GitHub only. Most paid work happens in private company repos.

Recently Faros published their AI Engineering Report 2026, and they looked at exactly the part we couldn't see - private company data. Faros sells a platform that companies connect to their engineering tools, and the report is built from what flows through those connections, from 22,000 developers and 4,000 teams. It's not a survey, nobody typed answers into a form, these are automatic records of what people actually did in their tools.

So I read the whole report and put it next to ours. A lot of things match, some don't, and I think the differences are even more interesting than the matches.

Two different ways of looking

Before comparing any numbers, it's good to know that these two studies are really different.

In short, Faros measured what happens around the review and after it - how long things take, how many bugs and incidents come out. We measured what happens inside the review, so if the person who clicked approve said anything at all.

One more thing worth knowing. Neither sample is random. Faros data is their own customers, so bigger companies that care enough about engineering numbers to pay for a tool that measures them. Ours is public GitHub, so whatever is still alive and open in 2026.

And both reports come from companies that sell something. Faros sells engineering measurement, we sell Reviewsaur, so read both with that in mind - I'd say the same about ours. But I think that's actually what makes the comparison useful. Two different companies, with different data and different reasons to publish, and the results still point the same way. That's harder to wave away than one report alone.

Where we meet

Even with such different data, a lot of findings point the same way.

One honest note before going further. Faros compares averages between low and high AI periods of the same team, and we compare typical values over the years, so the numbers are not 1:1. But in both datasets PRs got roughly half bigger, and that's already a lot.

The part of the Faros report that I liked the most is about why AI code is so hard to review. They write that it's "superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase. It looks like code written by someone who knows what they are doing."

This is exactly what I keep talking about. AI code looks clean, so it's super easy to approve. But good names and nice comments don't mean the logic is right, the problems sit underneath, and to find them you need to understand what the code was supposed to do in the first place. Just reading it is not enough.

We even agree on what to do about it

Faros conclusion is that "this is an authoring problem, not a review problem". So instead of stricter review, give AI tools better context about your codebase, and the code will be better from the start.

I agree with this. Better context means fewer bugs, and having your agent rules set correctly for your repo and architecture helps a lot.

I would only add one thing - fewer bugs doesn't mean more knowledge. Even if AI writes perfect code, somebody in the team still needs to understand it. I think review was never only about catching bugs, it's also the moment when knowledge moves from one head to another (or now, from the agent to at least one head).

And Faros doesn't throw review away either. In their recommendations they say every PR must pass some kind of gate - a human, an AI agent, or both - and that human review comments are "the signal that matters most".

We also agree that not every PR needs the same careful review. Faros says that "every PR must have a human review" will break under the amount of code AI produces, so you should decide by risk. Security-sensitive parts, high-stakes systems and customer-facing services need human eyes, lower-risk parts can be checked by an AI agent.

This is basically how Reviewsaur works too. For every PR it first checks if the change is trivial - a typo, a docs change, a version bump - and if it is, the check just goes green and nobody has to do anything. Careful review is demanded only where it matters, and you can mark paths like billing, auth or migrations so they always need it.

Where we see it a bit differently

Now the interesting part. There are three places where our findings don't match, and I think each of them says something.

1. Nobody looks vs nobody talks

In Faros customers' data, 31% more PRs got merged without any review at all, when teams were at their highest AI use compared to their lowest. We saw the opposite - in the team repos we followed since 2019, PRs merged with zero review went down from 14.2% to 1.6%.

So on public GitHub somebody still clicks approve. They just don't say anything.

I don't think any of us is wrong here, these are different kinds of teams. My guess is that it's the same problem seen from two sides. Either nobody looks at the PR, or somebody looks and says nothing - and from the outside you can't tell if that silent approve was a careful read or just a click.

2. More comments, but from whom?

Faros sees 25% more review comments per PR, and the comments got longer too. But they say themselves that they can't tell human comments from bot comments, and AI review tools went from zero to a quarter of all PRs in their data.

We count only humans, and humans got quieter. We also checked if people stay quiet because a bot already commented - and no, it's the other way around. When we left out PRs where a bot reviewed first, silent approvals went up even more, 12.3 points instead of 8.5.

So more comments in a PR doesn't mean more people paying attention. Part of it is probably just bots.

3. Why their numbers are so much bigger

Faros numbers are huge - review time more than 5x longer, incidents per merged PR more than tripled. Ours are much smaller, plus 8.5 points.

It's not a contradiction, we just measure different things. They compare each team at its lowest and highest AI use, we look at a slow change over years. And time spent in review is something else than words written in a review, so I wouldn't put these numbers against each other.

What none of us can prove

None of these reports proves that AI caused all of this.

Faros shows that worse numbers go together with more AI use, inside the same teams - and they say it themselves, it's correlation, not proof. Also their teams are their customers, mostly bigger companies, so it might look different in a 20-person startup. The same goes for us the other way - ours is public GitHub, so a private team might look different too.

On our side, we see the change starting in the AI era, but return to office and layoffs happened in the same years, and they fit the timing too. And we can't really check it, because there is no group of teams without AI left on GitHub to compare with.

We also tried to connect silent approvals with bugs. On 55 repos it looked like PRs without review needed a bug fix twice as often, but when we checked 81 repos, 43 of them pointed the other way. So we withdrew it, and that's why I'm careful here - I don't say that silent approvals cause bugs.

What I can say is this. Faros sees bugs and incidents going up, we see human attention in review going down, and both happen at the same time. Two independent studies with different data and different methods, pointing in the same direction - I think that's enough to take it seriously.

Your repo is a mirror of your team

If I had to sum up both reports in one sentence, it would be this: your repo is a mirror of your team.

How you do code review shows how your team really works. Not the process written in Confluence, but what actually happens when a PR comes in - who reads it, who asks questions, who just clicks approve, and who does all the reviews alone. It's all there in your PR history, you just need to look.

So we built a free tool for this: analyze your repo. It shows how many approvals in your repo are silent, how many PRs go in without any review, and if one person carries most of the reviews.

And if you don't like what you see there - that's exactly why I built Reviewsaur.