What happens when you dismiss an AI comment

Most AI tools treat a dismissal as a closed conversation. You click "resolve" or "dismiss" and the feedback disappears, until the same comment shows up on your next PR, unchanged, as if you never said anything. That's not a product limitation. It's a design choice. And it's the wrong one.

Codzee stores every dismissed comment as part of a per-repo memory. This post explains exactly what that means, how it works, and what actually changes in your reviews over time as a result.

Why dismissals are signal, not noise

When a developer dismisses an AI comment, they're making a judgment call: this doesn't apply here, this is intentional, this pattern is fine in our codebase. That's useful information. It's not just "the comment was wrong", it's "this team has decided this pattern doesn't warrant attention."

The problem is that most AI reviewers have no place to store that decision. They'll post the same comment about synchronous database calls in a request handler the third time they see it, having already been told twice that this team is okay with it for internal tooling. The reviewer isn't learning. It's just running the same analysis on each PR from scratch.

This is fixable if you treat dismissals as training signal rather than closed tickets.

What Codzee actually stores

Every repository has a memory object in the database, a rolling JSON store that evolves over reviews. When a comment is dismissed via GitHub's "resolve conversation" action, Codzee records:

• The comment category (BUG, SECURITY, PERFORMANCE, STYLE, etc.)
• A normalized pattern description (not the raw comment text, a generalized version)
• The file and directory context where it was dismissed
• How many times this pattern has been dismissed across all PRs

The pattern is normalized so that a dismissal in one file generalizes to similar patterns elsewhere. Dismissing "missing null check on user input" once doesn't mean Codzee will never flag null checks again, it means it will weigh similar findings lower in this repo's context, and those findings need higher confidence to make it past the posting threshold.

How memory affects the next review

When Codzee runs its next review on the same repo, the memory is injected directly into the Sonnet prompt as a structured section. The model sees:

The model uses this context to calibrate what it posts. A finding that matches a dismissed pattern gets a lower effective confidence score, meaning it needs to be a very high-confidence finding to still make the cut. Most dismissed patterns fall below the posting threshold entirely.

The numbers: how fast memory changes behavior

In our beta data, repos with at least 5 dismissed comments see a measurable reduction in repeat findings within 3 to 4 reviews. After 10 dismissals across a repo, the false positive rate drops by roughly 40% compared to a cold-start review on the same codebase.

This isn't because the underlying model is getting better at the language level , it's because the repo context is getting richer. The model has a more accurate picture of what this specific team considers acceptable, what patterns are intentional, and which files deserve heightened scrutiny.

What memory does NOT do

Memory doesn't suppress genuinely new issues. If a pattern has been dismissed before but a new instance of it is particularly high-confidence, say, a null check dismissal in an internal service, but now the same pattern appears in an externally-facing API handler, the model can still surface it. Context changes what matters. The memory shapes defaults, not outcomes.

Memory also doesn't cross repo boundaries. A dismissal in one repository doesn't affect reviews in another. Teams often have different standards for different codebases, and a pattern that's fine in a CLI script might be a real issue in a payment processor. We keep the memory scoped to the repo where the signal came from.

Making the feedback loop visible

One of the things we found in early beta is that the memory system only builds trust when it's visible. If Codzee quietly gets quieter on certain patterns but never tells you why, it just feels random. So we surface the dismissed patterns in the dashboard, you can see exactly what Codzee has learned to avoid in a given repo, and why.

That transparency does something useful: it turns the dismissal gesture from a closing action into a teaching action. When developers know their dismissals are being stored and used, they're more deliberate about them. A quick dismiss on something that genuinely doesn't matter is fine. But they're less likely to dismiss a real finding just to clean up their review queue, because they know that pattern will be learned.

The long-term picture

The goal is a reviewer that gets measurably better every month it's deployed on your repos. Not because we're retraining a model on your data, we're not , but because the context window that model operates in becomes progressively richer. A repo that's been using Codzee for three months has a memory that reflects hundreds of real judgment calls by the engineers who know that codebase best. That's a meaningful edge over any cold-start review.

Every dismissal is an instruction. Codzee just follows them.