This week the argument found a name. Uncle Bob Martin, who started coding in the late 60s and wrote the book on clean code, posted that his current strategy is to not read any of the code his agents write; he surrounds them with extreme constraints instead. Someone asked Hacker News whether looking at the code is slowing us down, and X split into two camps: the craftsmen insisting you must read every line, and the shippers declaring reading code an anti-pattern. “No look” coding. I’ve spent two days in my replies arguing with both camps.
When someone suggested Bob had lost it, my reply was short: maybe, but he’s not alone, and I think he’s 💯 right.
I started in 1981. I’ve led teams that built parts of COM/ActiveX, IIS, and Windows Media Center, all of Windows Home Server, the Windows Phone 7 developer platform, Alexa Smart Home, and Control4’s OS and smart devices; software and hardware used by tens of millions of people, multiple times over.
Six months ago I was with the skeptics. I started going no-look in about April, and I am now 100 percent convinced. In the 120 days since, I’ve built or upgraded five significant products, WinPrint, MCEC, and tui-cs/Editor among them, and I’ve not seen a line of code. On Terminal.Gui, a team project, the vast majority of PRs in the last four months have been no-look too. Get over it and get with it.
And yet the debate, as framed, is still wrong.
The “no look” conversation is the wrong conversation. The right conversation is about customer obsession, product judgment, taste, and leadership.
Reading code was always a proxy. We read every line for fifty years because the code was the only artifact that told the truth. The spec lied, the comments lied, the commit message lied, and the demo lied twice, but the code did what the code said. So the profession built its entire trust apparatus, code review, out of eyeballs on the one honest artifact.
That constraint is gone, and we have been here before. Do you review the instruction set or cache architecture diagrams for each new CPU you use? Do you and your teammates have a deep understanding of the compiler’s output? Sure, some engineers do (and need to), but it’s a really small world. When we moved from assembly to trusting compilers, we moved up an abstraction and new skills were required. This is that, again. Bigger, and more impactful, but not different.
“But technical debt that still passes every test!” No. I have repeatedly demonstrated, to myself anyway, and I am pretty experienced, that the AIs are excellent at identifying poor abstractions, unnecessary complexity, drift, and maintainability issues; as long as I am intentional about how I play FarmVille with them. Ask them about code quality, style, maintainability, and separation of concerns. They’re better reviewers than a tired human skimming their fortieth diff.
The key is not the harness; it’s the specification. The workflow that works today:
- Write a spec
- Iterate with AI and other high-judgement humans to improve the spec
- Give spec to AI and tell it to vibe code it, building tests and CI/CD.
- Have other AI do code reviews and fix in a test-first manner.
- Have high-judgement and not-so-high-judgement humans test the functionality
- Repeat 2-6 several times until it basically works (what we used to call alpha quality).
- Throw everything but spec and tests away. Seriously: Delete everything.
- Give spec to AI and tell it to engineer it as though it were a Principal Engineer that raises the bar for all of the Amazon PE Commnity Tenets, with specific instructions for improving the quality infra as well.
- Have another AI code review each component. Have AI fix all issues found in a test-first (build a test that fails before fixing) and “improve the spec” manner.
- More human tests of functionality. If testing finds problems, have AI improve the spec further.
If, after all that, it smells funny, throw the code away again start at step 7 again.
So here is what I, the human, actually look at, in order of how hard I look.
- The spec. The spec is canon now; the code is an intermediate representation. If the intent document is wrong, no amount of code reading saves you. This is where I spend real judgment, and it’s why I keep telling people who feel behind to start by learning to express intent, not syntax.
- The gates. Named, automated proof that cannot flatter me: tests the agents wrote under my direction, linters (yes, I enforce code/syntax style still!), compile gates, simulator scenarios, and CI that fails closed. A green gate means something because I looked hard at what the gate measures, once, instead of looking softly at every diff, forever. I read test plans with far more suspicion than I ever read implementations.
- The behavior. The running thing, in my hands, doing what the spec promised. For software that’s user testing. For hardware it’s confirming with your own eyes and ears that the device does what it should, because a version string over a serial port is not a product that works. That said, the AIs are getting excellent at actually seeing moving UI and noticing there’s something wrong with it.
- The code, almost never, on exception. When a gate fails strangely, when the agents argue with each other, when something smells expensive or insecure. The IDE didn’t die; as I said in Prompt to Metal, it became a visualization and verification surface. I open it to look, not to draw.
Notice what this list is. It’s the work backwards ordering: customer intent first, proof second, product third, mechanism last. Guarding the mechanism used to be the job because we had nothing better. Now we do, but only if you build it. The robots need docs, contracts, and gates written for them, and building those is the new craft.
One more thing, because I don’t believe this argument is actually about engineering.
Humans are led by fear. Fact. We are all biased toward loss aversion, especially when it comes to identity. Software devs have invested in skills, knowledge, and approaches that are part of their identity, and those things are not as relevant in the AI world.
That leads to loss, and humans deal with loss as grief: denial, anger, bargaining, depression, acceptance. Read this week’s threads again with that lens; “you must read every line” is rarely a risk analysis. I have gone through every one of those stages myself in the past three years, and I am now past acceptance and into full-on embracing. The way through is the same as for any bias: first recognize you may have one clouding your judgment, then get curious about whether you can overcome it, then do.
On the other side of grief there is, of all things, joy. I have some sadness that I’ll no longer care about the cool features I mastered in those ancient languages. But this new world has brought me back to the joy I felt in 1981 when I taught myself BASIC. For me the joy never came from typing; it came from two things:
- Finding things that are opaque to me and mastering the skills and knowledge that make them transparent.
- Solving customer pain with delightful experiences.
Playing FarmVille with AI agents is a target-rich environment for both of those things. Woo-hoo!
Meanwhile, this whole pissing contest is a software-dev luxury. Just wait until the EEs realize their current skill set is next, and start arguing “how can you build reliable hardware if you’ve never actually seen the netlist or the EDA diagrams?” I have thoughts on that too.
So argue with me. Tell me which stage of grief are you in? Leave a comment or find me on X at @tigkindel. I read everything. Even, on exception, the code.