You will never notice this one, because a shorter list of bugs looks exactly like a cleaner codebase. Every engineer has typed some version of “be conservative” or “only report high-severity issues” into a review prompt. The intention is sound — reduce noise, surface what matters. But with Opus 5, that instruction no longer filters output. It filters the model’s willingness to look. The result is a report that reads like a clean bill of health, and a codebase that quietly accumulates the debt you asked your agent to ignore.
The Prompt That Silently Mutes Your Agent
Consider a team running an AI-assisted code review on a mid-sized service. Their prompt includes a phrase like “be conservative — only flag genuine risks.” They get back five findings. That feels reasonable. The code looks solid. The PR ships.
What actually happened is subtler. A stale dependency would have thrown a warning in the output — that still shows up, because dependency scanners are deterministic. But a stale behavioural hedge — a prompt instruction written months ago that tells the model to suppress uncertainty — throws nothing at all. It is not a runtime error. It is a prompt-level instruction that the model continues to honour long after the context that motivated it has changed.
The danger is structural. Dependency warnings are visible by default. Behavioural hedges are invisible by design. One degrades loudly. The other degrades in silence.
Why "Be Conservative" Used to Work
The phrase was never unreasonable. Earlier models hallucinated findings aggressively. They flagged style preferences as bugs. They invented vulnerabilities that did not exist in the codebase. Telling the model to exercise restraint was a practical way to raise the signal-to-noise ratio.
Engineers learned to write prompts that said things like:
- “Only report high-severity issues.”
- “Ignore stylistic concerns.”
- “Be conservative in your assessment.”
These instructions worked because the models they targeted had a known failure mode: over-reporting. Dampening output was a feature, not a bug. The prompt and the model’s tendency cancelled each other out, producing roughly the right volume of findings.
That balance no longer holds. The model has changed. The prompt has not.
What Anthropic's Own Guide Says About Opus 5
According to Anthropic’s Opus 5 prompting guide, if a review prompt says “only report high-severity issues” or “be conservative,” the model may follow that instruction literally and report less. It does not second-guess the constraint. It does not interpret “conservative” as “thorough but selective.” It reduces output volume in direct proportion to the suppression instruction.
This is a meaningful behavioural shift. The instruction that once filtered noise now filters signal. The model is more capable of finding real issues, but the prompt is telling it not to bother looking for them unless it is confident they are critical. For anything below that threshold — medium-severity bugs, latent design issues, subtle security gaps — the agent stays silent.
The output still reads clean. The list is shorter. The team sees fewer findings and concludes the code is in good shape. But the absence of findings is not evidence of absence. It is evidence of a prompt that told a capable model to stop searching.
Why the Damage Is Invisible
Over time, the consequences compound. Issues that would have surfaced in a thorough pass accumulate in the codebase. They do not disappear — they wait. A security gap that a previous model would have flagged becomes a vulnerability in production. A design smell that an earlier prompt would have surfaced becomes a refactor six months later.
The team’s confidence in their code quality is inversely correlated with the actual quality, because the instrument they trust to measure it has been silently recalibrated.
The Fix: Report First, Filter Second
The solution is to invert the workflow. Instead of telling the model to be conservative inside the review prompt, instruct it to report everything it finds — every concern, every anomaly, every uncertain flag. Then apply filtering in a second pass, ideally in a separate step where a human or a separate agent can see what is being discarded and why.
This approach preserves the model’s full diagnostic capability. Nothing is suppressed at the source. The filtering decision happens downstream, where it is visible, auditable, and reversible.
Concretely, that means:
- Remove suppression language from your review prompts. If your prompt says “be conservative” or “only high-severity,” delete it.
- Add explicit expansion language: “Report all findings regardless of severity. Label each with a confidence score.”
- Filter in a second pass — a separate prompt, a script, or a manual review — where the team can see both the full list and the filtering criteria applied to it.
This is not about generating more noise. It is about making the noise visible so that the filtering decision is yours, not the model’s.
We work with engineering teams to audit their AI-assisted workflows and surface exactly these kinds of silent failures at Code N Rob. If your bug lists are getting shorter and you are not sure whether that is progress or a prompt problem, it is worth checking. The cleanest codebase is the one where you know exactly what was looked for — and what was not.
