LLM-Assisted Code Review and the Write-Only Code Problem

AI-assisted code analysis measurably compresses pull request lifecycle durations. Controlled benchmarks, such as Peng et al. (2023), demonstrate significant developer throughput acceleration on isolated implementation tasks. In production engineering teams, automated PR triage and semantic linting reduce review turnaround from several days to under 24 hours. The primary architectural benefit is the compression of continuous integration feedback loops, surfacing interface violations before human architectural review begins.

Those numbers are real. So is the problem they obscure: AI‑generated code is accumulating in codebases faster than teams can understand it, leading to a new category of technical debt, code that works today but that no one can confidently change tomorrow. When developers cannot predict the impact of a modification, any change becomes a risky gamble.

The Write-Only Code Problem

"Write‑only code" is a term borrowed from write‑only memory, a concept so absurd it became a joke. In the context of AI‑generated code, it describes something genuinely happening: code that was generated, passed review, and merged, but that no engineer on the team fully understands. This is not a hypothetical. It follows directly from how AI code generation works:

1. A developer prompts an AI assistant with a task.
2. The assistant produces a plausible implementation.
3. The developer checks that it passes tests and looks reasonable. At this point the developer often assumes correctness without digging into the logic.
4. It is merged.

The problem lies in step 3. "Looks reasonable" is not the same as "I understand what this does and why." When the code needs to change, because requirements shift, a bug appears, or a dependency is updated, the team discovers that no one can safely modify it. The code is effectively write‑only. Without a mental model of the implementation, any edit can introduce subtle regressions. A 2024 survey by GitClear analyzed 153 million lines of code and found that AI‑assisted codebases showed a measurable increase in code churn (code added and then reverted or modified within two weeks) and a decrease in code moved or updated, suggesting that AI tools are producing more throwaway code and less deliberate refactoring. Higher churn signals that initial AI suggestions often miss deeper design considerations, prompting rapid rewrites.

What AI Review Tools Actually Do

AI‑assisted code review tools (CodeRabbit, GitHub Copilot code review, Sourcery, Amazon CodeGuru) analyze pull requests and flag:

• common bug patterns (null dereferences, off‑by‑one errors, missing error handling); these patterns are easily caught by static analysis because they violate language semantics.
• security issues (hardcoded credentials, injection risks, insecure dependencies); such flaws can lead to exploitable vulnerabilities if left unchecked.
• style and consistency violations; consistent style reduces cognitive load for future readers.
• missing test coverage for changed paths; coverage gaps hide potential regressions.
• documentation gaps. Absent documentation forces developers to infer intent from code alone.

These are genuinely useful. They catch mechanical issues that human reviewers miss when fatigued or under time pressure. They also run consistently, they do not have bad days. However, they cannot:

• verify that the code solves the right problem; a correct algorithm applied to the wrong requirement yields no value.
• assess whether the design fits the system's existing architecture; architectural mismatches can cause ripple effects across modules.
• evaluate whether a new abstraction is worth its complexity cost; unnecessary layers increase maintenance burden.
• understand the business context that makes one correct‑looking implementation wrong; domain rules may dictate constraints invisible to the model.
• catch bugs that require understanding the system's invariants across multiple files. Cross‑file invariants often emerge from runtime contracts that static checks cannot infer.

// AI review will catch: missing null check on user
// AI review will miss: this function is called in a context where
// user.role has already been validated upstream, so adding a
// redundant check here creates a false sense of safety and
// diverges from the established pattern in the rest of the codebase

function getAdminDashboard(user: User): Dashboard {
  // AI suggests: if (!user) throw new Error('User required');
  // Human reviewer knows: callers are guarded by auth middleware
  return buildDashboard(user.role);
}

The Maintenance Debt Accumulation Pattern

The write‑only code problem compounds over time. Each merged AI‑generated function that no one fully understands:

• makes the next change harder (the engineer must reverse‑engineer before modifying);
• reduces the team's ability to reason about system behavior;
• increases the risk that a future change breaks something unexpected; and
• makes onboarding harder for new engineers.

The irony is that AI tools can also read code, they can explain what a function does. But explanation is not the same as understanding. An AI can tell you what a function does line by line; it cannot tell you whether that function should exist, whether its abstraction is correct, or whether it fits the system's design intent.

Why the Debt Accumulates Silently

The write‑only code problem is hard to detect because it does not show up in the metrics teams typically track. Test pass rates stay green. PR cycle times improve. Deployment frequency may increase. The debt is invisible until someone needs to change the code, at which point the cost of understanding it before modifying it is paid all at once, often under pressure. This is why the GitClear finding about increased code churn is significant: churn is a lagging indicator of write‑only code. Code that was generated, merged, and then reverted or rewritten within two weeks is code that was not understood well enough to be correct the first time. The churn rate is the debt becoming visible.

What Good AI‑Assisted Review Looks Like

The teams that use AI review tools most effectively treat them as a first pass, not a final gate.

Separate mechanical from architectural review

Use AI tools for the mechanical layer: style, common bugs, security patterns, test coverage. Reserve human review time for architectural questions: does this design fit the system? Is this abstraction worth its complexity? Does this change have non‑obvious side effects?

Review checklist:
  AI layer (automated):
    ✓ No hardcoded secrets
    ✓ Error paths handled
    ✓ No known vulnerable dependency versions
    ✓ Test coverage for changed paths

  Human layer (required):
    ✓ Does this solve the right problem?
    ✓ Does the design fit the existing architecture?
    ✓ Can the team maintain this in 12 months?
    ✓ Are there non‑obvious side effects?

Require understanding, not just approval

A reviewer who cannot explain what a piece of code does should not approve it. This sounds obvious, but it is violated constantly when AI‑generated code looks plausible and tests pass. The approval gate should require the reviewer to be able to answer: “If this breaks in production, what would you change and why?”

Track AI‑generated code explicitly

Some teams are beginning to tag AI‑generated code in commit messages or PR descriptions. This is not about blame, it is about knowing where to focus review effort and where to invest in additional tests. Code that no one fully understands needs more tests, not fewer.

Invest in acceptance criteria before generation

The most effective mitigation for write‑only code is writing precise acceptance criteria before asking an AI to implement anything. A function with a clear contract, inputs, outputs, invariants, edge cases, is much easier to review and maintain than one generated from a vague prompt.

/**
 * Calculates the prorated refund amount for a cancelled subscription.
 *
 * @param subscription - Must be in ACTIVE or TRIAL status; throws for others.
 * @param cancellationDate - Must be within the current billing period.
 * @returns Refund amount in cents, rounded down. Returns 0 if less than 1 day remains.
 *
 * Edge cases:
 * - Same-day cancellation: full period refund
 * - Last day of period: 0 refund
 * - Trial period: always full refund regardless of day
 */
function calculateRefund(subscription: Subscription, cancellationDate: Date): number {
  // implementation generated from the above spec is reviewable
  // implementation generated from "calculate refund" is not
}

The Broader Shift in Review Culture

AI‑assisted development is changing what code review is for. When AI generates the implementation, the reviewer's job is less about catching typos and more about:

• validating that the specification was correct;
• ensuring the generated code actually matches the specification;
• assessing whether the specification itself was complete;
• deciding whether the team can own this code long‑term.

This is a harder job than traditional review, not an easier one. Teams that treat AI tools as a way to reduce review effort will accumulate write‑only code. Teams that treat them as a way to redirect review effort toward higher‑value questions will get the productivity gains without the debt.