Using AI to Turn Changelogs Into Release Notes People Actually Read

Your changelog and your release notes are two different documents pretending to be one. The changelog is a list of commits: fix: null check in invoice serializer, chore: bump pino to 9.2, feat: add webhook retry backoff. It’s accurate, it’s complete, and almost nobody outside your team reads past the third line. Release notes are the version your users open — and the gap between the two is exactly the work most teams skip when a deadline is close.

That gap is where a language model earns its place. Not to write the release for you, but to do the boring translation step: cluster forty commits into five themes, drop the dependency bumps a user never sees, and rewrite feat: add webhook retry backoff as “Failed webhooks now retry automatically instead of dropping silently.” We ran a few weeks of our own releases through this and the pattern that worked was narrow and repeatable.

What the model is actually good at here

The useful tasks are the ones that are mechanical but tedious, and the model handles each one without much prompting.

Filtering signal from noise. A merged sprint is mostly commits your users will never feel: lockfile updates, test refactors, CI tweaks, internal renames. Feed the model the raw git log between two tags and ask it to drop anything that doesn’t change observable behavior. It’s reliable at recognizing chore, test, build, and ci prefixes, and reasonable at spotting internal-only refactor commits that produce no user-facing change.

Grouping by theme instead of by commit. Eight commits might all serve one feature — the migration, the API route, the UI, the docs, three fixes, and a copy tweak. Users want one bullet, not eight. The model collapses these into a single themed item far more consistently than a regex over commit prefixes ever will.

Rewriting from the reader’s side. fix: race condition in session refresh means nothing to a user. “You’ll no longer get logged out mid-session on slow connections” tells them what changed for them. This second-person rewrite — from what the code did to what the user now experiences — is the single highest-value transform in the whole pipeline.

Where it invents things, and the gate that catches it

The failure mode is consistent and worth naming plainly: the model fills gaps with plausible detail. Give it fix: handle empty cart and it may confidently write “Added support for saving carts across devices” — a feature that does not exist. It pattern-matches a terse commit to a familiar product story and ships the story.

Three categories of error show up repeatedly:

• Invented scope. A one-line bug fix gets described as a new capability.
• Wrong severity. A minor internal tweak becomes a headline; a genuinely breaking change gets buried in a “minor improvements” bucket because the commit message was understated.
• Lost specifics. “Improved performance” with no number, when the commit and its diff clearly showed a query going from N+1 to a single join.

The workflow that holds up keeps the human at the verification step, not the writing step. The model proposes; you confirm against source. That ordering matters: rewriting from scratch is slow and you’ll skip it under deadline, but checking a draft against a commit list is fast enough that you’ll actually do it every release.

A prompt that reduces the invention rate, roughly: give it the commit list, tell it to produce one bullet per user-facing change, require it to cite the commit hash each bullet came from, and instruct it to write UNCLEAR rather than guess when a commit’s intent isn’t obvious from the message. The hash citation is the part that makes review tractable — every claim is traceable to a line of history in seconds.

Wiring it into a workflow you’ll keep using

A tool you run by hand once gets abandoned by the third release. The version that survives is the one wired into the release itself. The shape we settled on:

1. On tag, collect git log <prev-tag>..<new-tag> with full commit bodies.
2. Pass it to the model with the citation-and-UNCLEAR prompt above.
3. Drop the draft into a shared doc — Notion works well because the draft lands somewhere the whole team can edit, not buried in a terminal.
4. One reviewer diffs each bullet against its cited commit, fixes severity and specifics, resolves every UNCLEAR.
5. Publish — to your changelog page, your in-app “what’s new,” and the channel where users actually look.

The last step is the one engineers underrate. Polished release notes that live only on a static /changelog page reach the handful of users who think to check it. The releases that drive re-engagement are the ones pushed to where attention already is — an email, an in-app banner, a community post. The AI step buys you the time to do that distribution work, because it removed the hour you used to spend staring at git log trying to remember what shipped.

The honest summary: AI doesn’t write your release notes, it does the translation and clustering you were going to skip, and it hands you a draft fast enough that the human review actually happens. The value isn’t automation — it’s that the tedious step stops being the reason good release notes never ship.