Two numbers landed in the same week and they explain more about the current interview bar than either one does alone. Meta reported a 106% year-over-year increase in lines of code per human-landed diff. Separately, a new benchmark called SlopCodeBench measured something engineers have felt but not quantified: AI-generated code accumulates duplicated abstractions and structural decay at roughly twice the rate of human-written code, and on multi-round tasks — the kind where an agent keeps building on its own earlier output — the strict pass rate collapsed to 0% as small bad decisions compounded across context resets.
Put those next to each other and the shape of the problem is obvious. The volume of code arriving for review more than doubled. The number of hours in a reviewer's day did not.
The tension: coverage was already a fiction
Full-coverage code review — reading every line, understanding every decision — was never fully real even before AI. Reviewers skimmed, trusted the author's judgment on routine parts, and spent their real attention on the sections that felt risky. That worked because the volume was survivable and a human author's mistakes clustered in predictable places.
AI changed both halves of that deal. The volume roughly doubled, per Meta's own numbers. And the mistakes stopped clustering predictably — SlopCodeBench's finding isn't that AI code has more bugs, it's that it has more structural decay: abstractions that almost make sense, duplication that tests do not catch, choices that compound quietly instead of failing loudly. That is a harder thing to skim for than a typo or an off-by-one.
SlopCodeBench is not measuring whether the code works — plenty of it does. It is measuring whether the code stays legible and non-redundant as an agent keeps extending it across multiple rounds. That is a different failure mode than a bug, and it is the one full-coverage review was worst-equipped to catch even before volume doubled.
The insight: the skill quietly narrowed from coverage to triage
A team that cannot review everything twice as carefully has two options: burn out, or change what "review" means. Most are quietly doing the second. A widely discussed engineering post making the rounds this week — arguing that AI did not break code review so much as expose that review was already being asked to do too much — makes the case plainly: reserve human review for architectural and security-relevant changes, and push routine correctness checks to pairing, fitness functions, and automated gates instead.
That is not a lowering of the bar. It is a redefinition of what the bar tests. The valuable skill was never "can you read every line." It was always "can you find the one decision in this diff that will actually hurt someone in six months" — full coverage just used to be a viable, if inefficient, way to get there. Now that coverage is off the table, the underlying skill is the only thing left, and it is the thing interviewers can actually isolate and test directly.
| Coverage-era review | Triage-era review |
|---|---|
| Read every line in order | Scan for the highest-risk section first |
| Flag anything that looks slightly off | Flag only what would actually break in production |
| Treat all diffs the same | Weight architectural and security changes heaviest |
| Success = nothing missed | Success = the one thing that mattered got caught |
How this shows up in interviews
This is exactly the shift behind the review-round and take-home formats spreading through 2026 loops. An interviewer handing you a diff and forty-five minutes cannot expect line-by-line coverage either — they are watching for the same triage instinct a real team now depends on: do you go straight for the part of the diff that carries real risk, or do you spend your limited time evenly across a page of code where most of it does not matter?
Reading a review diff top to bottom, commenting on every line, feels rigorous. In a time-boxed interview it usually means you never reach the one part that actually mattered. Interviewers read even, undifferentiated attention as a missing triage instinct — the same gap a team drowning in a 106%-bigger diff volume cannot afford either.
Practice the muscle, not the checklist
You cannot memorize your way into good triage because it depends on recognizing risk in code you have not seen before. What you can practice is the discipline of spending your limited time unevenly on purpose — scanning for shape first, naming what you are skipping, and defending that choice out loud when pushed. That last part is the one most practice misses: reading a diff alone is silent practice for a round that is entirely about narrating your reasoning under pushback.
Rubduck's mock interviews put you in front of an AI interviewer that hands you a diff or a take-home submission and pushes back on what you chose to flag and what you chose to skip — the same triage judgment a review round actually grades. Start your free sessions →