AI coding assistants changed the unit economics of a pull request. Three years ago a 600-line diff meant a week of work and a careful author. Today it can mean forty minutes and a confident autocomplete. The bottleneck moved from typing to reviewing — and most teams have not adjusted.
This post is the short version of habits we have seen work across the teams using Mesrai. Nothing exotic. Most of it is older than AI. But the failure modes have changed enough that the old advice needs new emphasis.
1. Keep diffs under 400 lines, hard cap
Google's internal data on review quality is well known: defects caught per review drops off a cliff past 400 lines. The number has not changed because AI is writing the diff. If anything the ceiling is lower now — reviewers fatigue faster on code they did not type. Split aggressively. One concern per PR.
2. Author writes the description, not the assistant
An AI-generated PR description tells you what the diff did, not why. Reviewers need the why. Make it a rule: if the author cannot explain the motivation in their own words, the PR is not ready. This single rule catches an astonishing amount of code that nobody actually needed.
3. Tests for behavior, not coverage
Assistants are good at producing tests that lift coverage numbers and verify nothing meaningful. Review tests with the same scrutiny as production code. Ask: would this test fail if I deleted the function body? If not, it is decoration.
4. Reviewers read the failure modes first
Start the review at the error paths. Where does this code throw? What happens on a null input, a timeout, a partial write? Assistants write happy paths beautifully. The gaps live in the corners.
5. Prohibit defensive code that hides bugs
A pattern we see weekly:
// AI-written, looks safe, is not
async function getUser(id: string) {
try {
return await db.users.findUnique({ where: { id } });
} catch (e) {
console.error('user fetch failed', e);
return null;
}
}This swallows the error, returns a null that downstream code treats as 'user not found', and produces a 404 instead of a 500. The bug is now invisible. Reject this pattern by default. Errors at internal boundaries should propagate.
6. One assistant per PR
If your author used Claude and your reviewer asks Copilot to summarize the diff, the team has no shared mental model of the change. Pick a tool for review, train the muscle, and stick with it. Mesrai exists for this — opinionated review that surfaces the same kind of finding the same way, every PR.
7. Merge what you would merge with no AI in the room
The deepest mistake we see: teams that started trusting AI-written code more than they trust their own, because rejecting it 'wastes' the assistant's output. The output is free. The defects are not. Hold the same bar.
The summary
Smaller diffs. Honest descriptions. Behavior-driven tests. Read the failure paths first. Refuse defensive sloppiness. One reviewer-of-record. Hold the bar.
None of this slows good teams down. It slows down the bad PRs, which is the entire point.