Evangelism: Making AI Standards a Movement
Policy adoption: developers comply because they must. Movement adoption: developers advocate because they believe. Internal evangelism transforms AI standards from a governance policy into something developers actively promote. The difference: policy adoption plateaus at 80% (the remaining 20% resist or ignore). Movement adoption reaches 95%+ because developers recruit each other.
The evangelism toolkit: stories (concrete examples of AI rules making someone's work better), demos (live demonstrations of AI rules solving real problems), content (internal blog posts, Slack messages, and wiki pages that share best practices), and events (lightning talks, lunch-and-learns, and hackathon integrations). Each tool targets a different audience: stories convince skeptics, demos convince the curious, content educates at scale, and events create community.
The evangelism principle: show, do not tell. 'AI rules improve code quality' is a claim. 'Watch me generate this entire API endpoint with 5 tests in 3 minutes — because the AI knows our conventions' is a demonstration. Claims create skepticism. Demonstrations create believers.
Storytelling: Before and After Narratives
The before-and-after story: the most powerful evangelism tool. Structure: the problem (before AI rules: code reviews took 4 hours because half the comments were about naming conventions and error handling patterns), the change (we deployed AI rules that encode our team's conventions), and the result (code reviews now take 2.5 hours, focused entirely on logic and architecture. Developer satisfaction went from 3.2 to 4.1.). Specific numbers and specific people make stories credible.
Collect stories continuously: after each quarterly review, ask 2-3 developers for their AI rules story. Prompt them: 'What is one specific moment where AI rules saved you time or prevented a bug?' Capture the story in their words — authentic developer voice is more credible than marketing language. AI rule: 'One genuine developer story is worth 10 pages of metrics. 'Maria on the Payments team says review time dropped 40%' resonates more than 'Organization-wide review time decreased by an average of 32%.'
Story distribution: share stories in: engineering all-hands (2-minute spotlight per quarter), the engineering Slack channel (weekly story post), the internal blog (monthly detailed case study), and new hire onboarding materials (stories from people they will work with). AI rule: 'Stories have a half-life. Share them within 2 weeks of collection while they are fresh and relevant. Old stories from 6 months ago lose impact.'
'Maria on the Payments team says her review time dropped from 4 hours to 2.5 hours after AI rules' resonates more than 'Organization-wide mean PR review duration decreased by 32.4% (p < 0.05).' Both say the same thing. The story is remembered. The statistic is forgotten. Collect developer stories after every quarterly review. Share them everywhere. Stories are the currency of internal evangelism.
Demo Culture: Show, Do Not Tell
Live coding demos: the most effective evangelism format. A developer opens their IDE, shows the AI rules file, then live-codes a feature with AI assistance. The audience watches: the AI generates convention-compliant code, handles error patterns correctly, and produces a complete feature in minutes. The developer does not explain the rules — the demo speaks for itself. AI rule: 'Demo on the team's actual codebase, not a sample project. Developers are skeptical of demos that use contrived examples. Real code removes all doubt.'
Lightning talks: 5-minute presentations at engineering all-hands or team meetings. Structure: 1 minute (the problem I had), 2 minutes (how AI rules helped), 2 minutes (live demo or before/after code comparison). Keep it short — attention drops after 5 minutes. AI rule: 'Lightning talks are the highest-reach evangelism tool. 200 engineers in the all-hands see a 5-minute talk. The investment: 30 minutes of preparation. The reach: every engineer in the org.'
Pair programming sessions: the most effective format for individual conversion. A champion sits with a skeptical developer and pair-programs on the skeptic's own task using AI rules. The skeptic sees: the AI generates code that follows their team's conventions, review-ready code is produced faster, and they do not need to change their workflow — just add a file to the repo. AI rule: 'Pair programming converts one developer at a time, but converts them completely. A developer who has experienced AI rules on their own code: becomes an advocate, not just an adopter.'
A demo with a sample todo-app: 'See, the AI generates correct React components!' Audience reaction: skepticism. A demo with the team's actual payment processing code: 'Watch the AI generate a refund endpoint that handles our custom error wrapper, uses our Decimal library for currency, and includes the audit log entry.' Audience reaction: belief. Real code removes all doubt. Contrived examples invite the objection 'that would not work on our codebase.'
Internal Content and Events
Internal blog posts: monthly posts on the engineering blog. Topics: new rule releases with rationale, developer stories and case studies, tips for getting the most from AI rules, comparison of AI-generated code with and without rules, and metrics updates (quarterly results). AI rule: 'Internal blog posts create a searchable knowledge base. When a developer has a question about AI rules: they find the answer in a blog post. The blog scales evangelism beyond one-on-one interactions.'
Slack engagement: a dedicated #ai-standards channel. Content mix: tips (daily — short, practical tips for effective AI rule usage), wins (weekly — developer shares a moment where AI rules helped), discussions (ongoing — developers ask questions, share ideas, propose rule changes), and announcements (as needed — new rule releases, training sessions, events). AI rule: 'The Slack channel is the community's living room. Active channel: indicates a healthy community. Dead channel: indicates the program has lost momentum. Post consistently to keep the channel alive.'
Events: quarterly AI rules hackathon segment (teams compete to write the best rule for a specific challenge), monthly lunch-and-learn (rotating presenters share tips and lessons), and annual AI standards day (full-day event with workshops, talks, and awards for top contributors). AI rule: 'Events create community. A community of developers who care about AI standards: sustains the program when leadership attention shifts to other priorities. Invest in community events as insurance against program neglect.'
Leadership attention is finite. This quarter: AI standards are a priority. Next quarter: the new product launch takes priority. Without community: the AI standards program loses momentum when leadership attention shifts. With community: developers continue advocating, sharing, and improving rules regardless of what leadership is focused on. Events, Slack channels, and champion networks: create the community that sustains the program through leadership attention cycles.
Internal Evangelism Summary
Summary of the internal evangelism strategy for AI coding standards.
- Principle: show, do not tell. Demonstrations > claims. Stories > metrics
- Stories: before/after narratives from real developers. Collect after quarterly reviews. Share within 2 weeks
- Demos: live coding on the team's actual codebase. 5-minute lightning talks for all-hands reach
- Pair programming: 1-on-1 conversion. Most effective for skeptics. Use their own task and code
- Internal blog: monthly posts. New rules, stories, tips, metrics. Searchable knowledge base
- Slack: #ai-standards channel. Daily tips, weekly wins, ongoing discussions, announcements
- Events: quarterly hackathon segment, monthly lunch-and-learn, annual AI standards day
- Community: events build community. Community sustains the program when leadership attention shifts