The Erasure of Code Authors
The Foundation of Traditional Review: Code Has a Human Author
Traditional software code review rests on an unshakable premise: every piece of code corresponds to an identifiable human author.
In review, we probe three layers: what logic does this code implement? Why was this particular approach chosen? Is there a better way to write it? Among these, "why this approach" is the core of review — it is fundamentally about tracing the developer's design intent.
When a reviewer encounters an unusual conditional branch, they ask: was this built for a specific edge case? The author can supply the full context — for instance, this logic handles a client-specific business requirement for Brazilian timezone offsets — and the reviewer understands that code which appeared strange has legitimate business justification.
This entire logic of intent-tracing collapses completely when code is purely AI-generated.
AI-Generated Code Carries No Subjective Design Intent
AI-generated code does not carry human intent.
This is not a matter of intent being hidden inside model weights — it is that the concept of "subjective intent" does not apply to large models. Intent requires a subject capable of deliberate choice: a person, in a specific context, actively choosing this implementation over alternatives. A large model's code output is a single random sample from a high-dimensional probability distribution. There is no subjective "choice" — only probabilistic output tendency.
Ask a human developer, "Why didn't you introduce a cache here?" and they can articulate a clear tradeoff: this data has a three-second TTL; the performance gain from caching does not justify the added maintenance complexity.
Ask AI the same question, and you receive no corresponding decision rationale. It is not that the model refuses to answer — it is that no subjective tradeoff occurred during generation. The code is the product of a prompt and a random seed combined through sampling. There was no decision process.
This means the core of traditional review — tracing design intent — loses its entire basis. The object of review scrutiny must be rebuilt from the ground up.
The New Object of AI Code Review: Runtime Behavior
The primary object of review is no longer the code text — it is the code's actual runtime behavior.
We stop asking about design reasoning and instead focus on three questions: what is the complete execution logic of this code? Does it produce side effects beyond what the business expects? Does it omit any functionality required by the specification? These three questions correspond to three new review work modes.
First, behavior tracing. In traditional review, verifying runtime behavior belongs to testing, not review. But code without an author cannot be understood through the designer's explanation — the only path to understanding behavior is execution and verification. When you receive AI-generated code, run it before reading the diff. Feed it normal business data, null values, extremely long strings, and malformed inputs. Observe program output and crash risk. The review function now must absorb basic behavior verification work.
Second, side-effect detection. Large models frequently introduce logic that the requirements never mentioned: similar functions in the training corpus commonly import a third-party library, so an unrelated dependency is silently added; a sampling path shift alters global shared state without warning. These are not bugs in the traditional sense — a bug is a failure to correctly implement required functionality. These are actions the program performs that the specification never authorized. In traditional settings, manual reading and static analysis tools jointly catch these issues. In the AI era, this evolves into diff-comparison review: not limited to code changes, but focused on comparing actual behavior against expected business behavior.
Third, specification coverage verification. Compare the requirements described in the prompt against what the code actually implements, and identify the gaps. The requirement asks for exception handling — the model adds a basic try-catch but omits log instrumentation. It asks for a performance optimization — caching logic is added but cache expiration is never handled. These omissions are not the AI actively removing functionality; they occur because the sampling process did not cover that logic, or because the requirement description did not explicitly constrain the detail. In traditional development, the author would notice and fill in these gaps. AI-generated code has no designer to catch them. The reviewer must check every requirement point against the specification, item by item, to confirm complete coverage.
The Unifying Logic of New Review: Interrogate Code, Don't Read It
Behavior tracing, side-effect detection, and specification coverage share a single core principle: stop reading code statically. Actively verify what the code does through every available means.
For example: what output does input X produce? Does the program read or write local files? What status code does it return on timeout? In traditional review, these questions go directly to the author. In the AI era, they can only be answered by running the program, printing logs, and invoking test suites. Code transforms from passive text to be read into an active entity to be interrogated. Review shifts from textual reading to behavioral interrogation.
This shift brings a material change in the skill requirements for review. Traditional review demands knowledge of programming languages, design patterns, and project history. AI-era review additionally demands a verification methodology — the ability to confirm, in the absence of a subjective design agent, that program behavior is safe and compliant.
AI Can Only Perform Static Checks — It Cannot Conduct Full Business Review
A common view holds that large models can replace human code review. AI can certainly identify unused variables, null pointer risks, and excessive cyclomatic complexity — but these tasks belong to static syntax analysis, not code review in its full sense.
The core judgment of a complete review is: given the current project architecture, the team's business context, and the phased roadmap, should this code change be allowed to merge? Models cannot access team-specific organizational information: they do not know that the same module had a similar defect last week, that the corresponding service is being decommissioned next month, or that the team maintains a long-standing norm of "simplicity over completeness."
These constraints are not syntactic — they are organization-specific business and collaboration rules. AI can recognize universal patterns in code, but it cannot judge the appropriateness of a change under a specific team's constraints. There is no absolute standard for "correctness" in engineering — it is a subjective decision made within contextual constraints, with real consequences that must be borne. Models bear none of that risk.
The Intent Transmission Chain Breaks, and Organizational Memory Shifts Carriers
Mature code review is not only defect detection — it is an internal knowledge transmission channel. Authors embed the reasoning behind their implementation choices in code. Reviewers absorb this context through reading. Future maintainers can then avoid repeating historical mistakes.
When code loses its human author, this knowledge transmission chain breaks directly. AI-generated code has no human decision process to trace. The reviewer can only summarize runtime behavior from the code — they cannot access the design considerations behind it.
The deeper impact is on the mechanism by which organizational memory is generated. Historically, newcomers studied the team's code history to absorb unified coding standards, system design patterns, and canonical problem solutions. Code was the carrier of the team's collective memory. AI-generated code is merely a sample from publicly available training data across the internet. It carries universal technical patterns, not the team's accumulated business context.
Closing this gap requires process design, not technical tools. Every time AI-generated code is merged, a review decision record must accompany it. The record does not restate what the code does — test cases already capture that. It states: among all feasible implementation options, why the team chose this version. This record is written by the reviewer, preserved permanently alongside the commit, and becomes the new form of team organizational memory.
The New Role of Review in the AI Era: Interrogative Collaboration
In its earliest form, code review was a defensive measure — intercept defects before merge. As software engineering matured, it evolved into a collaborative process for transmitting knowledge, unifying standards, and building trust.
In AI-native development, review enters a third form: interrogative verification. The reviewer no longer faces a communicable developer — they face a block of generated code with no subjective intent and behavior subject to stochastic variation. The logic cannot be trusted by default, and the verification process cannot be abbreviated. Latent defects introduced by random sampling will flow directly into production systems if unchecked.
The workflow consolidates into three steps: fully interrogate the code's runtime behavior, make a merge decision bounded by team constraints, and preserve the decision rationale from this review. Through this process, the broken organizational knowledge chain is reconstructed — adapted to a new development paradigm where code carries no author.