{"id":6043,"date":"2026-10-26T08:54:50","date_gmt":"2026-10-26T08:54:50","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=6043"},"modified":"2026-10-26T08:54:51","modified_gmt":"2026-10-26T08:54:51","slug":"stop-repeating-ai-mistakes-code-review","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/stop-repeating-ai-mistakes-code-review\/","title":{"rendered":"How to Stop Catching the Same AI Mistakes in Every Code Review"},"content":{"rendered":"\n

Adding comments such as \u201cplease do not write to the x<\/code> table directly\u201d is a PITA most of the time. If it happens occasionally, fine. But recurring comments? You\u2019d better prepare another liter of coffee. And when this happens a few times a month, you\u2019ve basically got yourself a very expensive cron job.<\/p>\n\n\n\n

Here\u2019s how to stop it.<\/p>\n\n\n\n

A comment left more than twice is an unwritten policy. To fix it, mine your code review history for recurring feedback, then route each pattern to the cheapest layer that can enforce it. Formatting and simple syntax patterns belong in formatters and linters. Rules that require understanding what a change actually does<\/em> belong in a semantic check, such as an invariant in Aviator Verify<\/a>. Judgment calls are left to humans.<\/p>\n\n\n\n

\n

TL;DR:<\/strong> AI slop is often code that ignores your team\u2019s conventions, and senior engineers keep catching it by hand. Turn each recurring review comment into a rule: filter for rules that apply across authors, send syntax issues to linters and semantic rules to invariants, write each rule as a single verifiable sentence, test it in draft mode, then promote it.<\/p>\n<\/blockquote>\n\n\n\n

Why THAT Same Old Review Comment, Again?<\/h2>\n\n\n\n

Coding agents start every session from zero.<\/strong> Cursor, Claude Code, Copilot and their pals start new sessions without the feedback your team has accumulated across hundreds of review threads. So the agent repeats the same mistake, and since agents write code fast, those mistakes pile up at a much higher volume. Yikes.<\/p>\n\n\n\n

Review knowledge is stored in a reviewer\u2019s memory.<\/strong> The senior engineer who remembers last quarter’s partial-write bug only catches it on the PRs she reviews. Her comment fixes one PR, but the underlying rule never becomes part of the codebase\u2019s checks.<\/p>\n\n\n\n

You could try stuffing every rule into the prompt. Aviator’s docs on verification layers<\/a> explain why that is the wrong approach. The agent would need to remember the team’s full ruleset on every submission. One bad submission could slip through if a rule gets overlooked, and every ruleset change would mean re-instructing the agent. Files like CONTRIBUTING.md<\/code> do help, but they are just guidance an agent may or may not follow. They don\u2019t block a merge.<\/p>\n\n\n\n

How Do You Turn a Review Thread Into an Invariant?<\/h2>\n\n\n\n

First, a quick definition. In Verify, an invariant<\/strong> is a team-defined rule applied to every matching change. Acceptance criteria describe what this<\/em> change should do; invariants describe what every<\/em> change should respect (Aviator docs<\/a>).<\/p>\n\n\n\n

Think of your invariant catalog as an anti-slop registry that contains mistakes your team has already caught and corrected.<\/p>\n\n\n\n

1. Mine the Code Review History<\/h3>\n\n\n\n

Scan the last quarter of PRs for recurring comments. Aviator’s docs note that many useful invariants start as review comments left more than twice. If you\u2019d rather not grep through threads by hand, Verify can do the mining for you. The AI from PR comments<\/strong> source analyzes your PR history and drafts invariants based on recurring feedback. According to the docs, it\u2019s often the highest-yield option. AI from docs<\/strong> works similarly by extracting rules from CONTRIBUTING.md<\/code>, LLM.md<\/code>, or similar files.<\/p>\n\n\n\n

2. Keep Only the Rules That Apply Across Authors<\/h3>\n\n\n\n

Filter hard. Aviator’s recurrence test is a good one: if you\u2019d write the same criterion on the next ten submissions, it should be an invariant. Personal preferences, like \u201cI would have named this differently,\u201d belong in human review.<\/p>\n\n\n\n

3. Route Each Pattern to the Cheapest Layer<\/h3>\n\n\n\n

Not every recurring comment needs an LLM-backed check. Send each one to the cheapest layer that can reliably enforce it:<\/p>\n\n\n\n

What the recurring comment looks like…<\/th>Cheapest layer<\/th>Why<\/th><\/tr>
“Fix the indentation” \/ “Sort these imports”<\/td>Formatter<\/td>Fully mechanical, auto-fixable<\/td><\/tr>
“Use camelCase here” \/ “No console.log<\/code>“<\/td>Linter<\/td>Simple pattern, deterministic and fast<\/td><\/tr>
“This should not be any<\/code>“<\/td>Type checker<\/td>The compiler already knows<\/td><\/tr>
“Go through the repository, not raw SQL” \/ “Handlers must authenticate first”<\/td>Verify invariant<\/td>Needs an understanding of what the change does<\/td><\/tr>
“Is this the right abstraction?”<\/td>Human reviewer<\/td>Judgment, not a rule<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

4. Rewrite Each One as a Checkable Statement<\/h3>\n\n\n\n

An invariant has to stand on its own, without the PR context.<\/p>\n\n\n

\n
\"Aviator<\/figure>\n<\/div>\n\n\n

Aviator Verify’s Invariants in action
<\/em>Aviator’s guidance on writing invariants<\/a> comes down to a few rules:<\/p>\n\n\n\n