Claim
AI-generated change descriptions for pull requests, commit messages, and tickets describe what the diff shows but omit why the change was made, which is the one thing a reviewer cannot get by reading the code. The result is worse than a missing description because it displaces the reviewer's motivation to ask.
Mechanism
AI generates descriptions from what is visible in the diff: which lines changed, what types were added or removed, which functions were modified. Reviewers already have access to all of this. What reviewers need is what is not in the diff: the decision that triggered the change, why this approach was chosen over alternatives considered, the architectural invariant the change is meant to preserve, or the bug reproduction path that motivated the fix. This context lives only in the author's head. AI has no access to it, so it substitutes visible syntax details for invisible intent. The substitution is the failure: a reviewer who reads an AI-generated description receives the false signal that context has been provided, reducing the chance they ask for the real context they need.
Conditions
Holds when: the change involves any non-trivial decision or involves a trade-off that a reviewer would need to evaluate. This describes most substantive engineering changes.
Fails when: the change is entirely mechanical, such as a dependency version bump or a variable rename. In those cases the diff is the full context and AI description adds nothing but also harms nothing.
Evidence
Kenton Varda, Principal Engineer at Cloudflare and tech lead for Cloudflare Workers, declared a team moratorium on AI-written change descriptions on July 8, 2026:
"I just declared a moratorium against AI-written change descriptions (e.g. PR and commit messages, also issues/tickets) from my team. AI was writing change descriptions that were worse than useless to me as I tried to review PRs: outlining details of the code that could easily be seen by looking at the code, but omitting the higher-level framing needed to understand broadly what the code is doing."
Signals
- PRs trigger multiple follow-up questions before approval because reviewers do not understand the motivation.
- Review comments ask "why did you do this?" on changes where the description does not explain intent.
- Reviewers say they cannot evaluate correctness from the description alone.
Counter-evidence
Prompting the AI specifically to describe decision rationale and alternatives considered may partially close the gap. Some teams report that AI descriptions accelerate the first read even when they need supplementing with a verbal explanation. The failure mode is most acute for complex architectural changes; on smaller routine PRs, AI descriptions may be adequate.
Cross-references
- Engineering ownership begins with naming the actual problem, not accepting the proposed solution: Ball's parallel observation that engineering ownership starts at problem definition, not solution execution. Both cards surface the gap between visible-but-insufficient detail and the implicit context that makes work understandable and reviewable.