Two pull requests land. A colleague wrote one by hand, and you read every line. The other came out of an AI tool, and it looks clean, consistent, and idiomatic. You scan it, leave no comments, and approve.
If you had done that on your first week of reviewing AI code, you would not have. You were careful then. Something changed in between, and it did not change because you decided it should.
🔍 What the data actually shows
Start with the part that goes against the common complaint. Reviewers are not casually waving AI code through from the start. Measured across large samples, the opposite happens. One benchmark covering 8.1 million pull requests from 4,800 teams found AI-generated pull requests were accepted at 32.7%, against 84.4% for human-written ones. Another study found senior engineers spent about 4.3 minutes on an AI suggestion against 1.2 minutes on human-written code. Reviewers also go back and forth about 12% more on AI code.
So the first instinct is right. People do treat this code as suspect.
The problem is what happens to that instinct over time.
A study tracked 400 reviewers who each reviewed repeatedly over seven months, covering more than 11,000 reviews. It compared each reviewer's early reviews with their later ones. Approval rates for AI agent pull requests rose from 30.1% to 36.8%. Over the same period, the same reviewers became more critical of human-written pull requests, not less. The change was not explained by the pull requests getting easier, and it held after accounting for the calendar date.
Two numbers from that study matter more than the approval rate. Review latency went up by three and a half times. Inline comments went down by 22%.
Read those together. Reviewers spent longer with AI pull requests and inspected them less. The time went into the queue. It did not go into the code.
That is habituation, and it is a well-known effect. Repeated exposure to something that usually turns out fine gradually lowers the attention you give it. Nobody makes a decision to care less. Attention just quietly reallocates.
🧠 Why this lands on seniors first
The study measured repeat reviewers, and that is the group this happens to. If habituation comes from repeated exposure, then whoever reviews the most habituates first.
On most teams, that is you.
There is a second reason, and it is about consequence rather than exposure. When a junior's attention drifts on a review, a senior often catches it downstream. When a senior's attention drifts, nothing catches it. You are the last check, and you are also the person whose review behaviour sets what the rest of the team thinks normal looks like.
The failures that get through are the kind you would expect from code nobody thought about carefully. A transformation that is correct today and that nobody on the team could safely modify in six months. Aggregation logic that runs clean and returns numbers that are quietly wrong, which a business user finds weeks later.
Neither of those is caught by reading faster. Both are caught by reading differently.
✅ Raise the bar, and measure the right thing
Two changes. The first is a rule, the second is what tells you whether the rule is working.
Require the author to state what they verified themselves. Not "AI wrote this." Something specific: which parts they ran, which assumptions they checked, what they did not check. This does two things. It puts the burden back on the person submitting, and it tells you where to spend your attention. A pull request that says "I verified the join keys but not the null handling" has told you where to look.
Review for maintainability, not only correctness. Ask one question of every AI-assisted change: could someone else modify this in six months without the original context? Generated code tends to drift toward generic patterns rather than your team's, and toward default error handling rather than yours. Each of those choices is individually defensible and collectively produces a codebase your team does not recognise. One study across more than 800 GitHub projects found static analysis warnings rose about 30% after AI adoption, with complexity rising over 40%.
Now the measurement. Do not track how long reviews take. That number goes up while attention goes down, which is exactly the trap. Track inline comments per pull request, and watch it over months.
If your comment count on AI-assisted pull requests is falling while the volume rises, that is habituation, and you can see it in the numbers before you can feel it in yourself. That is the whole value of measuring it.
⚖️ The objection worth taking seriously
The weak version is "this will slow us down." Easy to answer.
The strong version is an allocation problem: review capacity is fixed. Raising the bar on AI pull requests means lowering it somewhere else, and you have not said where. Nobody is given extra hours because the review policy changed. In practice, stricter AI review means slower human pull requests, or fewer design discussions, or a senior who stops writing code.
That objection is correct and the honest answer concedes most of it. There is no version of this where the time comes from nowhere.
What I would say is that the allocation already moved, without anyone choosing it. One report found AI-generated pull requests wait 4.6 times longer than human ones just to be picked up. Review is already the constraint on most teams. The question is not whether to spend more attention on AI code, because you already are. The question is whether that attention lands on the code or evaporates in the queue.
There is also a finding that should unsettle everyone, on both sides of this argument. In a controlled study, experienced developers using AI tools were about 19% slower, while believing they had been 20% faster. If your sense of how fast the team is moving is that unreliable, then "this will slow us down" is a claim to measure rather than to assume.
One caution on all these numbers. Several come from companies that sell code review tools, and their figures are not neutral. The habituation study and the developer speed study are independent, and those are the two the argument actually rests on.
🎯 The takeaway
An AI-assisted pull request checklist:
1. The author states what they verified themselves. Specifically, including what they did not check.
2. Ask the six-month question. Could someone else modify this without the original context?
3. Track inline comments per pull request, not review time. Time goes up while attention goes down. Comments are the honest signal.
You did not decide to read AI code less carefully. That is what makes it worth measuring, because you will not notice it happening.
