Reviewing 100 lines of a 2,000-line agent diff relies on a build set up to fail on lint errors

The exhaustive read still happens here. The type checker, the linters, the scanners and the test suite have gone over every character before the diff is opened, and they do not get tired ^[4]. What is left for the human pass is narrower: about 100 lines of the 2,000, read slowly, twice ^[2]. Five percent of the change ^[23].

The case against even coverage is an attention curve. Spread the same care over 2,000 lines and everything looks fine, focus gives out around file twelve, and the real problem sits in file thirty-one ^[3]. Twelve of forty files is 30 percent, so seven files in ten get read on a depleted budget ^[24].

What the toolchain cannot check falls into four classes, according to the post. Intent: the agent answers the question it understood, so a loose description returns something coherent and slightly off target ^[10]. Architecture: "It writes a new helper instead of finding the existing one, because writing is easier than looking" ^[11]. Scale: "A cathedral when you asked for a garden shed" ^[12]. Cost over time: it optimises for what works today, and does not ask whether the shape can absorb the next three changes or forces a refactor with a heavy migration attached ^[13].

Most of the review then moves ahead of the code. Every prompt ends with a version of one instruction: "Plan this before writing any code. Ask me the questions that would make the spec precise, and challenge anything that looks wrong or missing." ^[14] The reply is about ten questions, two or three of which cover things the author had not thought about: what happens to the rows that already exist, whether a limit is per user or per organisation, whether "recent" means this week or this session ^[15]. "Half of what I used to catch in diffs now never gets written," he wrote ^[16].

The answers get written down as ADRs, one short file per decision, with the choice and the options that lost ^[17]. Those files are read first when the diff lands, before any code; if one describes a decision he never agreed to, the diff is already wrong, and he puts the saving at twenty minutes ^[18]. The same files stop a later session with a different agent from quietly reversing the decision ^[19].

Whether any of this transfers depends on the disclaimer the post puts near the top. The repo is typed, the linters fail the build, the tests are real, the layers are clear, the conventions are boring ^[5]. "AI is an amplifier: a good codebase gets better, a bad one gets worse," the author wrote ^[6]. The operative word in that config list is fail. A linter that prints warnings into a log lets the build pass. Where the gate is advisory, the coverage on the other 1,900 lines is zero ^[28].

The post does not report a defect escape rate, or a count of what the old review caught against what this one catches ^[27]. The evidence is one practitioner's routine, settled over a few years and after a couple of outages he says showed him where the expensive mistakes live ^[21]. In my view the half that travels without a strong toolchain is the planning prompt and the ADR file, because both operate before any code exists ^[14][17]. The 100-line read travels only where a blocking CI gate supplies the coverage it assumes ^[5].