I've been building an AI-assisted content pipeline around Codenames AI — 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.
The experiment
I 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.
That felt like the correct lever.
I 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.
The failure loop
Each revision made the output worse in a different way.
The 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.
The rule file kept growing. The drafts kept rotating through new ways to miss the mark.
The accidental discovery
The useful move, in hindsight, was deleting most of the rules.
I replaced the checklist with one shipped article: Schema first, prompt second: valid JSON wasn't enough. That post already had the shape I wanted — field report, wrong assumption up front, specific failures, tradeoffs, a single takeaway.
The Cursor rule shrank to a pointer: read the example, match the example.
"Write more like this article" beat "be direct, avoid metaphors, use short paragraphs, include a takeaway."
Drafts stopped sounding like engineering documentation. They started carrying the observations and pacing of a field report instead of a rule checklist.
Why the example transferred better
Rules describe voice from the outside. An example demonstrates it.
For 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.
When 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.
The interesting part wasn't that the example contained better instructions. It contained decisions I didn't know how to describe.
I could recognize those choices when I saw them. I just wasn't very good at encoding them as rules.
What changed
Git history tells the story cleanly: the checklist-era rule peaked at 69 lines; the example-pointer rule landed at 23 lines.
After 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.
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.
Tradeoff: One example encodes one format. Field reports work; a tutorial or release note might need a second exemplar later.
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.
What I'd do differently next time:
- Ship one article I'm proud of before investing in voice rules.
- Point agents at that article.
- Keep the Cursor rule as workflow plus a link, not a paraphrase of the example.
- Add rules only for things examples can't carry: where files live, what not to paste into Notion, publish steps.
Prompt 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.
Takeaway
If 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.
If you'd like to see the project behind these posts, try Codenames AI.
Top comments (8)
Examples often beat rules because they carry taste in a compressed form. A rule says what to avoid; a good example shows rhythm, judgment, level of detail, and what kind of tradeoffs are acceptable.
For AI writing workflows, I like using a small set of annotated examples: this line works because it is concrete, this paragraph is too polished, this ending earns the ask. The annotation turns style into something the model can actually follow.
That's a good distinction.
What surprised me was that the example worked even without annotations. The article carried decisions I didn't know how to describe, but the model still picked up many of them.
Annotated examples feel like an interesting middle ground between a pure exemplar and a large style guide. You're still grounding the model in something concrete, but you can make specific choices explicit without turning them into dozens of abstract rules.
I'm curious whether that becomes more valuable once you have multiple formats. Right now I only have a small corpus of field reports, so one example goes a long way. I suspect annotations become more useful once you're juggling other writing styles.
I think annotations become more valuable exactly when the format set grows. A single strong example can carry taste for one pattern, but once you have field reports, launch notes, tutorials, and critique pieces, the model needs to know which choices are local to that format and which are global voice. The annotation does not have to be long; even a few margin notes can separate style from structure.
That's an interesting framing.
What I'm realizing is that my current workflow may already be getting some of the benefits of annotations from elsewhere. Between frontmatter, templates, project context, and surrounding metadata, a lot of intent is being carried alongside the example even if it's not embedded directly within it.
In that sense, annotations feel like a way to move that context closer to the specific decision it explains. Almost like inline frontmatter.
The more I think about it, the more that feels like the natural end state.
Exactly. I would count frontmatter, templates, folder structure, and surrounding project metadata as annotations even if they are not labeled that way. The useful question is whether the model can recover the intent behind the example. Sometimes an explicit note helps, but sometimes the workflow already carries that intent implicitly.
That is my hunch too. A pure example transfers taste, but an annotated example transfers taste plus intent. The useful part is not turning every choice into a rule; it is making the few non-obvious choices visible enough that a future reader, or model, can preserve them instead of copying surface style.
The maintenance angle is interesting too.
A rule exists in isolation, so future readers have to infer the intent behind it. An annotated example keeps the implementation and the reasoning together.
That's probably why examples have felt easier to evolve for me. If I disagree with a pattern later, I can look at the example and understand why it existed in the first place rather than just seeing a rule that says "do X".
Feels related to another thing I've been noticing lately: preserving rationale is often more valuable than preserving instructions.
Yes, that is the part I like about annotated examples: they preserve the why next to the what. A rule can drift into dogma, and a raw example can be copied without understanding. The annotation gives future-you a way to change the pattern without losing the original judgment behind it.