AI Coding Tip 027 - Force Code Standards

Style errors double when nobody enforces them. TL;DR: Wire your standards into hooks, skills, and a judge, so the harness blocks violations before a human opens the diff. Common Mistake ❌ You paste your coding standards into AGENTS.md and trust the AI to remember them. Then a human reviewer manually checks naming , indentation , and spacing on every pull request. Nobody wires a hook, a skill , or a judge that blocks the diff before a human ever opens it. The standards live in prose, and prose is optional. Problems Addressed 😔 A CodeRabbit analysis of 470 pull requests found AI-generated code carries roughly 1.7x more defects than human-only code, and nearly 2x more naming and style consistency errors Human reviewers burn attention on indentation and casing instead of design , feeding the same broken windows that erode a codebase over time Enforcement depends on someone remembering to check , so it drifts the moment nobody's watching The AI violates a rule it read in prose, because prose isn't a gate, only a suggestion Two human reviewers catch two different subsets of the same code without standards How to Do It 🛠️ Turn each standard into a machine-checkable rule instead of a paragraph of prose. Wire a pre-commit or pre-merge hook that runs the linter automatically on every change. Add a validator skill that reads the rule set fresh and re-checks the whole diff, not just what the AI remembers. Route ambiguous rules, like naming intent, to a large language model (LLM) judge instead of a human reviewer . Block the commit, the merge, or the session end until every gate reports zero violations. Log every violation the judge catches as a new rule , so the harness never misses it again. Benefits 🎯 Consistent gate: Every diff hits the same rule set, so two reviewers never catch two different subsets of the same violation. Faster reviews: Humans spend their attention on design and correctness , not indentation or casing. No memory decay: A skill reads the standards file fresh every session instead of trusting what the AI claims to remember. Judge for nuance: An LLM judge catches the semantic violations a regular expression can't parse, like a misleading name. Compounding rules: Every violation the judge finds becomes a new check , so the harness gets stricter over time. Measurable drop: You can track the naming and style defect rate over time and watch it fall toward zero. Context 🧠 Standards enforcement isn't new. Stephen C. Johnson wrote the first lint in 1978 to catch mistakes in C code that nobody wanted to check by eye. Checkstyle, PMD, and ESLint followed, each one refusing to trust a human to notice a mixed indentation . SonarQube added a server that gates a whole pipeline, not just a single file. Mago does the same for PHP now, running a linter, a formatter, and a static analyzer in one Rust binary fast enough to run on every keystroke. None of these tools ever asked a human to vote on a tab versus a space or a mixedCase versus snake_case name. AI coding didn't remove that need. It multiplied it. A CodeRabbit analysis of 470 pull requests found AI-generated code carries about 1.7x more defects overall than human-only code. Naming and style consistency errors came in at nearly 2x, the exact class of mistake a linter was built to catch decades ago. A model can now write in any human language , misspell an identifier , or reorder parameters inconsistently across two files that it never compared side by side. A linter still catches the syntactic version of these mistakes. The semantic version, like a name that lies about its role, needs a judge who reads intent, not just tokens . That's where an LLM-as-judge step fits: a second AI pass, wired into the same harness that runs the linter, checking the rules no regular expression can express. Skills are the natural home for that judge. A skill reads the standards file fresh every time, instead of trusting a memory that decays across sessions . Pair the judge with a criteria check before the task ends , so the AI can't say a task is done until the standards gate reports zero violations. A gate that blocks the diff is just another way to force the AI to obey you , not by asking nicely, but by refusing to let a violation through. This doesn't replace reviewing every line before commit . It removes the mechanical part of that review, so a human is free to judge design instead of counting spaces . When the judge catches a new violation, log it the same way you'd log a pitfall , so the harness never makes that mistake twice. Prompt Reference 📝 Bad Prompt 🚫 Please follow our coding standards for this feature. Use consistent naming and formatting like the rest of the codebase. I'll check it during code review before we merge. Good prompt 👉 Before you say this task is done, run this standards checklist: - [ ] Run the linter on every changed file, fix every violation. - [ ] Run the formatter, don't hand-format a single line. - [ ] Invoke the code-standards-validator skill on the full diff. - [ ] Check every identifier: no abbreviations, no misleading names. - [ ] Check indentation matches the project config, no mixed tabs. - [ ] Check casing: one convention, no mixedCase next to snake_case. - [ ] Check parameter order against other functions in the file. - [ ] Check spelling in every identifier, comment, and string. - [ ] Judge comment quality: flag dead comments and restated code. - [ ] Judge naming intent: does each name say what it does? - [ ] Confirm no file mixes languages in identifiers or comments. - [ ] Log any new violation type as a rule for the next run. - [ ] Don't report the task done until every box above is checked. Show me the completed checklist, not just the final code. Considerations ⚠️ A linter still beats an LLM judge on speed and cost for anything syntactic. Reserve the judge for rules that need intent, not tokens . A gate that blocks too aggressively gets bypassed with --no-verify , which defeats the whole point. Review the judge's false positives the same way you'd review a flaky linter rule. Type 📝 [X] Semi-Automatic Limitations ⚠️ An LLM judge costs tokens and time on every gate, so it doesn't replace a linter. It complements one. A judge can disagree with itself across two runs on borderline style calls, so keep the deterministic rules in the linter and reserve the judge for what's genuinely ambiguous. Tags 🏷️ Knowledge Management Level 🔋 [X] Intermediate Related Tips 🔗 https://hackernoon.com/ai-coding-tip-004-why-you-should-use-modular-skills?embedable=true https://hackernoon.com/ai-coding-tip-006-review-every-line-before-commit?embedable=true https://hackernoon.com/ai-coding-tip-011-how-to-initialize-agentsmd?embedable=true https://hackernoon.com/ai-coding-tip-015-force-the-ai-to-obey-you?embedable=true https://hackernoon.com/ai-coding-tip-016-your-pull-requests-should-teach-your-next-ai-agent?embedable=true https://hackernoon.com/ai-coding-tip-019-tell-the-ai-why-not-just-what?embedable=true https://hackernoon.com/ai-coding-tip-022-give-ai-a-harness-to-work-with?embedable=true https://hackernoon.com/ai-coding-tip-024-force-a-criteria-check-before-the-task-ends?embedable=true https://hackernoon.com/ai-coding-tip-025-add-a-pitfallsmd-next-to-every-skillmd?embedable=true Conclusion 🏁 A linter never asks permission to reject bad code. Neither should your harness . Wire the standards into hooks, skills, and a judge, so the diff gets rejected before a human ever has to say so. More Information ℹ️ Lint (software) - Wikipedia https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report?embedable=true https://arxiv.org/pdf/2508.02994?embedable=true https://github.com/lukehutch/awesome-static-analysis?embedable=true Also Known As 🎭 Harness-Enforced-Standards Machine-Judged-Style Standards-as-Code Linter-Native-Review Tools 🧰 https://mago.carthage.software/?embedable=true https://eslint.org/?embedable=true https://www.sonarsource.com/products/sonarqube/?embedable=true https://github.com/PHPCSStandards/PHP_CodeSniffer?embedable=true https://docs.astral.sh/ruff/?embedable=true https://rubocop.org/?embedable=true https://checkstyle.sourceforge.io/?embedable=true https://golangci-lint.run/?embedable=true https://doc.rust-lang.org/clippy/?embedable=true Disclaimer 📢 The views expressed here are my own. I am a human who writes as best as possible for other humans. I use AI proofreading tools to improve some texts. 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. https://maximilianocontieri.com/ai-coding-tips?embedable=true