{"slug": "one-good-example-beat-every-ai-writing-rule-i-wrote", "title": "One good example beat every AI writing rule I wrote", "summary": "A developer building an AI-assisted content pipeline around Codenames AI found that a single example article outperformed a 69-line rule file for teaching a model to match their writing voice. After cycling through increasingly complex prompts that produced progressively worse drafts, the developer replaced the rule checklist with a pointer to one shipped article, shrinking the Cursor rule from 69 lines to 23. The switch eliminated over-compliance and generic phrasing, with the example encoding structural choices—such as opening with context and a wrong assumption—that the developer couldn't describe as rules.", "body_md": "I've been building an AI-assisted content pipeline around [Codenames AI](https://codenames-ai.com/) — field reports from the repo, drafted in markdown, synced to dev.to. The part I assumed would be hard was publish automation. The part that actually burned time was teaching the model how to *sound* like me.\n\nI started where most people start: the prompt. I wrote a Cursor rule with tone guidance, pacing notes, section shapes, and a list of things to avoid. If the draft felt flat, add another paragraph to the rule. If it over-corrected, tighten the rule. Iterate until the voice stabilizes.\n\nThat felt like the correct lever.\n\nI assumed a longer, more detailed AI writing rule would produce better drafts. Voice felt like something you could specify in prose: a style encyclopedia with tone, pacing, and guardrails.\n\nEach revision made the output worse in a *different* way.\n\nThe cycle was predictable: generate a draft, dislike the tone, add rules, get over-correction, revert partway, add different rules, hit a new failure mode. Some passes sounded like generic engineering docs: correct, but missing the observations that made the article worth reading. Others had no concrete details. Others followed every instruction and lost personality entirely.\n\nThe rule file kept growing. The drafts kept rotating through new ways to miss the mark.\n\nThe useful move, in hindsight, was deleting most of the rules.\n\nI replaced the checklist with one shipped article: [Schema first, prompt second: valid JSON wasn't enough](https://dev.to/michaeltruong/schema-first-prompt-second-valid-json-wasnt-enough-3nhm). That post already had the shape I wanted — field report, wrong assumption up front, specific failures, tradeoffs, a single takeaway.\n\nThe Cursor rule shrank to a pointer: read the example, match the example.\n\n\"Write more like this article\" beat \"be direct, avoid metaphors, use short paragraphs, include a takeaway.\"\n\nDrafts stopped sounding like engineering documentation. They started carrying the observations and pacing of a field report instead of a rule checklist.\n\nRules describe voice from the outside. An example demonstrates it.\n\nFor long-form writing, an exemplar turned out to be closer to a spec than a style encyclopedia. Rule text and example text fail differently — a checklist compresses badly; an example carries decisions that are hard to encode as rules: pacing, level of detail, how much context to provide, and when to introduce examples.\n\nWhen I asked for \"direct engineer-to-engineer tone,\" the model complied literally and stripped the texture that makes a post readable. When I pointed at a finished article, it copied structural choices I hadn't thought to name: opening with context and a wrong assumption, using bold labels for contrast, ending sections with a concrete mistake instead of a principle.\n\nThe interesting part wasn't that the example contained better instructions. It contained decisions I didn't know how to describe.\n\nI could recognize those choices when I saw them. I just wasn't very good at encoding them as rules.\n\nGit history tells the story cleanly: the checklist-era rule peaked at **69 lines**; the example-pointer rule landed at **23 lines**.\n\nAfter the switch, I spent less time fighting over-compliance and stripping generic phrasing. Voice became more consistent across drafts because the target was an article, not a growing instruction list.\n\n**Maintenance lesson:** At 69 lines, the rule had enough instructions to contradict itself. A single canonical example stays honest. If the next post should sound different, update the example or add a second one for a new format. The rule stays an import statement.\n\n**Tradeoff:** One example encodes one format. Field reports work; a tutorial or release note might need a second exemplar later.\n\n**Tradeoff:** Examples can go stale. If the canonical post ages badly, future drafts inherit the wrong target. Treat the example like code you refactor, not like documentation you forget.\n\n**What I'd do differently next time:**\n\nPrompt engineering still matters for facts, structure, and evidence gathering. For *tone* on long-form posts, though, one good example beat every style guide I wrote.\n\nIf your AI writing rules keep growing and the drafts keep getting worse, stop adding rules. Find an article that already sounds right and make that the spec.\n\nIf you'd like to see the project behind these posts, try [Codenames AI](https://codenames-ai.com/).", "url": "https://wpnews.pro/news/one-good-example-beat-every-ai-writing-rule-i-wrote", "canonical_source": "https://dev.to/michaeltruong/one-good-example-beat-every-ai-writing-rule-i-wrote-7oo", "published_at": "2026-06-12 07:38:06+00:00", "updated_at": "2026-06-12 07:41:48.976438+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "generative-ai", "large-language-models", "ai-products"], "entities": ["Codenames AI", "Cursor"], "alternates": {"html": "https://wpnews.pro/news/one-good-example-beat-every-ai-writing-rule-i-wrote", "markdown": "https://wpnews.pro/news/one-good-example-beat-every-ai-writing-rule-i-wrote.md", "text": "https://wpnews.pro/news/one-good-example-beat-every-ai-writing-rule-i-wrote.txt", "jsonld": "https://wpnews.pro/news/one-good-example-beat-every-ai-writing-rule-i-wrote.jsonld"}}