AI code review overhead is the new review tax — here's where it goes, and how to cut it

When generation gets cheap, every other step downstream gets more expensive in proportion. An engineer who used to open two PRs a day now opens six, because the agent does the typing — but each of those PRs still needs a human to read it, and the human didn't get six times faster. The queue grows, review becomes the constraint, and the constraint is staffed by your most senior people, which is the most expensive place for a bottleneck to live.

Worse, the reviewing isn't even the high-value reviewing yet. Before anyone can ask "is this the right approach? does this handle the edge case? does this fit the architecture?" they first have to wade through slop: skim past the comments narrating the obvious, mentally diff the four near-identical blocks, squint at the function that does the right thing in a way nobody on the team would have written. The judgment work — the part only a human can do — happens last, after the de-slopping tax has already been paid.

Slop is predictable because the tools that produce it take predictable paths. quality·vibes is built around the patterns that show up again and again: overly verbose comments (a paragraph explaining a one-line getter), repetitive or duplicated blocks (the same fetch-and-handle logic stamped across components), non-idiomatic language usage (Python written like Java, a for-loop where the language has a built-in), inconsistent naming (userId here, user_id there, uid two lines down), and basic structural or architectural deviations (a new file that ignores the layering the rest of the repo follows).

Each of these is individually small and individually easy to miss, which is exactly why they accumulate. A human reviewer catches some and lets others through because they're tired, or because the PR is 40 files long, or because flagging "this comment is redundant" for the fortieth time feels petty. An AI reviewer doesn't get tired and doesn't feel petty — it flags every instance, in place, at the same standard, so the human can accept the obvious ones in a click and spend their attention where it counts.

You connect a GitHub repo and quality·vibes fetches its pull requests and diffs. The analysis engine reads each diff and annotates the slop patterns directly on the changed lines — not in a separate report you have to cross-reference, but inline where a reviewer already looks. Every flag comes with a suggestion and an accept/dismiss control, so triaging slop becomes a fast pass rather than a writing exercise, and each PR gets a slop score from 0 to 100 that tells you at a glance whether this is a clean change or one that needs a real cleanup conversation.

The honest framing matters here: quality·vibes does not auto-merge and does not auto-apply fixes — you accept suggestions, a human stays in the loop, and the tool never silently rewrites a teammate's branch. It's a reviewer's force multiplier, not a replacement for review. It also won't tell you whether the business logic is right or the design is sound; that's still the human's job, and the whole point is to give them back the time to do it. The slop layer is what gets automated; the judgment layer is what gets protected.