Strip the Comments Before You Feed the Context
The model read the comment. Then it read the code. Then it got confused.
The contradiction problem
Your codebase has comments. Some were written last week. Some were written three years ago by someone who left. Some describe behavior that was refactored twice since then.
To a human reviewer, stale comments are noise. You skim past them, trust the code, maybe leave a "TODO: update this comment" that never gets done.
To an LLM, every comment is context. Equal weight. Equal validity. The model cannot distinguish between "accurate description of current behavior" and "outdated note from 2019 that contradicts the implementation."
When the comments disagree with each other, the model has to pick a side. Sometimes it picks the wrong one. Sometimes it tries to satisfy both, generating duplicate methods or ignoring your instructions entirely.
"If your code is full of comments, those comments are often not in agreement with one another. And so those comments influence the large language model as you go."
Hannes Rudolph,
The experiment
One developer hit a wall on an experimental project. Full vibe-coding mode: let the agent run, don't look at anything, ship fast. It worked until it didn't. The agent started producing output that made no sense, ignoring clear instructions, generating code that contradicted itself.
The fix was not a prompt change. It was not a model switch. It was stripping the comments.
"I was working on an experimental project where I 100% vibed it and I didn't look at anything and then I got to a place where it just stopped working. So what I did is strip out all the comments and it responded 100 times better immediately."
Hannes Rudolph,
No tuning. No elaborate system prompt. Just removing the contradictory context that was poisoning every interaction.
The tradeoff
This is not "comments are bad." Comments written for humans serve a real purpose: explaining intent, documenting edge cases, warning future maintainers about non-obvious behavior.
The problem is accuracy decay. Comments that were true when written become false as code changes. The code gets updated; the comment does not. Over time, a codebase accumulates layers of contradictory documentation, each layer confident about behavior that no longer exists.
For human readers, this is annoying but manageable. For LLMs treating every token as valid signal, it is actively harmful.
"If you're going to have comments, make sure they're extremely accurate. Otherwise, just don't have them."
Hannes Rudolph,
The rule is binary: accurate comments help. Inaccurate comments hurt. There is no neutral middle ground where stale comments are "fine."
The practical workflow
Before running an agentic task on a legacy codebase:
-
Audit comment freshness. When was this file last meaningfully edited? Do the comments describe current behavior or historical behavior?
-
Strip aggressively if uncertain. If you cannot verify a comment is accurate, remove it. The model will read the code. The code does not lie about what it does.
-
Keep comments that encode intent. "We do X because of constraint Y" is valuable if Y is still true. "This function does Z" is worthless if the function was refactored.
-
Re-add comments after the task. Once the agent finishes and you review the output, add fresh comments that describe the new state. Future agents (and future humans) will thank you.
Comment freshness: old approach vs. context-aware approach
| Dimension | Old approach | Context-aware approach |
|---|---|---|
| Comment treatment | Leave all comments in place | Audit and strip stale comments before agent tasks |
| Accuracy assumption | Comments are helpful documentation | Comments are context that LLMs weight equally with code |
| Debugging focus | Prompt engineering and model selection | Context hygiene and contradiction removal |
| Post-task workflow | Move on to next task | Re-add accurate comments describing new state |
| Signal quality | Mixed signals from years of accumulated notes | Clean signal from verified, current documentation |
How Roo Code handles context for better agent output
Roo Code closes the loop by reading your codebase, proposing changes, running tests, and iterating based on results. This agentic workflow means every piece of context in your files directly influences what the agent produces.
When you use BYOK (Bring Your Own Key) with Roo Code, you control the models and the tokens. But model quality only matters if the context is clean. Contradictory comments in your codebase act as noise that competes with your actual instructions.
Before starting an agentic task in Roo Code, strip stale comments from files the agent will touch. The agent reads code as truth. When comments contradict that truth, the agent may generate code that satisfies the outdated comment instead of your current requirements.
Why this matters for your workflow
If you have been debugging agent behavior and the model keeps making confident mistakes, check the comments. The model might be reading a description of how the code worked two years ago and trying to make the current code match that description.
The fix is not a prompt. The fix is context hygiene.
Strip the comments. Let the model read the code. Add accurate comments back when you are done.
Frequently asked questions
Stop being the human glue between PRs
Cloud Agents review code, catch issues, and suggest fixes before you open the diff. You review the results, not the process.