Replace the Trivial, Augment the Difficult
updated
“In the anticipated symbiotic partnership, men will set the goals, formulate the hypotheses, determine the criteria, and perform the evaluations. Computing machines will do the routinizable work that must be done to prepare the way for insights and decisions.” — J.C.R. Licklider, Man-Computer Symbiosis (1960)
A rule in the code-review engine I built caught an idiom I’ve been writing for years and can no longer see. That’s the small half. The other half is that it told me why — that the line leans on a coercion quirk and taxes the next reader with knowledge they shouldn’t need. I already knew the rule; I wrote it. What I didn’t have was the sentence, at the moment my eye had just slid over the thing, aimed at code I’d written that morning.
If the tool had said “line 40, don’t do that,” I’d have fixed line 40. I’d also have written it again the following week, because nothing about me would have changed. It said why, so now I catch it myself. The catch was worth one line. The explanation was worth every line I write after it.
That gap is the whole design question. The default shape for an AI tool is a verdict: the summary you read instead of the paper, the review comment instead of the review, the answer instead of the work. Verdicts are what demos are made of. But a verdict aimed at the hard part of a job doesn’t remove the hard part — it hides it, and hands you a fluent thing you now have to check anyway.
So: replace the trivial, augment the difficult. The slogan is the easy part. Which mode you’re in is determined before you build, by a property of the check itself, and you can read it off in one question.
BLUF
- The mode is set by the referent, not by the difficulty. Ask what the check compares against. If that thing is written down somewhere a machine can read, you’re in replace-mode and the instrument should just decide. If it lives in someone’s head or in the part nobody wrote down, no instrument can decide it, and building one that pretends to is the failure.
- “Trivial” means determined, not easy. A whole-repo type-and-import sweep is hard engineering and still trivial in this sense: the answer is fixed before anyone looks. Meanwhile “does this solve the right problem” is cheap to ask and impossible to settle mechanically.
- In augment-mode, an instrument is judged on what it hands back, not on what it concludes. Filling one of those holes can’t transfer the judgment. It can only relocate it and equip it. So the spec is context: where to look, what’s already checked, what changed under you, what the plan used to say.
- The teaching channel is the part that compounds. Replace-mode pays once per run. Augment-mode pays into the human, who keeps it. Every tool ships the finding; almost none ships the why, and the why is the only part that makes the next review cheaper.
- Both errors cost, and they don’t cost symmetrically. Augmenting the trivial wastes attention on something already settled. Replacing the difficult launders the judgment — and you can’t tell from the output that it happened.
The test is the referent
Every check compares the work against something. Name that something and the build follows. There are three kinds. I’ve used that split before to decide where a check runs — How a Team’s AI Coding Flow Should Be Wired places each check at the point its referent exists. Here the same three kinds decide something else: what you build.
The referent is fixed and outside the work. A type signature, a lint rule, a banned import, a naming convention, a written architecture constraint. It existed before the diff and it doesn’t move. Mechanise it and let it decide. Don’t route it through a person, don’t ask a model to have an opinion about it, don’t soften the verdict to seem reasonable. A person adding judgment here is adding latency and nothing else.
The referent is live and moves while you work. The plan. The RFC. What everyone else has in flight. A machine can absolutely compare the change against the current state — that’s a query, and it’s tractable. What it can’t do is decide whether a divergence was justified. Plans get amended for good reasons and abandoned for bad ones, and the difference is not in the artifact. So the instrument here is mechanical at the noticing and mute at the verdict: it says “this moved, here’s what it used to say, here’s who else is in this file,” and stops.
The referent lives only in someone’s head. Is this the right thing to build. Does this shape match what we meant. Is this simpler than it needs to be. Nothing to compare against, because the comparison target was never written down. This is where the pull toward a verdict is strongest and most wrong: the model will produce a confident answer, the answer will be unfalsifiable, and you’ll have swapped a hard judgment for a plausible sentence.
The last case has a floor under it that isn’t about model quality. Every check reaches what you specified and no further, which means the part you never wrote down is invisible to all of them at once, by construction — A Pool of Models Narrows the Overlap settles that. Pool a dozen models and the blind spot is identical in every one. No amount of capability closes a gap that is definitional.
One caveat on running the test: it classifies comparisons, not tools and not review questions. “Does this implementation match the RFC?” straddles two classes at once — the RFC is written down, and the reason it got amended last week is in someone’s head. Split a question like that until each piece compares against one thing, then read the mode off each piece. A tool can run in three modes at once. A comparison can’t.
Two ways to get it wrong
Augmenting the trivial looks like diligence. It’s a scaffold on material the reader is already fluent in, a confirmation step on a determined answer, a human in a loop that had nothing for them to decide. It’s expensive in the scarcest thing you have. I have a clean receipt for the extreme version, metered in Noticing Is Cheap, Judgment Is Scarce: before I mechanised the noticing, a code-review engine of mine spent about 788,000 tokens across seven agents to say nothing about a fourteen-line rename. The rename was determined — a scanner could have cleared it in milliseconds. I was paying judgment rates to notice, and the fix was this same rule pointed the other way: take the determined part off the model completely.
The subtler form of this error is the one that gets praised. Faced with a bottom tier of trivial findings, the fashionable advice in 2026 is to suppress them — mute the nits, spare the human the triage. That reads as respect for attention and it’s the wrong lever, for the reason The Nit Was Never Optional works through in full. If applying and checking a fix is nearly free, you don’t hide the finding to protect the human, you act on it. Withholding a trivial finding to look restrained is still treating a trivial thing as if it needed a human. It’s the same misclassification wearing a nicer coat.
Replacing the difficult looks like progress. The output is confident, well-organised, and about the right length. And now the compression is load-bearing on exactly the thing you sat down to check. This is the error with no visible failure mode: a wrong verdict on a judgment call and a right one look the same from outside, and the only way to tell is to do the work the verdict was meant to save you.
Notice that both errors come from the same place — deciding the mode by how hard the work feels instead of by what it compares against. Hard-feeling work attracts verdict-shaped tools. Easy-feeling work attracts human sign-off. Both instincts are backwards.
In augment-mode, the output is context
Once you accept that an instrument at a judgment station can’t decide, the spec changes shape. You stop asking “how accurate is it” and start asking “how much of the human’s work did it do, and how much better equipped are they for the part that’s left.”
Those are two requirements, not one, and the second is the one that gets dropped:
- Take as much of the work as the referent allows. Everything mechanical, up to the line where judgment starts. Don’t stop early out of modesty and don’t stop early because a verdict would have been easier to ship.
- Hand back what the judgment needs. Where to look and why. What’s already cleared, so attention doesn’t go there twice. What moved since the plan was written. Who else is in this code. The claim the change is making about itself, with citations back to source so every part of it is checkable.
The second bullet is why “a claim with citations” beats “a summary” every time, and it isn’t a stylistic preference. A summary you can’t drill into is a verdict with extra words. If the reader can’t click through to the paragraph, the diff, the ticket, they won’t trust it — and they’re right not to.
I keep running into the same instrument, built separately by people who aren’t coordinating with each other. One is a personal skill that explains an unfamiliar diff before its author starts reviewing. One is a side project that assembles the context a change needs. One is review tooling whose whole job is handing the reviewer an overview of what actually moved. None of the three returns a verdict. All three are doing the second bullet. I can’t name them and I’m not offering them as measurement — but three parallel builds of a thing nobody sells is people routing around a gap.
It surfaces in print, too, and without a name. A verification loop published for agent-written code asks four questions of a change: did it behave as intended, did it introduce a known defect, does it conform to the project’s standards — and then whether there’s sufficient context for a developer to review the result efficiently. The first three compare the change against something written down. The fourth isn’t a property of the change at all; it’s a property of the handoff, and it’s sitting unmarked in a list of pass-or-fail checks. The author doesn’t remark on the difference. That’s this distinction being felt before it has a name to be felt under.
Teaching is the part that compounds
A verdict pays once. It resolves this diff, this PR, this question, and its value expires when the work merges. Run it a thousand times and you’ve bought a thousand resolutions and nothing else.
An explanation pays into the human, and the human doesn’t reset. The rule that told me why my dead idiom was dead — the one in Fluent in a Dead Idiom — did the one thing my reflex structurally cannot: it taught me the deprecation. My reflex is what makes me fast, and my reflex was dated the day I finished training it. I can’t see my own blind spots — that’s what makes them blind spots — so I can’t generate that explanation for myself. The rule’s why is the channel through which something outside my fluency gets in.
The return compounds, which is the reason to make the teaching part explicit rather than incidental. A reviewer whose job is to educate and lift the code will surface a finding it could have quietly fixed, because the finding is worth more said out loud than silently applied. A reviewer optimising its own precision score will not. Here is my bet, and it is the one thing in this post I haven’t measured: those two tools score about the same on any benchmark you’d run, and they produce different engineers a year later.
The asymmetry is easy to miss because only one side of it has a name. Teaching a machine from human judgment is a well-worked problem: encode the rule, capture the correction, grow the catalog. The other direction — machine to human, deliberately, as the designed output — gets built by individuals and almost never shipped as the point of a product. It doesn’t demo. You can put a verdict on a slide. “The reviewers who used this got better at reviewing” takes a year to observe and doesn’t fit in a screenshot.
Which is also the strongest thing you can say to a skeptic who thinks this is soft. Replace-mode’s ceiling is the tool’s accuracy. Augment-mode’s ceiling is the tool’s accuracy plus whatever the human learned, and the second term only grows.
What this changes about filling a hole
Map an existing flow and you’ll find gaps where a check should happen and nothing does. The tempting read is that each gap is a missing tool of the same kind. It isn’t. Sort them by referent first and they split into three piles with three different builds — decide it, notice it and stay quiet about the verdict, or equip the person who has to decide.
Two consequences fall out, and they’re the ones I’d carry into any flow audit.
The holes are what humans are covering right now, badly. Not all of them — some gaps are genuinely uncovered, and a check that nobody performs at all is a different and more urgent problem than one a person is doing from memory at the wrong moment. But where a human is covering it, they’re covering it under the worst conditions: last, tired, from memory, against a plan that moved. The instrument’s job is to change the conditions.
Filling the hole doesn’t move the responsibility. Where the referent is mechanisable, an instrument really does take the responsibility — that is the point of mechanising it, and a fluent engineer who keeps checking anyway is spending their own time by choice. Where the referent isn’t mechanisable, the responsibility cannot move, because there’s nothing to move it to. So the honest measure of that instrument is never “does it decide correctly.” It’s “when the person decides, how much better is their position than it was before this existed.”
That reframes the artifact work, too. Most of what makes a judgment station workable turns out to be upstream of any model: a plan that carries its revisions instead of only its latest state, a change description that makes a checkable claim, an RFC that records the approach and not just the need, a queryable picture of what the team is currently doing. None of those decide anything. All of them are the second bullet — hand back what the judgment needs. They’re not model problems. They’re artifact problems, and they’re the cheapest available lever.
Why this isn’t the reading post again
I’ve argued amplify-over-replace before, for reading: Augmented Reading says use the model to read more, and never read the summary instead of the source. That post is about one human in front of one artifact, and its lever is scheduling attention.
The build-side question isn’t the same claim. Reading gave me a preference between two modes. This post gives a test for which mode a given hole is in, a three-way answer instead of a binary, and a spec for the output when the answer is augment. The reading post also carries the one caveat that binds hardest here: a scaffold’s value scales inversely with fluency, so guidance that lifts a novice becomes redundant load for an expert. That’s the expertise reversal effect, and it’s the reason “augment” is not a licence to add apparatus everywhere. Augment the difficult — and difficult is a property of the check, not a flattering description of everything you’ve built.
The point
Sixty-six years ago Licklider wrote down the division of labour: people set the goals, form the hypotheses, and perform the evaluations; machines do the routinizable work that clears the way. Engelbart spent a decade on the second half of it, and defined augmentation as increasing someone’s capability to approach a complex problem and derive their own solution. Neither of them proposed a machine that hands you the answer.
The industry defaulted the other way anyway, because a verdict is legible and a better-equipped human is not. The correction is cheap and it starts with one question: what does this check compare against? Answer that honestly and most of the build is already decided for you. What’s left over is the part nobody can take off you — and the only thing worth asking of a tool there is that it hand you the judgment in better shape than you’d have found it, and a little better again the time after that.
How sure I am:
- Cited: the expertise reversal effect (Kalyuga, Ayres, Chandler & Sweller, 2003) — guidance that helps novices becomes redundant load for experts. The Licklider and Engelbart framings are quoted from the primary sources.
- From experience: the rule that taught me a deprecation my own eye slides over; the fourteen-line rename that cost about 788,000 tokens across seven agents; the call to surface trivial findings instead of suppressing them. All from a code-review engine I built and run.
- Prior art, corroborating not measuring: three independent builds of diff-explanation and change-context tooling that runs ahead of review, none of which returns a verdict. That’s convergent evidence the gap is real. It is not a measurement of what filling it is worth.
- One sighting you can go and check: the four-question verification loop is Luttrell-Williams’, published and dated, and the fourth question really is a different kind of question from the other three. That part is verifiable. What I’ve added is the claim that the difference is a category difference, and that’s mine, not the author’s — they don’t draw it. Weight it accordingly: it’s a vendor byline with no measurements in the body, so it evidences that the distinction gets felt in the wild, and nothing about what acting on it buys you.
- The wager: that the teaching channel compounds — that a tool which explains produces a measurably better reviewer over months, and that this dominates a tool which merely decides. I believe it and I haven’t measured it, and I’m not sure how to over a horizon that short. If this post is wrong somewhere, it’s there. The rest of the argument stands without it: the referent test holds even if teaching turns out to be worth less than I think.
Sources
- J.C.R. Licklider, Man-Computer Symbiosis (1960, IRE Transactions on Human Factors in Electronics) — the original division of labour between goal-setting and routinizable work.
- Douglas Engelbart, Augmenting Human Intellect: A Conceptual Framework (1962, SRI) — augmentation as increasing a person’s capability to derive their own solution; the tool system and the human system co-evolve.
- Kalyuga, Ayres, Chandler & Sweller, The Expertise Reversal Effect (2003, Educational Psychologist) — the bound on when a scaffold helps.
- Taylor Luttrell-Williams, CLI or IDE? Build in Verification First (The New Stack, 25 August 2026) — the four-question verification loop whose fourth question is about the handoff rather than the change. A vendor byline; cited as a sighting of the distinction, not as evidence for it.
Related: Augmented Reading (the same split for one reader and one artifact), How a Team’s AI Coding Flow Should Be Wired (the flow whose holes this sorts), Noticing Is Cheap, Judgment Is Scarce (why the mechanical half is the cheap half), Fluent in a Dead Idiom (the rule that teaches what the reflex can’t see), The Nit Was Never Optional (surface the trivial finding, don’t suppress it), A Pool of Models Narrows the Overlap (the unwritten part is invisible to every model at once).