--- title: "On reading code" date: "2026-08" category: "Working with AI" tags: ["Working with AI"] description: "Let me say something about my own view on whether you actually have to read the code. For me, I take the position of don't read code line by line, which I already talked about in Process-based quality control..." source: "https://enriquemark.com/en/posts/%E5%85%B3%E4%BA%8E%E4%BB%A3%E7%A0%81%E9%98%85%E8%AF%BB" --- Let me say something about my own view on whether you actually have to read the code. For me, I take the position of "don't read code line by line", which I already talked about in [Process-based quality control](/en/posts/基于过程的质量控制). Though there's probably a layering to do inside that. Like I said before, you need to layer your own code. Say something especially important, something that could put a human life at risk. That kind of code is still better read line by line, right? The second layer would be things that might involve large-scale financial processing, or a really important core, and those you probably still want to look at. But past that, you could say over 90% of the code we build day to day touches neither of those. In that case, and especially now, I think reading code line by line no longer means much. Because it becomes a serious efficiency bottleneck. Like I keep saying, I can produce ten thousand lines of code in a single day now, and if I had to read all of it, I'd be the bottleneck myself, wouldn't I? And without the context, the one who suffers more from reading the code is me. Some test reports say a human reads a few hundred lines an hour at most, so to get through ten thousand lines you'd spend the entire day just reading code, and you still couldn't hold up. So I think not reading the code is completely acceptable. It's just that "not reading the code" doesn't mean I've given up quality control over the code. Code written by AI especially will often drift further the more it writes, sometimes into outright problems. So I do still read it, just not line by line. What does "still read it" mean? My reading is having AI summarize for me, then looking at the rough architecture, looking at the summary, reading at the abstract level. These days I might really barely look at the code itself anymore; the code itself is more of an intermediate product to me. I put more of my attention on building the whole quality control system, the way a Harness constrains AI. For example, building really thorough test coverage. And coverage like that can't be built by a single Agent, because they hit a classic old problem, which is sneaking through the back door. What do I mean by that? Making up "fake greens". Even when your code really has gone wrong, it can still end up showing you that the tests passed. What's the point of a test like that? That's shooting the arrow first and painting the target after. So what does a test like this depend on? One is building it through adversarial review, for instance putting out an Agent with no context at all to review it; or having it do mutation testing, meaning deliberately breaking the original and seeing whether the test results still come back green. If it's broken and still green, that's a fake green. To make this work, it's best to script and automate the process of writing the mutation test rather than letting AI write it, so it doesn't go wrong without ever having been run. The second point is adding all kinds of testing approaches, like regression tests, integration tests, E2E tests and so on. One key thing among them is "aligning with the requirements". What does aligning with the requirements mean? Sometimes even when the tests pass, what they passed on isn't what I wanted. It's reasonable as program logic, and there really is no bug, but what it tested is a wrong behavior. My spec wants behavior A, and it wrote a behavior B completely unlike A, then made the tests pass. That's what I call not aligned with my requirements and spec. As some people say, line-by-line reading isn't realistic, and "pretending to read line by line" is worse. Every four or five hundred lines you read, the quality of your reading keeps dropping. If you really review code for a whole day straight, by the end you won't know what you're looking at. A human at that point isn't necessarily more accurate than a machine. A mass of code drowns you, and in the end you just don't want to look at it, and efficiency gets very low. Rather than doing that sort of pointless Review, build a complete, comprehensive, engineered test environment. You can look at StrongDM and their development style, which is a bit like a "lights-out factory" or a "software factory". Their stance is very hard-line: code absolutely must not be written by humans, and must not be reviewed by humans either. So how do they guarantee code quality? By what I've been saying, building an engineering environment solid enough to hold. This is a bit like, well, one is guaranteeing from the inside, the other is constraining from the outside. Either you guarantee from the inside that your code itself is of high enough quality, written without a single bug; or, even if there are bugs, I don't care, I'm fine treating you as a black box, but I need all sorts of external packages and all sorts of tests to keep your whole behavior pressed into the range I want. That's what external constraint means. I think this kind of external constraint means boundaries and shaping. One is taking an external framework as a mold and fitting it in, the other is shaping that mold from the start. It's not that either one has to be right or wrong, both sides have their own reasons. But looking at it from efficiency, insisting on manual Review will sooner or later fall behind the times, the way I see it, because its efficiency bottleneck really is too severe. StrongDM has one test I find interesting and quite like, which is that they build a completely digital clone environment (DTU, Digital Twin Universe). They do a behavioral clone of the third-party services the software depends on, to detect what goes wrong when the software connects to the outside. Basically simulating a real running environment and testing against it over and over. And their test intensity is high, things like high-volume stress tests, deliberate attacks, manufacturing dangerous failures. The point is that their test conditions are all verifiable, and the test frequency is high. They also have a mechanism called Gene Transfusion. Though looking into theirs, it seems more like extracting some standard paradigms and migrating similar working patterns between different pieces of code. It isn't only guaranteed by Skills, it's more like there's some special dependency, or a fixed structure and mechanism. This is similar to how I use it. I read it as having built a reusable, modern development methodology whose behavior is reusable and portable in every place, not just bound to one library. On file management they have complete conventions too. The system records all kinds of intermediate memory files in full, and manages the core files in particular. Directory names carry meaning, various indexes get built, and then the intermediate state gets written back to disk in full. The point is to keep the Agents inside the repo carrying memory at all times, instead of starting over every time. This step is so the Agent can persist the whole environment, so the next time it develops it can pick things straight back up. Everyone will end up converging on this direction eventually. On top of that they have two execution modes: one is interactive, with a Human-in-the-loop; and one is fully non-interactive, where you give it the spec and it runs from start to finish. The non-interactive one is interesting. After it finishes writing, it also builds a node graph loop that works like an attractor. Say implement the feature first, then find the bottleneck, then go optimize performance. Through that process, a whole set of verifiable behaviors and results makes sure it gets clear feedback within the loop. At the same time they use a separate LLM to evaluate; the process is observable and the result is deterministic. Like the graph programming that's popular now, going through a directed acyclic graph (DAG) from request and plan to call scheme, attempt, success, return. The way I read it: they're trying to build a system that runs itself and corrects itself. Two things are key to a system like that. First, it can run from start to finish. Second, it can hit clear feedback and correct itself. "Verifiability" matters enormously here. If your verifiability doesn't come up, then the Agent runs off the rails the moment it starts, falls into a dead loop, and things go wrong. There's also cross-Agent independent review layered in the middle, using process on top of process to guarantee quality. This also bears out a view I very much agree with: the key point of development now has already moved from "the code itself" to "behavior" and "acceptance criteria". That is, what running state of the code is acceptable? What behavior is the one I expect? What we're really doing is designing one strict gate after another, hoping AI can pass them, and if it doesn't pass it has to fill the gap. In that process the Agent's tendency to wander off gets held back to a degree. The core idea of it is that an Agent needs discipline. We need to guarantee that its work is effective, and that effectiveness is guaranteed through strict process and quality valves (gating). I can skip reviewing every line of code, but I have to have verifiable metrics and gates to make sure the code really does have quality. Of course there are things I can't not read. Like how a specific feature should be designed, or the architecture as a whole. At minimum I have to understand and have a grip on the whole architecture. I can't design a system myself and not know what it looks like. I can skip caring about the details at the code level, but the macro-level details and the architecture I definitely have to know. So I think the trend for development overall should be to keep strengthening this kind of engineering-gate construction. [The right not to read the code | Raphael Moura](https://raphamoura.dev/en/blog/o-direito-de-nao-ler-o-codigo/) [StrongDM Software Factory](https://factory.strongdm.ai/) https://arxiv.org/html/2606.13175v1 --- **Translation note.** I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: [关于代码阅读]().