The diff gets fetched twice, in effect. `actions/checkout@v4` runs with `fetch-depth: 0` [8], which pulls the entire history, and the next step downloads the diff separately with `gh pr diff` into `pr.diff` [9]. The path shown reads the file itself rather than local git history; `ai-review.mjs` reads the file [20]. A full-history clone is a cheap habit right up until the repo is not small.
The chunk boundary is the design decision I would copy, and the stated reason is the right one: an arbitrary line split hands the model half a function, while a file split gives it one complete before and after [11]. It also sets a floor. File is the smallest unit in the split, so a single 3,000-line file stays a single request no matter how the aggregate threshold is tuned. The other throttle worth noting is the `if` block, which skips dependabot, `release/` branches and drafts [7]. The draft exclusion is the only one an author can operate directly.
What the catch rate measures is narrower than it reads. The prompt casts the model as a senior Java/Spring Boot engineer and asks for only real, high-confidence issues, with an explicit do-not-flag list starting at style preferences, minor naming and Javadoc on non-public methods [12][13]. So the denominator is issues that somebody eventually found: a defect the AI missed and no human caught is not in it. The post, up to the point where its text stops mid-prompt, gives no false-positive rate, no count of flagged issues, and no comparison against whatever linting the pipeline already ran [21]. Without a baseline, 30 to 40 percent is an improvement over an unstated starting point.
The before-state arithmetic holds up better. Four to six hours a day across five days is 20 to 30 hours a week, spread over 70 to 100 PRs. That is between about 12 and 26 minutes of senior attention per pull request [1]. Twelve minutes is roughly the time it takes to read a medium diff once, which is why the queue was producing "you forgot to close the stream" comments from an expensive reviewer [2].
One figure does not reconcile. Six months is about 26 weeks, and 100 PRs a week caps that window near 2,600. Reaching 4,200 requires roughly 162 a week [2]. Either the cadence has grown past the stated range, the measurement window is longer than six months, or the count covers more repositories than the single review queue described, and the post leaves open which of the three explains the gap.
From this I would take the file-level chunk, the draft gate, and the choice to put comments inline rather than in a summary at the bottom of the thread, which the author says gets ignored [17]. I would not take the percentage without re-measuring against my own defect mix. The claim that reviewers now spend their time almost entirely on architecture and business logic rests on the writeup's own numbers: it reports the 4 to 6 hours a day before the change but gives no equivalent figure after [22].
