Uncle Bob Stopped Reading the Code

Uncle Bob Stopped Reading the Code

Let's Call It Peek-a-Boo Engineering

Robert C. Martin, the man who wrote Clean Code and spent two decades telling the profession to read every line it ships, posted this on August 19: "It is amazing how much work it is to wrestle these agents to my will. Don't get me wrong, it's crazy productive. But it's also a lot of hard, focussed work. All my software engineering and problem solving skills are brought into play -- even though I barely look at the code." Twenty-five hundred people liked it. A few days later he spelled out the loop he runs now, run the app, have an agent diagnose and file issues, have an agent fix them, have an agent audit the fixes, have an agent repair what the audit found, go back to the top, and when someone asked why he wasn't reviewing the output, he answered plainly: "I don't want to read the code because that slows the whole process down. The last thing a squad of agents needs is me looking over every line of code."

Two days before that first post, The Register published an account of what happens at an outfit with a considerably larger blast radius than a retired consultant's side project when the code review stops and nothing takes its place. On the June 18, a commit co-authored by GitHub Copilot Autofix landed in Snowflake's public snowflake-connector-net repository. It removed the sanitized-input pattern a GitHub Actions workflow had been using and replaced it with direct string expansion inside a run block, which is the textbook shape of script injection in CI. Five days later, on the twenty-third, Wiz's autonomous red-team agent found the workflow during a routine sweep of public repositories, opened an issue with a title crafted to break out of the echo, and walked off with a Jira token that gave it read access to Snowflake's engineering, security compliance, and bug bounty projects. Snowflake patched it the same day, rotated the token, and confirmed from audit logs that Wiz was the only outsider through the door. Nobody got hurt. An AI wrote the bug, an AI found it, and the humans in between had signed off on the change.

Last week we closed with a run on the controls that keep an agent honest, and promised that this one would change altitude and talk about where it's genuinely safe to let go of the wheel. Uncle Bob and Snowflake, in the same week, are the two ends of that question. One is a veteran deliberately not reading the code because he built something else to catch what reading would catch. The other is a change that got the ordinary kind of review, a human looking at a diff a bot labeled as a fix, and shipped a hole. The difference between them is a piece of industrial-safety vocabulary worth borrowing: an interlock. On a press brake or a lathe, an interlock is the mechanism that makes the machine physically unable to run while the guard is open. It doesn't advise, and it can't be persuaded. Letting go of the wheel is legitimate only when the thing you hand it to is a check that can fail the run, and a person nodding at a diff isn't that at all.

What He Looks At Instead

The inventory of what took reading's place is the interesting part of Uncle Bob's week, because he's been unusually specific about it, and every item on that list sorts into one of two bins. In a thread with Kent C. Dodds he argued that AI has made high, meaningful coverage "within easy reach of even the most casual projects," and that the CRAP metric and mutation testing "usually improve the tests considerably." Those are interlocks. A mutation score is a number produced by a program that changes your code and checks whether your tests notice; it can't be flattered, it can't be talked down, and it can be wired to fail a build. A complexity ceiling is the same kind of thing. When he says he barely looks at the code, this is the machinery that lets him mean it.

The other bin is the audit. He has an agent audit each finished task, and he's noticed, with evident amusement, that the auditor "often finds things to fix," and that the same model "almost always passes the second audit." He also posted the instruction that shows which bin the audit belongs in: when you ask the agent to audit itself, "make sure you read it's responses very carefully. Especially the part where it talks about gaps and things that were NOT done. You'll often be surprised." Read that as a control and it's issue #25. The audit is a brief. It's a well-informed opinion from a party that can't be held to it, and Uncle Bob is still the one reading the brief and deciding. He let go of the wheel on the code and kept both hands on it for the audit, and that's the correct allocation, because the audit is the one thing on his list that can't fail the run on its own.

The ratio is the part of his list he doesn't advertise, and it's the part worth stealing. In the reply that put his gain at 5x, the number comes after "all the tools, checks, and ceremony I impose upon them to keep them honest and their output high quality." He watches agents do small tasks ten to twenty times faster than he could, and the ceremony eats most of that back before it becomes the five. That's the price of letting go. You don't get to skip the reading for free; you pay for it up front, in interlocks, and the productivity that's left over is the real number.

Snowflake Is What "Reviewed" Looks Like Without An Interlock

Now put the Snowflake commit through the same two bins. Whatever review it got (and a public repository at a company that size has branch protection) had a diff in front of it with Copilot Autofix in the co-author line, arriving under a label that says, in effect, "this is the fix." Issue #25 was about this failure, the moment the bot's summary becomes the thing the human rubber-stamps, and here it is in the wild with a red-team agent on the other end. The reviewer was the only check that could've caught the change, and the reviewer was the one check in the chain that a confident label could soften.

What the check would've needed to see is small. Inside a GitHub Actions run block, an expression such as github.event.issue.title, wrapped in the runner's double-brace syntax, is expanded by the runner into the shell script before the shell ever sees it. Whatever an anonymous user types into an issue title becomes program text with the workflow's permissions and its secrets. That's why the repository had a sanitized-input pattern in the first place, and it's why the commit that removed it wasn't a refactor. A diff that deletes a sanitizer and adds a raw event expansion inside run: has a signature, and a signature is a thing a program can check. The Register later clarified that Wiz couldn't determine whether Autofix introduced the flaw or only failed to correct it during its own review, and it doesn't matter. Either way, a bot touched the trust boundary of a CI workflow and a human ratified it, and nothing between them was built to refuse.

The timeline matters more than the mechanism: five days from commit to exploit, by an agent doing routine sweeps of public repositories, not by a person who was targeting Snowflake. Any workflow with that shape, in any public repo, is now findable at machine speed. The bar for what counts as "reviewed" has to move accordingly. A person looking at a bot's diff was an adequate control when the adversary was also a person with a finite afternoon. It isn't one anymore.

An Interlock Can Fail The Run. A Reviewer Can Only Decline To.

The working definition applies to anything on your own list. An interlock has three properties. It's deterministic: the same change produces the same answer every time, which is what issue #26 was about and why a model at temperature zero doesn't qualify. It can block: a failed interlock stops the run, the merge, or the send, rather than filing a comment. And it can't be argued with: there's no prompt, label, or co-author line that changes its answer, which is the property the Snowflake reviewer lacked and the property issue #28's fuse had by construction. Tests, mutation scores, complexity budgets, lint, SAST rules, and the fusebox ceiling are interlocks. An LLM reviewer, an agent auditing its own work, and a tired human approving a diff at four in the afternoon are advisors. Advisors are valuable; they're not the thing you hand the wheel to.

The same distinction explains the other observation Uncle Bob made this week, about scale. "One agent makes us go faster. Two makes us go even faster. But does that scale linearly?" His answer from experience: six agents arranged in an assembly line worked well, and six running in parallel produced "very bad results," with agents that "create inappropriate interfaces, double up on functionality," and end in "the horrible cascade of merges." CooperBench put a number on the same thing in January: across six hundred paired coding tasks, two agents cooperating succeeded about 30% less often than each agent handling both tasks alone, which the authors named the curse of coordination. An assembly line works because every station is an interlock for the one before it; nothing reaches station three that station two's checks didn't pass. Parallel agents with no interlocks between them are six advisors with commit access, and that's the configuration a mutation score, a contract test, or a merge gate exists to prevent.

Where It's Safe To Let Go

Last week's issue promised an answer, and here it is: it's safe to let go of the wheel inside the interlocks and nowhere else, and "inside" has a testable meaning: the work is either reversible or it lands behind a check that can fail it. Read-only work qualifies almost by definition, the log triage of issue #24, summarization, diagnosis, an agent filing issues into issues.md the way Uncle Bob's first station does. Draft output qualifies, pull requests and staged changes and generated tests, as long as the thing that promotes them is an interlock and not a nod. Bounded batch work qualifies once it's under a fuse. That's a large envelope, larger than the human-in-the-loop-forever crowd will admit, and the reader who just absorbed four issues of controls has earned the other half of the argument: with a mutation score, a golden set, a pinned snapshot, and a fuse in place, you've earned the right to stop reading, and continuing to read every line is spending your engineers on a check the machine already runs better.

The other edge of the envelope is just as sharp. Anything that ratifies stays human; the audit in Uncle Bob's loop is still read by Uncle Bob. Anything with an irreversible side effect stays human or stays behind a deterministic gate: sends, payments, deletes, production deploys. And after this June, one more category belongs on that list explicitly: any change to CI configuration, workflow files, or the sanitizers inside them, whatever the author, whatever the label. Those files are the trust boundary. A bot editing the trust boundary is the one diff a human must read in full, and the interlock's job is to make sure it never arrives without that reading having happened.

Quick Wins

🟢 Easy (~15 min): Sort every check on one pipeline into the two bins: can it fail the run, or does it only comment? Any bot review, AI summary, or self-audit that sits in the "required" column of your branch protection moves out of it today. Advisors advise; they don't ratify.

🟡 Medium (~1 hour): Add a CODEOWNERS rule that routes every change under .github/workflows/ to a named human, and turn on the branch-protection setting that requires the most recent push to be approved by someone other than the pusher. A bot editing the trust boundary now can't arrive without a full human read.

🔴 Advanced (half day): Wire interlock into the merge queue for one repository, with INTERLOCK_CHECKS set to your real test and lint job names, and add a mutation-testing job to that list. Then pick one agent workflow whose output lands behind those gates and stop reading its diffs for a week. Measure what the interlocks catch. That's the reading you were doing, done by something that can't be flattered.

Next Week

There's a queued topic that this June made harder to keep putting off: the connectors we're handing agents, and why the protocol everyone adopted in a year looks a lot like the one the web spent a decade learning to distrust. More next Tuesday.

Uncle Bob stopped reading the code, and the software profession's most reliable scold about reading the code was right to. He didn't stop checking it; he moved the checking into machinery that can refuse, and he kept his own hands on the one control in his loop that only advises. Snowflake had a human read a bot's diff, which is the arrangement most teams still call review, and a second bot found the hole in five days.

Whether to let go of the wheel was never the question; what you hand it to is. Inside the interlocks, for work that can be reversed or refused, let go, and stop paying engineers to re-run a check a program runs better. At the trust boundary, and anywhere a change can't be taken back, the wheel stays in a hand you can hold to it.

A reviewer can decline to approve. An interlock can refuse to run. Build the second kind and you've bought the first kind's afternoon back.

P.S. Standing up agents with the interlocks wired in before anyone stops reading the diffs is the kind of work NodeBridge does for a living, and the read-only, deterministic spine of the TestScout MCP suite is the same instinct pointed at your test suite. If this issue found you with a bot in the required-reviewers column, forward it to whoever owns branch protection. If someone forwarded it to you, subscribe at bashmatica.com.