Your team ships far more code than it did a year ago and reviews it exactly the way it always has. That is the part that breaks. The agent is not the bottleneck any more. The person reading every line of its output is.
Anthropic published its own version of this problem on 14 September 2026. Its engineers now ship around eight times as much code per quarter as they did across 2021 to 2025, Claude authors roughly 80 per cent of it, and continuous integration job volume rose 25 times over six months. Writing code stopped being the constraint. Everything downstream of writing became one.
Why line-by-line review stops working
Reviewing every line was never a quality control. It was an affordable habit. When a senior developer produced 200 lines of considered change a day, reading all of it took twenty minutes and felt responsible. When an agent produces 2,000 lines across six branches, the same habit produces a queue, and a queue produces the thing you were trying to avoid: skimming, but pretending otherwise.
The failure mode is not that reviewers miss bugs. It is that they spread the same attention thinly across everything, so the migration that could drop a column gets the same three minutes as the CSS fix. Thin uniform attention is worse than deliberate uneven attention.
What should you actually review in Claude Code's output?
Review what is expensive to get wrong and cheap to check: the interface a change exposes, anything touching authentication, money movement, personal data or database schema, and the tests themselves. Read the test diff before the code diff, because a test that was written to pass tells you more about the agent's understanding than the implementation does. Everything outside that set can be sampled rather than read in full, as long as each change arrives with evidence attached.
Set the review depth by what the change can break
The practical move is to stop deciding review depth per pull request and decide it once, per class of change, then apply it without renegotiating. The table below is the starting split we give Australian teams. Adjust the sampling rates to your own incident history rather than ours.
| Change class | Review depth | How much you read |
|---|---|---|
| Schema migration, auth, payments, personal data under the Privacy Act | Full read, plus a second reviewer | Every line, every time |
| Public API or shared interface change | Read the interface and its callers, skim the body | Every change |
| New feature on an isolated path | Read the tests first, then the diff summary | Every change, shallow |
| Bug fix with a failing-then-passing test | Read the test, confirm it fails without the change | One in three |
| Refactor with no behaviour change | Confirm test output is identical, skim the file list | One in five |
| Formatting, generated files, dependency bumps | Check the file list and the lock file | Spot check weekly |
The point of writing it down is that it survives a busy Thursday. A rule you hold in your head becomes whatever you have time for.
Three questions that replace reading every line
For anything in the sampled tiers, these three questions do most of the work that line-by-line reading used to do, in about a tenth of the time.
Did it do what was asked, and nothing else? A diff that touches files outside the request is a flag no matter how good the code inside it looks.
Is there a test that failed before and passes after? Without that, a bug fix is an assertion. Ask for the before run, not just the after.
What else does this touch? Ask the agent for the callers, config and migrations affected, then check that list against the diff instead of reading the diff cold.
Two of the three are answerable without opening the code. That is the whole saving.
The changes you never sample
Some categories stay at full human review regardless of how good your agent workflow gets, because the cost of being wrong is not measured in engineering hours.
Anything that moves money, or changes who can authorise it.
Anything that deletes or migrates production data, including a migration that looks reversible.
Anything that changes what personal information is collected, stored or shared, which in Australia is a Privacy Act question before it is an engineering one.
Anything a regulator could ask you to explain later. For teams under APRA supervision, that is a wider set than it first looks.
Keeping this list short matters as much as having one. A list of fifteen exceptions is the same as no list.
Sampling is only honest if the rest carries evidence
Reading less is a defensible position only when the changes you did not read came with proof. That means real test output, lint results and a type check attached to the change, produced by the agent as part of finishing the task rather than asserted afterwards. Our earlier piece on Claude Code verification patterns sets out the workflow rules that make that routine.
Without that, sampling is not a review strategy. It is just reviewing less, and the difference will show up in production eventually.
Whether lighter review raises the bug rate
In the teams we have moved onto tiered review, the defect rate on sampled tiers did not move much. What moved was where defects were found. More were caught by tests and fewer by reviewers, which is the correct direction, because a test catches the same problem again next month and a reviewer does not.
The honest caveat: this only holds where the test suite is worth trusting. If your coverage is thin on the paths the agent is changing, tiered review will feel efficient right up until it is not. Fix the suite first, then reduce the reading.
What the current approach is costing you
Put a number on it before you change anything. A senior reviewer spending two hours a day reading agent diffs costs roughly 440 hours a year. At an indicative fully loaded rate of $110 an hour in Sydney, that is about $48,000 a year per reviewer, and on most teams it is more than one person. These are planning figures, not a quote, but they are usually enough to settle the argument about whether the current habit is free.
If you want to model the trade against your own numbers, our ROI calculator works on the same inputs, and our services page covers how we set these workflows up. The Anthropic engineering write-up on scaling CI under agentic coding is worth reading if your pipeline is feeling the same strain.
Where to start this fortnight
Write the tiering table for your own repository and put it in the contributing guide. Pick one tier to sample, not all of them, and run it for two weeks. Track what the sampled tier let through. If nothing, sample the next tier down. If something, tighten that one row rather than abandoning the approach.
If you want a second opinion on where your review line should sit, book a short call and we will look at your change mix with you. We will tell you plainly if your test suite is not ready for it.
