Can AI write release notes? An honest look at what works and what doesn't

So, can AI actually write release notes?

Short version: it can write the draft, and it's surprisingly good at it. The longer version is the interesting one.

I write a lot of eesel's content with AI in the loop, and I also sit close enough to our support side to see what happens the week after a product ships. There's a pattern. A team pushes a genuinely good release, then the "wait, where did this button go?" and "did you change how X works?" tickets start landing, because the release note was either a wall of fix: null check commit messages or it never got written at all. Release notes are the cheapest support deflection you'll ever write, and they're the first thing that gets skipped under deadline. That's exactly the gap AI is good at closing.

But "can it" and "should you trust it unsupervised" are different questions. The most useful thing I read while putting this together wasn't a vendor page, it was a January 2026 Ask HN thread on automating release notes, where actual engineers fought it out. That debate maps the whole territory, so I'll lean on it.

"AI release notes" means three different things

When people ask whether AI can write release notes, they're usually picturing one workflow. There are really three, and they sit on a spectrum from "barely AI" to "fully written by a model".

1. Template assembly. This is the cheapest and most common, and it's only loosely "AI". GitHub's automatically generated release notes pull a list of merged pull requests, a contributor list, and a link to the full changelog, with categories driven by PR labels in a release.yml file. Note what it reads: merged pull requests, not commits. Direct commits to the default branch don't show up. It's deterministic assembly, not a model writing prose, which makes it reliable and also a little flat.

2. LLM from source. Here a model reads your structured signal and writes the entry. Linear's AI does this from issues: its docs describe using a "Linear agent to analyze the set of issues included in a particular release" and generate notes on a template each time a release hits production. A wave of smaller tools do the same from commits and PRs, the Show HN launches all describe the same shape, "connect GitHub, AI generates, share with customers".

3. Full AI content writer. This is treating the release note like any other piece of content: you hand a general-purpose AI content writer the raw material plus your brand voice and let it produce a polished, customer-facing post. It's the same category as the AI writing tools you'd use for a blog. More control over tone, more room to get the voice wrong, and the closest to how you'd run a content pipeline for blog posts.

Most teams should start at level 1 or 2 and only reach for level 3 when release notes are a real marketing surface. If you want the full mechanical walkthrough of each, the companion AI release notes generator guide goes deeper on the tooling.

Where AI genuinely shines

Let me be generous first, because the upside is real and the skeptics on Hacker News undersold it a bit.

Grouping and formatting. Sorting thirty merged PRs into Added, Fixed, Changed, and Security is dull, mechanical work that a model does instantly and consistently. This is the single biggest time win, and it's the least risky.

Translating jargon into a benefit. A good model turns "patched race condition in webhook retry queue" into "fixed an issue where some webhooks could fire twice". That's a genuine skill, and it's the same muscle as a technical blog writer rewriting engineering-speak for a wider reader.

Throughput. One builder posting a Show HN on a GenAI release-notes tool reported it "reduced the time taken for generating release notes by approximately 70% for our product's release management team at Microsoft." That's self-reported by the maker, not an independent benchmark, so treat it as a practitioner data point rather than gospel, but the direction is right: the drudge work compresses hard.

This is also where the build-versus-buy question shows up. You could wire up your own script against the OpenAI or Anthropic API, and plenty of the Show HN tools are exactly that. But as one eesel customer, Karel at GENERAL BYTES, put it about a different AI build:

We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain.

That instinct is usually right. A weekend script to summarize commits is fun; maintaining it across model changes, rate limits, and edge cases is a job.

Where it quietly falls down

Now the honest part, and this is where the Hacker News crowd earned their keep.

Commit messages are not customer copy. The sharpest objection came from weinzierl:

The commit messages are a private space where developers communicate. The messages should never end up at the customer without thorough filtering and distillation.

This is the core risk. Point an AI at raw commits and you don't just get noise, you risk leaking an internal project name, an embarrassing bug description, or a security detail you didn't mean to publish. The safe input is always the curated layer (a pull request, a linked issue), never the raw diff.

Garbage in, garbage out, but louder. nitwit005 ran fully automated notes from git tags and found them "unfortunately useless as people don't actually add the right tags on things, so everyone ends up manually editing it." Automation amplifies whatever discipline you already have. If your PR descriptions are one-word stubs, AI gives you polished one-word stubs.

It doesn't know what to leave out. A long-time skeptic, insin, put the verdict plainly:

I've never seen an auto-generated set of release notes I liked, a list of PRs doesn't cut it.

Editing is mostly subtraction: knowing that the internal refactor and the dependency bump don't belong on a customer page, while the small UI change everyone will notice does. That judgement is the thing the model can't reliably make for you yet. The same content editing discipline applies to any AI draft.

There was even a clean one-liner from ok1984 for the fully-automated dream: "automating release notes is like recording an audio and play it each time you introduce your kid to somebody." Some communication is supposed to be human.

The workflow that actually works: generate, then curate

So the move isn't "AI writes release notes" or "humans write release notes". It's a relay. The most credible operator in that thread, richard_obrien (who disclosed he runs a release-notes tool), summed up the precondition:

The teams that have the most success with automation of this process treat GitHub PRs or Jira, Azure DevOps, Linear, GitHub issues as the source of truth. Also their issues/PR descriptions tend to clearly describe the problem and the solution.

Here's the loop that follows from that.

1. Fix the source first. Write PR and issue descriptions like the customer will read them, because increasingly they will. This is the unglamorous step that decides everything downstream.
2. Let AI draft by type. Feed merged PRs (not commits) to the model and have it group into Added, Fixed, Changed, Security. This is the 70%-time-saving step.
3. Cut and add the why. A human deletes the internal noise and adds the one line of context the model can't know: why this matters to the user, what to do about it. This is where the voice of a good writer earns its place.
4. Publish where people look. Ship the note to your changelog and your help center, not just a git tag.

You own steps 1, 3, and 4. AI owns step 2. Get that division right and you keep the speed without the risk. If you're scaling this across many releases, it starts to look like any other content production pipeline, and the same tools that automate content creation apply.

The half everyone forgets: release notes are a support channel

Here's the part that turns a nice-to-have into actual ROI, and it's the reason I care about this from the support side.

A release note isn't really a document, it's an answer to a question your customers are about to ask: "what changed, and do I need to do anything?" If they can't find the note, they ask your support team instead. That's the ticket spike I see after every release that shipped without good notes.

So the last step in the loop above (publish where people look) is the one that pays. When your release notes live in your help center and your knowledge base, two good things happen at once.

First, customers self-serve, which is the whole point. Second, and this is the part that's easy to miss, your notes become training data for your AI support agent. An agent that has read your latest release note can answer "is the new export feature live?" without a human touching it. Notes that sit in a CHANGELOG.md nobody links to do nothing for support deflection.

This is the same reason keeping help content current matters: an AI support agent is only as good as the freshest thing it has read, and release notes are the freshest signal you produce. It's also why release notes belong in your broader knowledge management setup, not in a silo, and why an AI documentation assistant is worth pointing at them.

Try eesel

I'll be straight about where eesel fits, because it isn't a dedicated release-notes generator and I won't pretend it is. Two things it does do well around this problem.

One, eesel's AI content writer can take your shipped work and draft the customer-facing version, the same level-3 workflow above, with your voice and your sources. Two, and more importantly, once those notes are published, eesel connects to your help center and past tickets so its AI support agent answers the "what changed?" questions for you. We've spent years putting AI agents on live support queues, and we simulate every rollout against your historical tickets before it goes live, so you can see exactly which release questions it'll handle before it answers a single customer.

If the release note is the answer, eesel makes sure the question never reaches a human. It's free to try, and you can point it at your existing knowledge base in a few minutes to see what it deflects.