All posts
·6 min read·The Releasedog pack

AI-drafted release notes that don't sound like a robot

Generative AI can write a changelog in seconds. Here's how we prompt it so the output reads like a human wrote it — because a human still edits it.

aillmrelease-notesprompting

Most AI-generated release notes are easy to spot. They're technically correct, structurally fine, and completely forgettable — the writing equivalent of stock photography. If you're going to use a model to draft your changelog, the goal isn't to save writing time. It's to get a good first draft so a human can spend their time on the last 20%.

Feed it the right source, not all of it

Throwing every commit message at a model produces a wall of noise. We filter upstream: merged PRs tagged with a user-visible label, or Jira tickets closed in the release's version. Fewer inputs, more signal.

Prompt for voice, not just structure

"Write a changelog" gets you a changelog. "Write in the voice of a senior engineer explaining to a friend over coffee" gets you something a person might read for fun. Give the model a voice sample from a past release you liked — it matches tone better than any list of rules.

Ban the obvious tells

Add explicit "don't use" lists to your prompt:delve, leverage, seamlessly, unlock, in today's fast-paced world. The corporate-blog lexicon is the fastest way to signal "AI wrote this."

Ground it in facts, then let it write

The pattern that works: first extract the raw facts (what changed, by who, when, affecting what), then ask the model to narrate over those facts. Two-step prompting beats one-shot generation because it lets you check the facts separately from the prose.

Always edit. Always.

The model gets you to 80%. The last 20% — cutting the one weird sentence, adding the inside joke, linking to the right doc — is what makes the changelog yours. If nobody edits the draft, your users will notice, and they'll stop reading.

A prompt that holds up

Here's the skeleton we use inside Releasedog, adapted for your own use:

  • Role — "You are an engineer writing release notes for other engineers."
  • Voice — paste 1-2 paragraphs from a previous release you liked.
  • Structure — headline, new, better, fixed. 1-3 bullets per section.
  • Constraints — no marketing adjectives, no hype, plain English, active voice.
  • Input — the filtered PR list or ticket list, with titles and short bodies.

Done well, the draft you get back is something you'd be happy to publish with a five-minute polish. Done badly, it's something users scroll past. The prompt is the difference.