People seem shocked that the author of Clean Code doesn't read code anymore. But that should not be surprising. Why did I write Clean Code? What is the goal of keeping code clean? To get it out of the way of the real job -- thinking.

OK. It's time to rethink this. I've spend the last several weeks working on a harness that tightly constrains the agents to work the way that I want them to work. I set up all kinds of gates, and tests, and tools, and protocols, and ... And while I was heads-down getting that to work, the agents got a LOT better. So much so that when I came up for air, the need for my harness was obviated. Indeed, the need for _any_ but the most liberal of harnesses may be obviated. Just how good these things have gotten blows me away. I have had long debates with grok and codex about the structure of systems -- as if they were senior engineers. They often disagree with me and have their own perspectives. I have, more than once, found myself agreeing with their views. I have not given up on constraints and tooling. Unit testing is still important. So is CRAP and Mutation testing. These tools still find bugs and offer useful constraints, though they can leave scars. However, the agents have gotten so good that I can now give one a very significant task with a few guidelines and it will faithfully implement it. I can walk away for 40 minutes and when I return it will be done. CRAP will be satisfied, Coverage will be high, and Mutation testing complete. The architecture will be clean, and the code will be very good. The end result may not behave perfectly, but it's so close that a couple of tweaks usually puts it into place. What does this mean going forward? I'm not sure. But I'm beginning to think that harnesses should not treat agents as components within a software design.