Loading today’s stories
Build1 distinct publisher3 min readPublished
Code review has always been sampling, and the signals it sampled stood in for a mind that had read the code. A dev.to post argues that when diffs arrive without one, what needs rewriting is the process, not the effort.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Count the twelve questions by what each one needs. Three sit before you read the code: the one-sentence intent from whoever asked for the work, the split between the parts that arrived whole and the parts a human wrote, and a line you pick for the submitter to explain [9]. Six are for while reading, covering whether every function, flag and constant exists, whether the error handling does anything, the second call, halfway failure, untrusted input, and blast radius outside the diff [11]. Three come before approving: production-volume cost, whether the thing already exists in your utils package, and whether a stranger can debug it at 3am from code and logs [13]. So nine of the twelve are answerable from the diff and the repository around it, and the three that need a live person are exactly the ones placed before review starts [18].
Fifteen seconds is a suspiciously low price for the item the author rates highest [10], and the reason it is low is that the asking was never the expensive part. The missing thing leaves no trace in the artifact, which is why a retry loop reads identically whether or not anyone considered idempotency [7]. Re-reading does not recover it. Nor does reading for hesitation, because generated code is uniformly assured across the parts it got right and the parts it invented, so the hedge that used to mark uncertainty is not in the text [5]. A model reproduces the surface features of a careful author without the thing underneath [3]. The one probe it cannot sit for is a spoken account of a line the reviewer chose.
That elevates question one from paperwork to load-bearing. If the same process wrote the implementation and the tests, you do not have a check, you have one opinion written twice in two files, and a test derived from an implementation only asserts that the implementation does what it does [15]. The requester's sentence is then the only description of intent that did not come out of the same generation [9]. Tests bound to that sentence are a check. Tests bound to the diff are a transcript.
What would have to be true for the full twelve to be worth the throughput they cost: your generated hunks would have to escape defects at a higher rate than your hand-written ones. The post does not measure that. Its only quantity for how much the input has changed is that a meaningful share of diffs now arrive with no reason behind them while the checklists have not changed a word [16]. The mechanism is convincing on its own terms, since plausibility went up and correctness stayed where it was [6]. The experiment that would settle it is cheap and boring: one provenance label per hunk, then a quarter of escaped-defect counts split by label. If the rates come out level, the old sampling still holds and the checklist can stay a spot check [8].
Ranked by verification strength, evidence, and original report placement.
Reviewing has always been sampling: you do not verify a 300-line diff line by line, you read it for signals and extend trust across the rest where the signals are good, because there has never been a version of the job with time to do otherwise.
The review signals were proxies for a mind: whether the person knows the codebase, thought about the failure case, and chose names that suggest they understand the domain. A model produces the surface features of every one of those without the thing underneath.
Style consistency stops being evidence: a human whose code matches your conventions has usually read your code, while a model matching your conventions has pattern-matched from whatever was in its context window, which might be two files.
Confidence stops being evidence: people hedge where they are unsure with a TODO, a defensive comment or a question in the PR description, whereas generated code is uniformly assured across the parts it got right and the parts it invented.
In the post's example a diff wraps an HTTP call in exponential backoff with jitter, three attempts and a sane cap; the checklist never had to ask whether the retried operation is idempotent because a human who wrote the loop had at least glanced at the question, and the diff looks identical either way.
The post offers twelve questions for a diff you did not write, says most were already on somebody's checklist, and says what changed is that they used to be spot checks and now they are the review.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 3, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The best review comment asks whether the code belongs, and Microsoft's numbers back it1 distinct publisher
build
Coverage at 80% was a price on human attention, and CI is the wrong place to charge it1 distinct publisher
build
Coverage Is A Line Counter, So A Coverage Gate Buys You Line-Counting Tests1 distinct publisher
build
AI built the store in weeks. Production itemised what the apprenticeship would have cost1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One practitioner's argument, printed in full, checked by nobody
The strongest thing about this reporting is that it withholds nothing: all twelve questions and all four proposed merge gates are on the page, so you can judge the reasoning directly. What is absent is anything outside the author's head. The prescriptive claims stand up because they are self-describing, while the empirical spine — a 'meaningful share' of diffs arriving without a reason, plausibility rising as correctness held still, hollow error handling appearing 'frequently' — carries no counts, no repository sample and no second observer.
No team, no rollout, no trace
Nobody is shown doing this. There is no engineering organisation named, no policy that shipped, no pull-request template with the attribution checkbox on it, and no account of what happened after a team tried the fifteen-second question. Advice this cheap to adopt may well be spreading, but our coverage gives no way to tell, so we are not putting a number on it.
Modest asks resting on unweighed premises
The overreach is not in what dev.to wants you to do — point at a line, break a test on purpose, name one accountable human — those are small, testable and honestly priced at about a minute each. It creeps in at the edges, in the quantifiers: 'a meaningful share', 'frequently', 'far more often than people expect', and a highest-yield ranking awarded without anything being measured. The recommendations are cheaper than the diagnosis is proven.
Nothing on sale, attention on offer
Read it looking for the pitch and you will not find one: no product, no vendor, no model, no consultancy, not even a link to a linter that would enforce the twelve questions. What remains is the ordinary economics of a developer platform — a corporate-sounding handle publishing free, quotable craft advice earns reputation and reach. That shapes the confident register more than it shapes the substance.
Clear text, no second opinion
We can be quite sure what was said and what was recommended, because the full text is in front of us and its internal logic holds together. We can be much less sure it describes your codebase. One publisher, one author, zero corroboration, and the question of how often plausible-but-wrong diffs actually reach merge stays open — which caps how far this should travel as fact rather than as counsel.