AI Coding Tip 041 - Turn Every Human Review Finding Into a Harness Rule

Signup Write New Story AI Coding Tip 041 - Turn Every Human Review Finding Into a Harness Rule by Maxi Contieri by Maxi Contieri | @ mcsee Software Engineer Manager and Book Author at O'Reilly I’m a sr software engineer specialized in Clean Code, Design and TDD Book "Clean Code Cookbook" 500+ articles written

I’m a sr software engineer specialized in Clean Code, Design and TDD Book "Clean Code Cookbook" 500+ articles written

A human should never address the same issue twice.

TL;DR: Turn every human review finding into a harness rule, so the next review starts where this one ended.

You review the AI's pull request and find a problem.

The comment lived in a closed pull request, and the harness never heard about it.

You explained the same naming rule in three pull requests this week.

You're the only memory your harness has.

And you're the most expensive part of it.

You generate code faster than anyone can read it, and you don't scale as a reviewer.

Mäntylä and Lassenius found that 60% to 75% of review defects were about evolvability: naming, structure, and documentation.

A comment in a pull request is a rule living in the wrong place.

The right place is the harness: a linter, a hook, a skill, or a written decision.

Fool me once, shame on you; fool me twice, shame on me.

Traditional proverb, first printed in 1651 by Anthony Weldon

Standards gates block the mechanical findings, so you climb toward design trade-offs and risk.

This is the loop in loop engineering: the evaluation checks every finding you move into it, no human needed.

The harness grows, and rules start to disagree, so you should audit your contradictions every few weeks.

Review this pull request. Fix every problem you find. Tell me when it's ready to merge.

Good prompt 👉 You're reviewing this pull request as the harness, not as a person. Read AGENTS.md, the standards, and the design decisions first. Review the diff against them.

List every finding in a numbered table. For each finding, say who should catch it next time. Pick one: linter, hook, skill, or human.

Then propose the smallest harness change that catches it. Write the rule, the file where it belongs, and a failing example. Don't edit any code.

Don't edit any rule. Ask me to approve each rule, one at a time. Last, list the findings only a human should decide.

Explain why the harness can't. A human reviewer found five issues with different severities. Take the review comments on the pull request.

Write a failing test that represents each finding. Watch it fail on the rejected code. Write a rule that fixes the problem.

Add it to the code standards, style, architecture, and design suite. That way, the finding never reaches a human reviewer again. Considerations ⚠️ Not every finding deserves a rule.

A one-off judgment call about a strange edge case stays a comment.

A rule written after one comment can be wrong.

I wouldn't automate a rule after a single comment.

You should test it on the rejected diff and on a clean one, so it blocks the first and lets the second pass.

Rules are code too, so they need review like any other change.

You move to the decisions that matter, and that's a different job, not a smaller one.

I don't know yet how many findings per review a healthy team should see.

The first weeks cost more time, because you write the rule on top of the fix.

A judge skill costs tokens on every diff, so you should keep the cheap checks in linters.

A finding that depends on context nobody wrote down can't become a rule until you write that context.

https://hackernoon.com/ai-coding-tip-040-ask-the-ai-to-list-where-your-prompts-and-skills-contradict-each-other

https://hackernoon.com/ai-coding-tip-016-your-pull-requests-should-teach-your-next-ai-agent

https://hackernoon.com/ai-coding-tip-027-force-code-standards

https://hackernoon.com/ai-coding-tip-022-give-ai-a-harness-to-work-with

https://hackernoon.com/ai-coding-tip-032-build-a-dark-factory-pipeline

https://hackernoon.com/ai-coding-tip-024-force-a-criteria-check-before-the-task-ends

https://hackernoon.com/ai-coding-tip-006-review-every-line-before-commit

https://hackernoon.com/ai-coding-tip-025-add-a-pitfallsmd-next-to-every-skillmd

https://hackernoon.com/ai-coding-tip-034-stop-hoarding-rules-in-your-agentsmd

https://hackernoon.com/ai-coding-tip-023-how-to-shrink-your-ais-pull-request

https://hackernoon.com/ai-coding-tip-019-tell-the-ai-why-not-just-what

A review is the cheapest way to learn what your harness is missing.

If the finding doesn't become a rule, you pay again next week.

Git hooks and linters hold the mechanical rules.

A validator skill holds the semantic ones.

It lives in an assistant that reads AGENTS.md, like Claude Code.

I am a human who writes as best as possible for other humans.

I use AI proofreading tools to improve some texts.

Most AI detectors will flag this article as AI-generated. That's expected. It's a technical article. It has a rigid format and clear steps to follow.

That's exactly the pattern those tools are trained to catch. I've apparently been "writing like an AI" for decades, long before AI existed. This is a technical article, not a novel.

I welcome constructive criticism and dialogue.

I shape these insights through 30 years in the software industry, 25 years of teaching, and writing over 500 articles and a book.

This article is part of the AI Coding Tip series.

Code Smell 322 - Don't Keep Request-owned Pointers in Long-lived Variables