How to write release notes with AI

What input produces release notes worth reading?

Merged pull request titles and the issue titles they close, for the window you are shipping, plus the release tag. Not raw commit messages.

The distinction decides the quality of everything downstream. A commit log is mostly refactors, dependency bumps and follow-up fixes to work that never shipped separately, and a model reading it will faithfully summarise all of that, because nothing in the text marks which lines a customer would ever notice. Pull request titles sit one level up, where somebody already made a judgement about what the change was. Issue titles sit one level higher again, where somebody wrote down why it was wanted.

If your repository follows Conventional Commits, the structured prefixes do some of this work already: a feat and a fix are visible as such, and a breaking change carries its own footer. That is a useful head start and not a substitute for the pull request layer, because the prefix says what kind of change it was, not whether anyone outside the team cares.

What does the generation prompt actually look like?

Below are the merged pull request titles and linked issue titles for
release [tag], shipped [date].

Group them into these six types only: Added, Changed, Deprecated,
Removed, Fixed, Security. Put anything you cannot place into a seventh
list called Unclear, with the reason.

For each entry write one sentence in plain language, naming what a user
can now do or no longer has to do. Do not use internal component names.
Do not merge two changes into one line. Do not add adjectives.

[paste titles]

The Unclear list is the part worth keeping. A model asked to categorise everything will categorise everything, including the twelve entries that are internal work with no user-facing effect, and those will arrive dressed as improvements. Forcing a seventh bucket turns the guesswork into a visible list you can delete in one pass.

Ask for plain language explicitly, and name the two failure modes you expect: internal component names, and lines that quietly merge two changes so the summary looks tidier. Both slip through a casual read and both cost the reader real time.

The three edits a model never makes

• The cut. Handed 40 merged changes, it summarises 40. Deciding that 34 belong in an internal log and 6 belong in front of customers is a judgement about who is reading, and nothing in the input encodes it.
• The reorder. Generated output follows the order of the diff. Readers need the order of impact, which means the change affecting how a hundred people work every morning goes first even if it was a twelve-line fix.
• The consequence. A model writes what changed. A reader needs what they now have to do differently, which is a sentence that exists nowhere in the commit history because it was never written down.

Those three edits take about twenty minutes and they are the note. The generation step saves an hour of transcription; it does not produce anything anyone would choose to read.

Who is actually reading these?

Four audiences, with conflicting needs, and the note usually serves one by accident.

Existing users want to know whether anything they rely on moved, and they skim for their own workflow. Evaluators, the people mid-trial deciding whether the product is alive, read the last three releases as evidence of momentum rather than for detail. Support and sales need the line they can paste into a reply to a customer who asked for this three months ago. And the changelog itself becomes a public record that outlives everyone involved, which is the argument Keep a Changelog makes for writing it for humans rather than for a script.

Write for the first audience and the second one is served automatically, because a note clear enough for a user who relies on the product is also clear enough for someone deciding whether to. The support line is worth adding deliberately: one sentence per meaningful change, naming the customer-visible symptom in the words a customer would use. It is the highest-return sentence in the whole document and it is almost never there.

How do you write a breaking change?

At the top, alone, before anything else, with three things in it: what breaks, what the reader has to do, and by when.

Semantic Versioning reserves the major version increment for incompatible changes so the number carries the signal without anyone reading prose. That works for the machines and for the engineers who watch version numbers. It does nothing for the admin who will discover the break on a Tuesday, which is why the note has to say it in words, above the fold, with the deadline attached.

The mistake worth naming: softening it. A breaking change described as an improvement with a migration path still breaks, and the reader who skimmed past the softened version arrives in support with a problem and a sense of having been misled. The plain version costs you a slightly less pleasant paragraph and saves a much less pleasant week.

What about the release nobody will read?

Most of them. A note for a routine release that fixed three bugs and adjusted a default is read by almost nobody, and that is the correct outcome rather than a failure of writing.

The value of shipping it anyway is cumulative. An entry for every release, in a predictable place, on a predictable rhythm, is what makes the archive worth something to the evaluator reading three releases back and to the support agent searching for when a behaviour changed. Skipping the quiet ones breaks the record exactly where it would have been most useful, which is the boring middle nobody was paying attention to at the time.

The honest limitation of the whole workflow: a well-generated, well-edited note cannot rescue a release with nothing in it. If the notes keep reading thin, the problem is the roadmap, and no amount of narrative work at the end fixes something decided a quarter earlier.

When does a change deserve more than a note?

That is a different decision, and it belongs to whoever owns the launch rather than to whoever owns the changelog. A line in the release notes is the default. An announcement, a migration email, a landing page update, or a full launch are escalations, each earned by the size of the behaviour change rather than by the size of the engineering effort. Once the escalation reaches a real launch, it stops being a release note question and becomes a go-to-market one, with its own audience, channel and timing calls that a changelog entry was never built to carry.

Builders Camp's Product Marketing with AI bootcamp teaches that call inside a loop it describes as market, narrative, product, launch, learning, using AI as a copilot for research, positioning and asset creation while keeping the strategy decisions with a person. It runs 1 week across 2 live sessions with 6 self-paced microlessons, and it covers the asset workflows, generating landing pages, emails and enablement material, then editing for accuracy and tone, which is the same generate-then-edit shape this page applies to one artefact.

If the difficulty is the writing itself rather than the launch decision, Product Storytelling covers narrative structure for roadmaps, launches and stakeholder updates across 1 week and 2 live sessions. For a first launch with no audience yet, From Idea to Launch with AI covers the distribution side, where the release note is one small channel among several. See product messaging for the layer above a single note, and ChatGPT for product managers for the general drafting workflow this one specialises.

See the Product Marketing with AI bootcamp

Worth measuring, and almost nobody does: how many support replies quote a line from the notes. If the answer is none after a quarter, the notes are being written for the team rather than for the people the team is writing to, and the fix is in the support sentence rather than in the tone.