How to Prioritize Which AI Rules to Write First

Write the Most Impactful Rules First

A new project could benefit from 50 AI rules. You have time to write 10 this week. Which 10? Random selection: wastes effort on low-impact rules while critical conventions remain unencoded. Prioritized selection: the 10 rules that prevent the most bugs, eliminate the most review friction, and affect the most code. The priority framework: ensures every rule you write delivers maximum value. The rules you write later: can wait because their impact is lower.

The prioritization principle: the best time to write a rule is when the cost of NOT having it is highest. A security rule (prevents vulnerabilities): write immediately. A naming convention (improves consistency): write soon. An import ordering preference (cosmetic): write eventually. The priority: matches the consequence of the convention being violated. Critical consequences: first. Cosmetic preferences: last.

The framework: score each potential rule on three dimensions. Frequency (how often does this convention appear in code?), Severity (how bad is it when the convention is violated?), and Volume (how much AI-generated code does this affect?). The product: Frequency × Severity × Volume = Priority Score. The highest scores: written first.

Step 1: The Frequency-Severity-Volume Framework

Frequency (1-5): how often does code involve this convention? Error handling: every function (5). Database transactions: only multi-table mutations (2). API versioning: only when creating new API versions (1). High frequency: the rule affects code written every day. Low frequency: the rule affects code written occasionally. The AI: generates more code involving frequent conventions, so frequent rules have more impact.

Severity (1-5): what happens when the convention is violated? SQL injection (security breach): 5. Float for currency (financial errors): 5. Wrong naming convention (cosmetic inconsistency): 1. Wrong import order (no functional impact): 1. High severity: violations cause bugs, security issues, or data corruption. Low severity: violations are cosmetic or easily caught in review. AI rule: 'Severity determines the cost of NOT having the rule. High severity = expensive bugs. Low severity = minor inconvenience.'

Volume (1-5): how much AI-generated code does this pattern affect? The error handling pattern: affects every function the AI generates (5). The database migration pattern: affects only migration files (1). A React component pattern: affects every component (5 in a React project). High volume: the rule improves a large amount of AI output. Low volume: the rule improves a small amount. The product: Frequency × Severity × Volume. Maximum: 125 (5×5×5). A security rule affecting every function: 5×5×5 = 125 (write immediately). An import ordering rule: 5×1×5 = 25 (write eventually).

💡 Code Review Comments: The Single Best Priority Source

The most-commented conventions: are the most-frequently-violated conventions. The most-frequently-violated: are the highest-priority rules to write. The comments are pre-prioritized by frequency (the more comments: the more frequent the violation) and pre-validated by the team (the reviewer cared enough to write the comment). Scan 30 days of PR comments. List the top 5 convention topics. Write those 5 rules first. Total effort: 30 minutes of scanning + 15 minutes of rule writing.

Step 2: Source Priorities from Real Data

Source 1 — Code review comments: the conventions that reviewers comment on most frequently. Count convention-related comments in the last 30 days. The top 5: the highest-frequency rules to write. This source: already prioritized by frequency (the most-commented conventions appear most often). AI rule: 'Code review comments: the single best source of rule priorities. They are pre-prioritized by frequency and pre-validated by the team (the reviewer cared enough to comment).'

Source 2 — Bug reports: bugs caused by convention violations. A bug from un-parameterized SQL: severity 5. A bug from missing input validation: severity 4. A bug from incorrect error handling: severity 3. Bug reports: prioritize by severity (the conventions whose violations cause the most damage). Cross-reference with frequency: a high-severity, high-frequency convention: the top priority.

Source 3 — Developer feedback: ask the team: 'Which convention do you wish the AI already knew?' The answers: conventions that developers manually correct most often (high volume). These may not show up in review comments (the developer fixes them before review) or bug reports (the developer catches them before merge). But: they consume developer time and reduce the AI's perceived value. AI rule: 'Three sources: review comments (frequency), bugs (severity), and developer feedback (volume). Combine for the complete priority picture.'

⚠️ Do Not Write All 50 Rules at Once

The temptation: identify 50 conventions the project needs and write all 50 rules in one weekend. The result: 50 untested rules, many too vague, several conflicting, and the team overwhelmed by a 50-rule file they did not help author. Better: write the top 5 this week. Test them. Deploy. Next week: write the next 5. Test. Deploy. After 10 weeks: 50 rules, all tested, all validated by daily use. Each batch: battle-tested before the next arrives.

Step 3: The Ordered Rule Backlog

Create the backlog: list every potential rule with its Frequency × Severity × Volume score. Sort by score (highest first). The result: an ordered backlog where the most impactful rules are at the top. Write rules from the top of the backlog. The first 10 rules: the most impactful. The next 10: still impactful but less than the first 10. The last 10: the least impactful (write when you have time, or skip entirely).

Batch execution: write rules in batches of 3-5 per week (or per sprint). Each batch: the top 3-5 from the backlog. After writing: test with benchmark prompts. Deploy. Measure impact. The next batch: the next 3-5 from the backlog. This cadence: produces 10-20 rules in the first month, covering the highest-priority conventions. The lower-priority rules: added in subsequent months as part of the quarterly maintenance cycle.

Backlog maintenance: as new conventions emerge (the team adopts a new pattern, a new bug type is discovered, a developer requests a rule): add to the backlog with a score. The backlog: always sorted by priority. New high-priority items: may jump ahead of existing lower-priority items. The backlog: a living document that evolves with the project. AI rule: 'The backlog: the rule-writing to-do list, sorted by impact. Write from the top. Add new items as they emerge. Review quarterly to remove items that are no longer relevant.'

ℹ️ The Backlog Ensures No High-Priority Rule Is Forgotten

Without a backlog: you remember to write the rules that annoyed you today. You forget the rules discussed last month. The security rule a teammate mentioned in Slack: lost. The convention from the post-mortem: never written. With a backlog: every rule idea is captured, scored, and ordered. Nothing is forgotten. The highest-priority item: always at the top. New ideas: added and scored, possibly jumping ahead of existing items. The backlog: organizational memory for rule ideas.

Prioritization Summary

Summary of prioritizing which AI rules to write first.

Framework: Frequency × Severity × Volume = Priority Score. Max 125. Write highest scores first
Frequency: how often does the convention appear in code? Every function (5) vs rarely (1)
Severity: what happens when violated? Security breach (5) vs cosmetic inconsistency (1)
Volume: how much AI output does it affect? Every generated function (5) vs rare file types (1)
Source 1: code review comments (pre-prioritized by frequency). The single best source
Source 2: bug reports (prioritized by severity). High-severity convention violations
Source 3: developer feedback (prioritized by volume). Conventions devs manually correct most
Backlog: ordered list by score. Write 3-5 per week. New items added as they emerge. Review quarterly