Why AI-Generated Comments Rot Faster Than the Code They Describe

When an agent writes a function and a comment in the same diff, the comment is not documentation. It is a paraphrase of the code at write-time, generated by the same model from the same context, and it is silently wrong the first time the code shifts. The function gets refactored, an argument changes type, an early-return gets added, the comment stays. By next quarter, the comment is encoding a specification that no longer matches the code, and the next reader trusts the comment because the comment is easier.

This is an old failure mode — humans-edit-code-comments-stay-stale — but agents accelerate it across three dimensions at once. Comment volume goes up because agents add a doc block to every function whether it needs one or not. The comments are grammatically perfect, so reviewers don't flag them as low-quality. And the comments paraphrase the code in different terms than the code actually executes, so they look like documentation but encode a second specification that drifts independently of the first.

The cost shows up later, in the form of a maintenance trap that compounds. A future reader builds their mental model from the comment. A future agent — or a future engineer — "fixes" the code to match the comment when the two diverge. The bug that ships isn't a hallucination. It's a faithful execution of the wrong spec.

The Second-Specification Problem

A code comment that paraphrases the function it sits on top of is a second specification. The function says one thing in code; the comment says something close to that thing in English. As long as both are written by the same author at the same moment, they agree. The instant the code moves, they disagree, and there is no mechanism that makes them agree again.

For human-written comments, this problem self-limits. Humans are lazy about writing comments, so the comments that exist tend to encode something the author thought was worth saying — an invariant, a workaround, a non-obvious reason. Those are still vulnerable to drift, but the volume is small and the surviving comments often encode load-bearing information that a careful reviewer notices when the surrounding code changes.

Agents do not have that filter. An agent will gladly write a four-line docstring describing a three-line function. The docstring restates the parameter names, restates the return type, and restates the obvious. None of it is wrong on day one. None of it is useful on day one either. But every line of it is a hostage to fortune: when the function changes, every clause in the docstring is now a candidate to be wrong. The probability that the whole block is still accurate after two refactors approaches zero, and nobody notices because the comment still reads fluently.

The asymmetry is what makes this dangerous. AI-generated code that breaks tends to break loudly — a type error, a failed test, a 500 in staging. AI-generated comments that drift break quietly. There is no test that fails when a docstring lies. There is no compiler that warns when the prose says "returns null on missing key" and the code now throws. The comment rot is invisible until a reader acts on it.

Why Reviewers Wave Comments Through

In a 2025 GitHub blog post on Copilot code review, the team noted that the agent now averages about 5.1 comments per review and stays silent on 29% of PRs entirely — the result of explicit work to reduce noise so that high-signal feedback survives. The reviewer-side discipline is well understood at this point: when AI review comments have less than a 30–40% action rate, you're generating noise, and the configuration needs tightening.

But the same discipline rarely gets applied to AI-authored docstrings and inline comments inside the diff itself. Two reasons.

First, comments don't break the build. A reviewer scanning a 400-line PR for problems is looking at signatures, control flow, error handling, and the obvious places things go wrong. A grammatically clean docstring on a helper function is a green light visually — it looks like the author cared enough to document. The reviewer's pattern-matcher treats it as a positive signal and moves on.

Second, the comments are uniformly fluent. Human-written comments come in a range of styles that betray the author's relationship to the code: terse for code they wrote and trust, defensive for code they're nervous about, expansive for code that surprised them. Agent-written comments are uniformly polished, uniformly grammatically complete, and uniformly written in the same neutral documentation voice. There is no tonal signal that this comment is more or less load-bearing than the next one. So reviewers either trust them all (the common case) or distrust them all (rare and exhausting).

The fluency gap is the trap. A reviewer who would push back on "ok now we add the user" will not push back on "Adds the user to the database after validating the email and normalizing the username for case-insensitive lookup." The second sentence is no more verified than the first. It is just better-formatted.

The Compounding Maintenance Trap

The first time a comment drifts from the code, the cost is small — a confused reader, a few minutes lost. The compounding cost lives one cycle further out, when the drift starts to influence future edits.

Three patterns recur. The first is the trust-the-comment edit, where a future engineer or agent reads the comment, doesn't carefully re-derive the code's behavior, and writes code that depends on what the comment says rather than what the code does. The second is the fix-the-code edit, where the engineer or agent notices the divergence and "fixes" the code to match the comment, on the assumption that the comment encodes the original intent. The third is the doc-as-API edit, where downstream consumers — including agents in other parts of the codebase — quote the comment as if it were a contract.

Loading…