The EM's AI Rules Opportunity
Engineering managers care about: team velocity (shipping features), code quality (maintainable, bug-free code), developer growth (team members improving their skills), and team health (developers are productive and satisfied). AI rules support all four: velocity (AI generates correct code faster), quality (consistent patterns reduce bugs), growth (junior developers learn patterns from AI-generated code), and health (less code review friction means less interpersonal tension).
The EM's role with AI rules: the EM does not write the rules (that is the tech lead's job) but the EM ensures: the team adopts the rules (rules are configured in all repos), the rules are useful (gather feedback, remove friction), the rules are maintained (updated when conventions change), and the impact is measured (track before/after metrics for reporting to engineering leadership).
The biggest EM win: code review becomes a conversation about logic and architecture instead of a debate about conventions. With AI rules: the AI handles naming, formatting, patterns, and error handling. The reviewer focuses on: does this solve the problem? Are edge cases handled? Is the architecture sound? Code reviews become faster, more valuable, and less stressful.
Getting Your Team to Adopt AI Rules
Step 1 — Team buy-in: involve the team in creating the rules. Run a 1-hour session: what are our coding conventions? What causes the most code review friction? What patterns do we want the AI to follow? The team writes the initial rules together. Adoption is higher when developers own the rules, not when rules are imposed. AI rule: 'Team-authored rules have higher adoption than top-down mandates. The EM facilitates the session; the team decides the content.'
Step 2 — Configuration: ensure every developer on the team has the AI rules configured in their development environment. For Claude Code: CLAUDE.md in the repo root. For Cursor: .cursorrules. For GitHub Copilot: .github/copilot-instructions.md. AI rule: 'The EM verifies configuration during onboarding: new team members have AI tools set up with the team's rules on their first day. Include AI tool setup in the onboarding checklist.'
Step 3 — Iteration: after 2 weeks, gather feedback. Which rules are helpful? Which are too restrictive? Which are missing? Update the rules based on real usage. Repeat monthly for the first quarter, then quarterly. AI rule: 'Rules are a living document. The EM schedules regular retros on rule effectiveness. Rules that developers consistently override: investigate and update. Rules that consistently prevent bugs: celebrate and reinforce.'
A 1-hour team session: 'What are our top 20 coding conventions?' produces rules the team owns. Developers who wrote the rules follow them willingly. Rules imposed from above: followed reluctantly, worked around frequently. The EM's role: facilitate the session, ensure all voices are heard, and document the outcome as the initial rule file. The team revisits and updates rules quarterly — they are a living agreement, not a fixed mandate.
Code Review Efficiency and Quality
Before AI rules: a typical code review includes 30% convention comments (naming, formatting, pattern choice), 50% logic comments (correctness, edge cases, architecture), and 20% nit-picks (personal preference, subjective style). After AI rules: convention comments drop to near zero (the AI already applied the conventions). Reviews focus almost entirely on logic and correctness. Result: reviews are 30-40% faster and 2x more valuable.
Measuring review efficiency: track PR review time (time from PR opened to approved), review round-trips (number of review cycles before approval), and reviewer comment types (convention vs logic vs nit-pick). AI rule: 'After AI rules adoption: review time should decrease, round-trips should decrease (fewer convention-related rework requests), and the ratio of logic comments to total comments should increase.'
Setting review expectations: AI rule: 'With AI rules: reviewers should not comment on convention adherence (the AI handled it). Reviewers focus on: business logic correctness, edge case handling, performance implications, security considerations, and test completeness. The EM communicates this shift to the team — reviewing conventions when AI rules handle them is redundant work.'
After AI rules adoption: a reviewer comments 'this should use camelCase not snake_case.' But the AI already applied camelCase per the rules — this comment is about old code the developer manually wrote. The EM communicates the shift: with AI rules, convention enforcement is automated. Reviewers focus on logic, correctness, and architecture. Reviewing conventions that AI handles is redundant work that slows the team without adding value.
Developer Growth and Team Metrics
Junior developer acceleration: AI rules are the best tool for accelerating junior developers. The AI generates code that follows senior-level conventions. The junior developer reads, understands, and verifies the generated code — learning the conventions through exposure. After 3 months: the junior developer internalizes the patterns and can write convention-compliant code without AI assistance. AI rule: 'Use AI rules as a teaching tool. In 1:1s: review AI-generated code with junior developers. Ask: why did the AI generate it this way? This builds understanding, not dependency.'
Team metrics for EM reporting: adoption rate (% of team using AI rules), velocity trend (sprint velocity before/after), quality trend (defect rate before/after), review efficiency (review time before/after), and developer satisfaction (survey scores for AI tool effectiveness and rule helpfulness). AI rule: 'The EM presents these metrics in monthly engineering leadership meetings. Positive trends: justify continued investment. Negative trends: trigger rule revision or additional support.'
Coaching AI-assisted developers: AI rule: 'The EM coaches the team on effective AI usage: always review AI-generated code (do not blindly accept), understand what the AI generated and why, modify when the AI's approach does not fit the specific context, and provide feedback to improve the rules when the AI consistently generates suboptimal code. The goal: developers who use AI effectively, not developers who depend on AI blindly.'
Traditional junior onboarding: the senior developer reviews every PR and comments on conventions. This consumes 2-3 hours per week of senior time. With AI rules: the junior's AI generates convention-compliant code. The senior reviews for logic and correctness only. The junior learns conventions by reading AI-generated code. After 3 months: the junior writes convention-compliant code independently. The senior's review time drops by 50%. Both developers are more productive.
Engineering Manager Action Items
Summary of the engineering manager's guide to AI rules adoption and management.
- Buy-in: team writes rules together in a facilitated session. Ownership drives adoption
- Configuration: AI tools set up for all team members. Included in onboarding checklist
- Iteration: 2-week feedback cycle initially, then monthly, then quarterly. Rules are living docs
- Review efficiency: convention comments → near zero. Reviews 30-40% faster, 2x more valuable
- Review shift: focus on logic, correctness, edge cases. Stop reviewing conventions the AI handled
- Junior acceleration: AI rules as teaching tool. Review AI output in 1:1s to build understanding
- Metrics: adoption, velocity, quality, review time, satisfaction. Report monthly to leadership
- Coaching: review AI output, understand the why, modify when needed, improve rules from feedback