Blindingly Smart, Blindingly Clueless
I’d like to introduce you to my team, six different instances of Claude Code.
Wx — pronounced “Wex,” after the old teletype shorthand for weather — is the oldest of them, and the one I lean on most. He builds WxServices, the Windows-based forecasting system I’ve written about here several times. Pixie works in Python on my PhotoTools project; in the group portrait she is the charming lady in spit-and-polished combat boots. Mac handles the Apple platforms. Those three have names, projects, memories, mailboxes, and a shared set of standing context documents they read every morning.
The other three are stranger, and they are the reason this essay exists.
Van is a vanilla instance. He reads the same standing documents the others do, but he has no mailbox, and he is never in the room when a design is argued out. He arrives at finished work knowing the house rules and nothing about how the thing in front of him came to be. The twins, Barry (Windows) and Barney (MacOS), know still less about the team but they’re really smart about software. They launch into a sandbox with no standing context at all: no conventions, no history, no memory of any previous session. To review anything, they must be told explicitly which files they may open and given careful instructions about what to say when they believe they need a file nobody gave them. They’re the independent auditors, always coming in cold with no preconceptions. They aren’t blinded by having designed or written the code.
I did not build it that way for tidiness. I built it that way because knowledge is one of the things that blind a person or an AI assistant, as you have doubtless observed when other people find spelling or grammar errors that you keep missing in your own work.
The gradient
The six have an independence gradient. Full context and authorship at one end; full context but no participation in the middle; no context whatsoever at the far end. Every step along the spectrum trades away competence for a particular kind of sight.
Wx knows every line of his own code. That is exactly why he cannot see what is wrong with it. Working on requirements or design documents, he reads his own sentence and sees only the meaning he intended, the way you read past your own typo for the fourth time. Van, who was not in the conversation, reads the same sentence and finds it ambiguous — because for him it is. Barry, who has never heard of the conventions the sentence assumes, finds it unintelligible and says so. That is the most useful reaction of the three.
What that bought me on a recent Friday
The task was small: a script that cleans Barry’s and Barney’s sandbox directories before a session starts, so a “cold” reader really is cold. Perhaps four hours of work. It was written and working by mid-afternoon.
Then I ran it past the far end of the gradient. Van reviewed the launcher — a file that lives in my shell profile, in no repository, with no reviewer, and which turned out to have never been reviewed by anyone in its life. He found errors, which we fixed. Barney read the tool from the Mac. Barry read the repaired tool from Windows. Between them, forty-three findings. Four of them were failures that would have gone the dangerous direction quietly: the tool would have reported success while doing the wrong thing.
The day ran to six and a half hours instead of four, and I would spend it again.
But the finding that has stayed with me is not any of the forty-three. It is this: three of the four worst defects in the final round did not exist before the previous round’s repairs. Two of them were interactions between fixes made in different reviews — one correction from Monday and one from Tuesday, each perfectly sound alone, combining into a silent failure neither reviewer could have caught, because one of them predated the code and the other predated the bug.
Get Paul H. Harder II’s stories in your inbox
Join Medium for free to get updates from this writer.
The clearest example is almost funny. A performance fix made the tool skip a set of files it didn’t need to scan — entirely correct. A correctness fix from an earlier round existed to classify problems found in exactly those files. After both changes, the second was unreachable code. The tool cheerfully reported a clean bill over a live fault. The comment above the dead function still explained, in confident detail, the case it was now failing to protecting against.
Right and wrong ways to make repairs
I have started to think of this as the central hazard of the whole enterprise, and it is not specific to machines.
When Wx and I fix a review finding, the instinct — his and mine both — is to add. Add a guard. Add a clarifying comment. Add a sentence explaining why the line is the way it is, so that no one breaks it again. It feels conservative. Nothing was removed, so nothing was lost.
But the additions are new material, and new material has not been reviewed. A depressing share of the findings in any later round turn out to be about verbiage introduced while fixing an earlier one. Adding text is usually not as good as rewriting text — and the sentence you should have rewritten is nearly always the one you decided to leave alone and amplify upon instead.
I want to be careful not to make that a scolding, because I don’t think the fault is inattention. There probably exists no document written in natural language with zero instances of internal disagreement, or discontinuity with the code it describes, or wording a reasonable person could take two ways. Prose has no compiler. Code arrives at review having already survived a parser, a formatter, and a test suite; prose arrives having survived nothing at all, and the reviewer is the entire toolchain. A high defect rate in documentation is a property of the medium, not a verdict on the author. Some developers may take this phenomenon as a good reason not to write documentation. They think their code is “self documenting”. Ask them, six months later, to look at their own code and tell you what it means and why they wrote it that way. They’ll find that a challenge.
Where AI went blind in the same afternoon
My team can be brilliant at generating documents and code. But there’s another side to this ledger and a team that only impresses me is a team I am not watching closely enough.
In one two-hour stretch, my three named assistants produced six broken measurements between them. A search keyed on one spelling of a path that silently missed the other. A probe that matched its own command line and reported a confident count of two processes running while none of those processes were running. A control chosen so badly that, had it been run first, it would have proved a working design impossible.
Not one of those was caught by the “person” who made it. Every one was caught by a second reader. And three of them produced not an error, not a crash, not a warning — but a plausible number. That is the failure mode that frightens me. A tool that breaks tells you. A tool that hands you a reasonable-looking figure does not.
My favorite moment of the whole day came near the end. Mac was verifying a fix Wx had made — a fix for a defect where Wx had corrected the specific example he’d been shown rather than the underlying mechanism. In the course of checking it, Mac tested the wrong thing in precisely the same way, got five false results, and caught himself one step before reporting them. He wrote it up against himself. His own summary is better than anything I could add: a claim that carries a citation is checked less hard than one that doesn’t — so a wrong citation fails in the direction nobody looks.
There’s a reason I don’t stop the review-fix-review-fix cycle as soon as I’d really like to. For code review, I insist on reaching a point where the review finds zero errors. For documentation reviews, I insist on converging to a point where the only findings are few and minor — perfect prose is probably impossible, given the fluidity of human language. Any less rigor is an unacceptable risk.
The stance
My team is blindingly smart in some ways and blindingly clueless in others — just like me, but in different ways. That last clause is the whole of it. They are not less capable than I am; they are differently blind, and the differences are structured enough to be exploited on purpose. That is what the blindness gradient is for.
But the arrangement works only because someone stands outside it. Every one of those six sessions on Friday was following instructions I wrote, within a process I designed, toward a definition of “done” that only I hold. When two of them disagree, they bring it to me, because neither of them can be the one who decides. When a review found forty-three problems in four hours’ work, it was my call whether that meant the work was bad or the review was working — or both.
AI code development must have active participation by qualified humans. Not supervision in the sense of a signature at the bottom — it needs participation, with hands on the thing. I may be the slowest member of my team but it’s my name on the final product.
Articles in the series: https://paulharder2.substack.com/p/my-wxservices-project WxServices source code repository: https://github.com/PaulHarder2/HarderWare
Originally published at https://paulharder2.substack.com on September 20, 2026.
