A 5,000-line pull request from an agent is not a 5,000-line pull request from a colleague. It arrived in an afternoon, it almost certainly does four things, and its description was written by the thing that wrote the code. Reading it top to bottom is the wrong first move. Here is a method that takes two or three hours instead of two days, with the commands, and with the parts Firetrail does for you marked as such.
updated September 4, 2026 · every fact links to where we checked it
SmartBear's study of code review at Cisco (2,500 reviews, 3.2 million lines, 50 developers) is still the best data we have. Reviewers who went slower than 400 lines an hour found more defects than average; faster than about 450 lines an hour, they found fewer than average in 87% of cases. The same study puts the useful ceiling at 200 to 400 lines per sitting, with 60 to 90 minutes yielding 70 to 90% of the defects.
At 5,000 lines, reading carefully is 12 hours or more, spread over days, with accuracy falling the whole time. Reading quickly is worse: you finish in an afternoon having found the typos. Neither is a review. Google's engineering practices say the same thing from the other side: small changes get reviewed faster, more thoroughly, and with fewer bugs introduced, which is why the method below ends in a split more often than in an approval.
Agent-written PRs add their own problems on top of size. The description came from the model's plan, not from the diff, so it shares the code's blind spots. The tests came from the same run as the code. And nothing in the PR says which of the 5,000 lines the author actually read. So the method starts by rebuilding the facts the description should have given you.
Times are for a 5,000-line PR. Every step is tool-agnostic; the peach box says what Firetrail already did by the time the PR opened.
gh pr view 412 --json files --jq '.files[].path' | sort git diff --stat main...feature/invoice-export | sort -k3 -n -r | head -40
Group the files by area (API, UI, migrations, config, tests, generated) and write down how many deliverables you see. A UI and the API behind it are two. A dependency bump is one. A refactor the agent did on the way is one. Tests and docs that accompany a change don't count.
where Firetrail does this for you
The Multi-Intent check counts the deliverables on every PR and the Refactor + Implementation Mix check says whether a cleanup is tangled with a behavior change. Both are in the comment's breakdown with their evidence.
Two lists. Promised and delivered: each claim in the description, found in the diff. Delivered and not promised: everything in the diff that the description never mentions. The second list is where the surprises live: the timeout that got raised, the retry that got added, the default that changed, the test that got loosened. Search the diff for timeout, retry, rescue, catch, default, skip, xit, TODO.
where Firetrail does this for you
Intent drift (Pro and up) produces the second list with evidence and a short theory of why each change is there, and the PR comment warns when the diff quietly does something the description never said.
Order the files, and read them later in this order:
A change to any of the first four is worth a question to the author on its own, regardless of the feature.
where Firetrail does this for you
Global Config Change and Package Update flag the wide-blast-radius files on every plan. The Review Brief lists every changed endpoint with its contract (before and after for modified ones) and one table per database table for the schema diff.
Before the code. For each new test: what is mocked, and is the unit under test among the mocks? Do assertions check behavior or restate the implementation? For each existing test the PR touched: was it loosened, skipped or deleted? Then ask which added production lines no test reaches. In a 5,000-line agent PR the answer is usually “most of the error handling and all of the authorization”.
where Firetrail does this for you
Patch coverage (Pro and up) reads every added production line and estimates which the PR's own tests reach, listing the untested ranges per file and which test reaches the covered ones. Test Relevance asks whether the changed behavior is tested at all. Mike, the QA reviewer, names the missing cases when he is in the project's lineup.
You have enough to decide without having read the feature code. Merge as is: one deliverable, description matches, blast-radius files are fine, tests prove the behavior. Rare at 5,000 lines outside mechanical renames and generated code. Split: more than one deliverable. Send back: the description is wrong about something material, or a blast-radius change has no justification. Write the decision down before you read a line; reading tends to talk you out of it.
where Firetrail does this for you
The Future Debug Cost band is the summary: Low and Moderate usually merge, High means read the breakdown first, Critical means split. The verdicts from the review team say the same thing per specialty, and a well-written PR that is doing too much gets a meh at best with a suggested split.
By hand: one branch per deliverable, carry the files over, keep a chain where one depends on another.
git checkout -b invoice-export/api main git checkout feature/invoice-export -- app/controllers/api/v1/invoices_controller.rb app/services/invoices/export.rb spec/requests/invoices_spec.rb git commit -m "Add the invoice export API" # next deliverable builds on this one git checkout -b invoice-export/ui invoice-export/api git checkout feature/invoice-export -- app/javascript/invoices/
Or tell the agent that wrote it: “split this into one PR for the export API, one for the UI stacked on it, one for the timeout change with the p99 that justifies it; leave the rename out.” Agents are good at this when told where the lines go.
where Firetrail does this for you
On Business, Firetrail wrote the Rework plan when it analyzed the PR: one intent per PR, the files each carries, the findings each fixes, acceptance criteria, branch names, and which steps chain. In your coding agent: rework PR 412 with Firetrail. It shows the plan, asks, opens one draft PR per step, and never touches the original branch. Skip a step or steer the plan in the app first.
Each split PR is 800 to 1,500 lines, and you've already decided what it is. Read in the blast-radius order from step three. Let a line-comment bot (CodeRabbit, Greptile, Copilot, Bugbot, Claude Code Review) do the mechanical pass and read its findings alongside. Human attention goes to: error handling that swallows exceptions, anything with retries or timeouts, duplicated helpers that already exist in the repo, and every place two variables of the same type sit next to each other.
where Firetrail does this for you
Each new PR is analyzed on its own, so you can compare the score of the parts with the whole. The original PR's comment links to its parts. This step is the one Firetrail doesn't do for you: keep your bot for the lines.
Explain the three riskiest hunks without looking at them. If you can't, you're approving code nobody understands. Then write the note the on-call engineer will want: what to watch after deploy, how to roll back, which config changed.
where Firetrail does this for you
The PR Quiz (Pro and up) turns the top risk drivers into two to four questions with three plausible readings each; the answer is recorded on the PR. Sarah, the SRE reviewer, writes the deploy-and-rollback concerns for you when she is in the project's lineup.
Whether the author is a person or an agent, the useful comment is the same shape: what the PR is, what it should be, and what's missing. A template:
This PR does three things: the invoice export API, its UI, and a gateway timeout change. I'd like them as separate PRs so each can be reviewed and reverted on its own: 1. Export API + CSV builder + job (fix the N+1 in the builder while you're there) 2. Export UI, stacked on 1 (needs loading and error states) 3. Timeout change alone, with the p99 numbers that justify it The description doesn't mention the timeout or the retry added in PaymentClient; please call those out. The new tests mock PaymentClient itself, so nothing exercises the retry path; a test against the real client with a stubbed gateway would.
An agent given that comment will usually produce the three PRs correctly. A person will too, and will appreciate that the review told them the shape rather than 140 inline nits.
| Approach | Time | What you get |
|---|---|---|
| Read all 5,000 lines carefully | 12+ hours over several days | Accuracy falls past the first 400 lines; the shape of the change is still unclear at the end |
| Skim it in one sitting | 2 hours | Typos and naming. The bundled timeout change and the mocked-out test ship. |
| This method | About 1 hour to decide the shape, 30 minutes to split, 60–90 minutes of line review on the parts | A decision made on facts, PRs small enough to review well, and a note for on-call |
| This method with Firetrail | Steps 1–4 are in the PR comment when it opens; step 6 is one sentence to your agent | The same, with the score, the drift, the coverage and the split plan already written |
Sometimes: a mechanical rename across 400 files, generated code, a vendored dependency, a formatter run. Those are big and harmless, and Firetrail's Triviality check exists to discount exactly them. A 5,000-line PR that implements a feature is almost never one deliverable and almost never should merge as one.
Decide the deliverables, then either carry files over branch by branch with git checkout from the original branch, or tell the agent which pieces go in which PR and in what order. On Business, Firetrail writes that plan for every analyzed PR and your agent executes it as draft PRs after you confirm.
It's a useful first pass and a poor last one: the same model has the same blind spots, especially about what it left out of the description. Use a different reviewer, tool or human, for the shape decision and the risky hunks.
A PR too large for the model to read in one pass gets a partial analysis: the highest-churn files plus every config, migration and dependency file, clearly labeled as partial with reduced confidence. A Turbo Analysis re-runs the whole pipeline on a model with a much larger reading window so the PR is read in full; each paid plan includes a monthly allowance per seat.
Don't read faster. Read less: decide the shape first, split, and then read PRs small enough that 400 lines an hour covers them. Let a bot do the mechanical pass. Spend human attention on blast-radius files, tests and the hunks you can't explain.
Firetrail's comment carries the deliverable count, the drift, the blast-radius flags and the coverage estimate a minute or two after the PR opens. Free for one repository.