The Death of Code Review: Toward Agent-Legible Systems

FOGMOE-telegram-bot is a summer hobby project of mine, forked from a relatively simple implementation by FOGMOE. After two months of design and refinement—and burning through more Codex quota than I can count—the project now has the basic characteristics of a cloud agent: containerized agent workspaces, the novel fmBPF dynamic plugin system, and reliable operations and deployment tooling.

The project is implemented natively in Python 3.14 and C++23, targets Linux, and uses PostgreSQL for its data services. According to cloc, the Git-tracked files contain roughly 383,600 nonblank lines of effective code and comments: 244,700 lines of production code and 138,900 lines of test code, split about evenly between Python and C++. This code also comes with quality assurance: the production code contains 9,109 functions, with an average cyclomatic complexity of about 5; in the long tail, 456 functions exceed 15 and 127 exceed 30. The codebase is exceptionally consistent, follows domain-driven design throughout, and uses the type system to constrain and express semantics and business logic. It is a textbook example of top-down implementation following sound design.

For one person to systematically rewrite a project of roughly 28,000 lines and evolve it into an engineering system of about 380,000 lines within two months would have been impossible just a few years ago. Moreover, even after the pure design and development phase, there are still operations and deployment to handle, as well as product feedback through the Telegram interface—a span far beyond that of a traditional backend engineer.

Allow me to call software engineering before the widespread adoption of coding agents “traditional software engineering,” because a project like this makes a fundamentally different cost model plainly visible: its scale and efficiency extend far beyond what any engineer’s proficiency in a particular technology stack could cover. Such a vast quantity of code easily overwhelms the economics of human attention. In the past, writing an algorithm and reviewing one could require comparable effort, but an agent can often reproduce an algorithm in mere seconds by going online and consulting best practices. Limited human attention becomes the largest serial component of the entire process. The bottleneck has clearly shifted.

The most intuitive response is to slow down agents’ code output, or to dismiss it all as “AI slop” and return to programming the old-fashioned way. I find this mode of thought and the sentiment behind it immature: it has never concretely demonstrated how much worse “AI slop” is than the work of an experienced senior engineer. Much of engineering taste cannot be measured at all, and one cannot simply declare that spending 99% of the cost for 1% of the performance is necessarily “better.” Before coding agents existed, was the code written by so many backend engineers rushing to ship and meet output targets somehow not slop? Moreover, much of this discourse instinctively invokes AI hallucinations—but why should we assume that a model is sacred and omnipotent in the first place? Does an engineer never make mistakes? And yet why are we able to trust their judgment?

What, ultimately, makes code worthy of trust?

I believe code is trustworthy not because its author is trustworthy, but because it can be systematically verified, falsified, and constrained. Code review is merely one form of governance under the old cost model: we trust that this institution can improve code quality and spread knowledge, while engineers’ mistakes remain rare enough to recover from. If we return to the proper focus—“If it is wrong, do I have mechanisms good enough to catch it?”—the two elements of such an institution become obvious: first, a threshold for admission; second, mechanisms for fault tolerance.

Type systems, tests, linting, architectural checks, and CI are all important, but they address risks that we have already modeled explicitly. Real systems are also shaped by data distributions, concurrency, load, dependencies, kernels, networks, scheduling, and failure modes. That is why static analysis, testing, and CI did not replace reviewers even in the past. Engineers possess a higher-level context: they can imagine what their systems look like at runtime and what semantics and protocols must be obeyed.

Consider today’s coding agents. Reinforcement-learning post-training has raised models’ procedural capabilities to a considerable level, even as some loudly proclaim that “scaling has hit a wall” or invoke the “density law.” I do not intend to discuss here what reinforcement-learning post-training actually does within the model sampling process, nor do I want to delve into the gulf between factual and procedural capabilities. What I want to point out is that the achievements of today’s tool-using coding agents rest on two prerequisites: external knowledge can be conveniently obtained through tools, and measurable quantities and feedback mechanisms are available.

I believe the key to systematic engineering with agents is to let them obtain runtime information invisible in static code and reason from it, instead of relying on knowledge internal to the model for the kind of high-context judgment at which it is not adept. I call systems designed from the outset so that agents can actively query, experiment with, and verify runtime state, critical invariants, and causal evidence Agent-Legible Systems.

Google SRE became a major school of thought in the cloud-native era because it incorporated operational capability itself into system design, turning reliability from after-the-fact firefighting into a system property that could be designed, measured, budgeted, and automated. I believe the key change in AI-native system design is to incorporate observability into system design. We should not wait until the code has been written to find ways for an agent to understand the system; from the very beginning, the system should be designed around how agents will observe and reason about it.

We should shift our focus toward infrastructure. For example, we need to provide this kind of capability: instead of an agent reading through the code like an engineer and saying, “Performance is poor here,” the agent can launch a toolchain and workflow, obtain profiling data, and clearly show that “performance is poor here.” Instead of spinning up a host of subagents for review and receiving some number of P0 and P1 findings, an agent can quickly launch a test environment and obtain detailed tracing and crash reports. One of the central values of traditional code review is that reviewers can mentally simulate runtime behavior from experience. We can instead design systems so that agents directly observe the runtime: we provide easy-to-use tools through which they can acquire knowledge, and ensure that the information feeds back into a closed loop.

We do not need to compress and distill this information, express it better, or visualize it. We need to let the information span the entire space, because agent attention is not expensive. In the past, reconstructing events after the fact required extensive reasoning and tedious tool use before one might experience a flash of insight and notice the problem. Now this process of organizing evidence and discovering patterns can be handed entirely to agents, turning heuristic work into data analysis.

Accordingly, humans should not—and need not—spend their scarcest attention inspecting thousands of lines of mechanical implementation. They should review domain models, public contracts, critical invariants, migrations, security boundaries, and irreversible architectural decisions. More and more implementation detail can be handed to agents, while human judgment concentrates on what the system ultimately permits to happen and what it must never permit. At the same time, I believe we should practice agile development, poetic programming, and documentation first. “Documentation first” should not mean Big Design Up Front. It should mean prioritizing the preservation of stable facts during collaboration: ADRs, schemas, migrations, typed interfaces, composition roots, and runbooks. This reduces the tacit knowledge for which “only one person knows why” and lets humans and agents work from the same source of truth.

Looking back at history, the need for communication between heterogeneous systems gave rise to the enterprise service bus; overengineering then gave rise to the idea of microservices; distributed systems, in turn, introduced SRE. This time, agents have profoundly overturned the traditional cost model of software generation. In response, we should design a closed loop in which agents propose hypotheses → manipulate the environment → obtain runtime evidence → falsify hypotheses → modify the system → verify again, thereby creating agent-legible systems. After all, architecture means thinking from the vantage point of a system’s evolutionary lifecycle—its flourishing and decline. This time, we let agents directly feel the system’s breath and pulse, and take part in its evolution.