AIが書いたコメント、残す？消す？ ― AI時代のコメントとの付き合い方 The article examines when to keep or discard AI-generated code comments and provides pract…

As AI coding assistants like GitHub Copilot become a standard part of many developers' workflows, a small but recurring question has emerged in day-to-day practice: when an assistant inserts explanatory comments alongside generated code, should you keep them or strip them out? The answer matters because comments are not neutral. They shape how quickly future readers understand a codebase, and low-quality or misleading comments can quietly erode trust in the very documentation meant to help.

AI-generated comments tend to fall into recognizable patterns. Many simply restate what the code already says, producing lines such as a comment announcing that the following statement increments a counter directly above code that plainly does so. This kind of narration adds visual noise without adding meaning, and it is exactly the sort of comment that experienced engineers have long been advised to avoid. Assistants generate these comments partly because they are trained on large volumes of public code where such patterns appear, and partly because verbose, step-by-step explanation can look helpful in isolation even when it is redundant in context.

The more useful distinction, and one that predates AI, is between comments that explain what code does and comments that explain why it does it. The what is usually best expressed through clear naming and straightforward structure, because the code itself is the most accurate description of its own behavior. The why, on the other hand, captures intent, trade-offs, constraints, and the reasoning behind a non-obvious choice, and that information cannot be recovered by reading the code alone. AI tools are generally good at producing the former and less reliable at producing the latter, since they do not have access to the business context, prior discussions, or design decisions that motivated a particular implementation.

This leads to a practical rule of thumb that many teams appear to be converging on. Treat AI-generated comments as drafts rather than finished text. Keep a comment when it records genuine intent, warns about a subtle edge case, or documents an external constraint such as an API quirk or a workaround for a known bug. Delete or rewrite it when it merely paraphrases the adjacent line, when it states something already obvious from a well-chosen function name, or when it risks becoming stale. Stale comments are a specific hazard: a comment that describes behavior which later changes becomes actively misleading, and AI-inserted commentary can accumulate faster than it is maintained.

Accuracy is another concern worth verifying. Because assistants predict plausible text, a generated comment can occasionally describe what the code was probably meant to do rather than what it actually does. Reviewing comments with the same scrutiny applied to the code helps catch these mismatches before they mislead a teammate months later. Some teams fold this into existing code review checklists, asking reviewers to flag comments that add no information or that contradict the implementation.

The broader tooling landscape reinforces this shift. Beyond Copilot, editors and assistants such as Cursor, Amazon Q Developer, JetBrains AI Assistant, and various open models offer similar inline suggestions, and many can also generate docstrings or summaries on request. That capability is genuinely useful for boilerplate documentation, public API descriptions, and onboarding notes, where consistent structured comments carry real value. The key is matching the tool's output to the situation rather than accepting everything by default.

It also helps to configure the workflow rather than fight it after the fact. Prompts and custom instructions can ask an assistant to comment only non-obvious logic, or to omit explanatory comments entirely for simple code. Linters and formatters can flag empty or duplicated comment patterns, and team style guides can state explicitly how AI-assisted comments should be handled before code is merged.

Ultimately, the arrival of AI-generated comments does not introduce a new philosophy of documentation so much as it raises the volume on an old one. The long-standing principles that comments should explain intent, stay close to the truth, and justify their own existence remain the reliable guide. AI simply makes it cheaper to produce text, which shifts the burden toward disciplined editing. Keeping the good, cutting the redundant, and rewriting the vague is likely to remain the most durable strategy for coexisting with these tools.