Stop re-explaining the same code review rules to your AI agent
If you caught the same naming problem in three pull requests this week, you didn’t have a code problem. You had a harness problem. The rule lived in your head instead of in a linter, a hook, or a validator skill, and your AI agent had no way to know it.
Maxi Contieri’s AI Coding Tip 041 frames this clearly: every human review comment is a defect in the harness, not just in the code. Fix only the code and you pay for the same finding again next week.
The triage workflow
Not every finding belongs in the same place. The article proposes sorting each review comment by who could catch it next time:
- Mechanical findings (naming, formatting): route to a lint rule or a git hook.
- Semantic findings (logic patterns, structural conventions): encode as a rule inside a validator skill the agent reads each session.
- Design findings (architectural trade-offs): record as a written decision with the reason attached.
- One-off judgment calls (strange edge cases that happened once): leave as a comment. Don’t automate after a single occurrence.
The article recommends waiting for the second instance of a finding before writing a rule. One comment can be wrong. Two is a pattern.
️ The rule-writing loop
- Write the rejected code as a failing test case first. The test should fail because nothing detects the problem yet.
- Write the rule that makes the test pass.
- Run the harness against the rejected diff with a criteria check. Keep the rule only if it blocks that diff and passes a clean one.
- Ship the test and the rule in the same pull request as the fix.
The article also flags a cost consideration: a validator skill runs on every diff and spends tokens doing it. Cheap mechanical checks belong in linters, not skills.
Why this compounds
Mäntylä and Lassenius found that 60% to 75% of review defects were about evolvability: naming, structure, and documentation. Those are exactly the findings a linter or hook can catch without a human in the loop. Moving them out of your head and into automated checks is where the leverage is.
The article also flags maintenance: new rules can contradict old ones. Running a contradiction audit every few weeks keeps the harness coherent and lets you drop rules the model has outgrown.
The honest trade-off
The first weeks cost more time. You’re writing a rule on top of the fix instead of just shipping the fix. The payoff is that the finding never reaches a human reviewer again. According to the article, the author doesn’t yet know what a healthy finding-per-review count looks like. Zero means nobody is looking. The goal is to move toward findings that only a human can decide: design trade-offs, business rules, and risk.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
