AI Writing Code for AI: Does Human Readability Still Matter?

When AI starts generating code for another AI, the principle we take for granted—that code is first and foremost written for humans to read—is being re-examined. Recently, a developer on Reddit with long experience in AI and low-level Rust systems raised this question: if the readers of code shift from humans to machines, should we design a machine-oriented language or intermediate representation?

The core of the discussion isn't just "whether readability is needed"—it pulls in a series of more practical questions: compilers have long used intermediate representations, so how will AI change the design of such representations? Once humans struggle to understand code, how do auditing, verification, and behavioral control proceed?

Readability Was Never Free

Traditional programming languages are designed on the premise that developers need to read, understand, debug, and maintain code. Variable naming, indentation, module organization—these conventions all serve human cognition. But the poster points out that when both the producer and consumer of code are AI, these human-optimized designs may become pure overhead.

A more direct idea: have AI generate some kind of machine-friendly intermediate representation instead of human-readable source code. In theory, this could strip away a lot of redundant structure that only serves humans, making information transfer between machines more efficient.

But the problem is that removing readability doesn't necessarily yield real gains. The poster himself raises the counter-question—"or do we just lose the benefits of readability and gain nothing?" This question is key, because readability doesn't just make code easier for humans to read; it also indirectly serves debugging and verification.

Intermediate Representations Aren't New—AI Is the Variable

The poster specifically notes that compilers already use intermediate representations, so "machine-oriented code forms" are nothing new. What really interests him is whether AI should change the way we design these representations.

In traditional compilation pipelines, intermediate representations are transitional forms inside the compiler, ultimately mapping back to human-understandable behavior. But when AI participates in generating and consuming code, intermediate representations may shift from "transitional form" to "primary communication vehicle." This means their design goals change: they no longer need to explain things to humans, but need to let another AI accurately parse intent, make fewer errors, and be easy to compose.

However, this path currently lacks clear engineering consensus. The poster offers no concrete proposal, and the discussion remains at the level of questions. What is certain is that if intermediate representations become the primary language between AIs, their syntax and semantics will differ significantly from today's programming languages.

Intermediate Representation (IR) is an internal data structure used by compilers when translating source code into target code, sitting between the source language and the target machine. Typical examples include LLVM IR, GCC's GIMPLE, and Java bytecode. IR is typically designed to preserve enough semantics for optimization while abstracting away source-language details for cross-platform generation. Traditionally, IR is regarded as a "compiler's private format" that humans rarely write or read directly, but its correctness is guaranteed by formal specifications, compiler test suites, and optimization verification tools. When AI becomes the producer and consumer of IR, IR may shift from an "internal transitional form" to a "communication protocol between AIs," and its design focus may shift from "easy for compiler optimization" to "easy for model parsing and composition"—for example, requiring more explicit intent annotations, fewer implicit context dependencies, and composable module boundaries.

The Real Difficulty: How to Audit Code You Can't Understand

The thornier issue in the discussion comes from control. The poster states plainly: if humans can no longer easily understand code, how do we audit it, verify its behavior, and maintain control over it?

This isn't alarmism. Risks in software systems often come from interactions humans didn't anticipate, and auditing presupposes that someone can understand what the system is doing. If code is generated by AI and consumed by AI, with humans excluded from the reading loop, traditional code review becomes ineffective.

Possible alternatives include behavioral verification, formal methods, and runtime monitoring, but none of these can currently fully replace the depth of understanding that human reading provides. The poster doesn't elaborate on specific technical solutions, but leaves this question to practitioners in compilers, programming languages, and AI.

Formal verification and behavioral verification are the two main alternative approaches to the problem of "unreadable code." Formal verification uses mathematical specifications to prove that a system satisfies certain properties (such as memory safety or freedom from deadlock), without relying on humans reading the code logic; behavioral verification uses testing, fuzzing, or runtime monitoring to observe whether system inputs and outputs match expectations. Both have limitations, however: formal verification requires humans to write specifications and struggles to cover all behaviors of complex systems; behavioral verification can only sample and cannot prove that "no unexpected behavior exists." Traditional code review works because humans can use readability to build a global understanding of system intent, and the alternatives above currently struggle to fully reproduce that depth of understanding—this is the core of the poster's concern.

The Value of Readability May Be Underestimated

Judging from the direction of the discussion, an implicit conclusion is that human readability isn't just "convenience"—it's the foundation of control. Compiler intermediate representations don't need humans to read them directly because a complete toolchain and specifications guarantee their correctness. When AI-generated code lacks such guarantees, readability may be one of the few entry points that let humans intervene and understand the system.

The question the poster raises has no standard answer, but it points to an easily overlooked trade-off: optimizing code forms for machines may improve efficiency, but it may also cause humans to lose the ability to understand the system. Before reliable alternative auditing methods are found, giving up readability requires great caution.

For those working in compiler and programming language design, this may be a direction worth thinking about in advance: once AI participates in code generation, should the design goals of languages and intermediate representations be layered—should machine-oriented efficiency and human-oriented understandability be carried by different representations?

Toolchains and specifications are the precondition that lets compiler IR be trusted even though humans don't read it directly. Take LLVM: its IR has a formal LangRef specification, version-by-version compatibility tests, verifiers for a large number of optimization passes, and an active community continuously fixing bugs. This infrastructure ensures that even if no one reads the IR line by line, its semantics remain controllable. By contrast, AI-generated code or intermediate representations currently lack a comparable ecosystem of specifications and verification: model outputs are probabilistic, the same intent may correspond to multiple forms, and there is no unified definition of "correctness." Thus the poster's implicit comparison is this: the "unreadable but trustworthy" nature of compiler IR is built on decades of engineering accumulation, and for AI code to earn equivalent trust, a similar system of specifications and verification must first be established.

One-line Summary

When AI writes code for AI, should human readability be removed from code design?

Paragraph Summary

The article centers on a Reddit discussion: when AI becomes both the producer and consumer of code, does the human-cognition-oriented readability design become redundant overhead? The poster proposes having AI generate machine-friendly intermediate representations but questions whether removing readability really yields gains. The article notes that compilers have long used intermediate representations, and AI's involvement may change their design goals, shifting them from transitional forms to primary communication vehicles. The thornier problem is control: once humans can't understand code, traditional auditing and code review become ineffective, and behavioral verification and formal methods cannot yet fully replace the depth of understanding from human reading. The core judgment is that readability is not just convenience but the foundation for humans to maintain control over systems, and giving it up requires reliable alternative auditing methods.