How to Remove Code Comments Before Using AI

Decide what should be removed

Comments can consume space in a prompt, but they are not automatically waste. A license block, generated documentation, disabled experiment, or repeated explanation may add little value to a debugging request. A short note explaining an unusual invariant, security decision, expected unit, or compatibility constraint may be essential. Start by defining the AI task. If you want a syntax review, much of the prose may be removable. If you want the model to explain intent or check whether implementation matches requirements, comments can be part of the evidence.

Send the smallest complete excerpt that reproduces the problem. Include imports, types, configuration, and nearby call sites only when they influence the behavior. Removing unrelated files often saves more tokens than aggressively modifying one relevant function.

Understand why simple replacement fails

A global search for two slashes or a hash character can damage valid program text. URLs contain two slashes. Regular expressions, shell parameter expressions, templates, and string literals may contain characters that resemble comments. Some languages use nested block comments, documentation strings, directives, or multiple comment styles. Removing line breaks blindly can also join tokens that were previously separate and create a different program.

For JavaScript and related languages, a syntax-aware parser is safer than a regular expression when the input parses successfully. A conservative scanner is preferable when full parsing is unavailable, but its result still requires review.

Use a safe cleaning workflow

1. Keep the original source in your editor or version control.
2. Copy only the files or functions relevant to the question.
3. Select the correct language or comment style.
4. Remove trailing spaces and repeated blank lines before changing code structure.
5. Preview the result and compare it with the original.
6. Paste the cleaned copy into the AI prompt; do not overwrite production source.

If the prompt is still large, remove generated files, bundled libraries, logs, snapshots, and duplicated examples. These usually create more avoidable volume than short comments written by a developer.

Keep comments that carry requirements

Retain comments that describe behavior the code cannot express by itself. Examples include why a timeout differs from a default, which external system owns an identifier, what threat a validation rule addresses, and which edge case a workaround prevents. A model reviewing code without those facts may recommend a superficially cleaner change that breaks a real requirement.

You can move critical notes into a short prompt section labeled “Constraints” instead of leaving them scattered through a long excerpt. This makes the information easier to see and lets you remove repetitive commentary while preserving intent.

Handle language differences

Python uses hash comments, but triple-quoted strings are executable expressions and sometimes serve as docstrings. JavaScript, Java, C, and C# use line and block comments, with different rules for strings and templates. Shell files use hash comments but also rely on a leading shebang. CSS and HTML have their own block forms. Choose a cleaner designed for the source you are handling, and treat mixed-language files such as HTML with embedded scripts as separate sections when possible.

Preprocessor directives, JSX, templates, heredocs, and embedded query languages deserve extra attention. When a tool reports a parsing problem, reduce the excerpt to one language or keep the original formatting.

Validate the cleaned excerpt

Compare line count, structure, and string content. Confirm that quoted URLs, regular expressions, template expressions, directives, and multiline strings remain unchanged. If the code can be run safely, pass the cleaned copy through its normal parser, formatter, compiler, or focused tests. Then check whether the AI still receives the error message, expected behavior, and constraints needed to answer the question.

A smaller prompt succeeds only when it preserves meaning. Record the before-and-after token estimate if cost or context capacity matters, but judge the transformation by whether the same engineering question can still be answered correctly.

Worked example: preserve a URL and a requirement

For a JavaScript review, remove the redundant trailing comment but keep the timeout requirement in the prompt.

Original excerpt

// Keep this timeout: the upstream service can take 25 seconds.
const timeoutMs = 30000;
const endpoint = "https://example.com/api"; // API endpoint

Prepared excerpt

const timeoutMs = 30000;
const endpoint = "https://example.com/api";

Alongside the code, include: “Constraint: preserve the 30-second timeout because the upstream service can take 25 seconds.” This keeps the reason for the value available to the reviewer. The slashes inside the URL must remain unchanged.

Three checks before copying

• Compare string literals and regular expressions with the original.
• Run the excerpt through the project's parser or focused checks where available.
• Keep license notices and required attributions when redistributing code; do not assume that all comments are disposable.

Try the Code Comment Minifier on a copy, then compare prompt estimates in the Token Counter & Cost Estimator. Token savings alone do not establish that the code still means the same thing.

Related guides

• How to Reduce AI Token Costs Without Losing Useful Context
• AI Tokens and Context Windows
• How to Prepare Documents for AI