# AI release notes — what they are, how the good ones work, and how to pick one A practical guide to AI-drafted release notes — where the AI actually adds leverage, the three places it can plug into your release pipeline, and how to evaluate a tool against your own workflow. An AI release notes tool drafts customer-facing changelog entries from your codebase rather than from a blank editor. The strongest tools work upstream — they read merged pull requests, branch diffs, or release-tag comparisons and produce categorized entries you review and ship. Editor-side AI that polishes already-written prose is the weaker mode. Herald uses three source modes (PR range, branch diff, release tag diff) and publishes back to GitHub Releases. Published: May 2026 Last reviewed: 2026-05-28 Author: Herald Team Category: AI & Automation Read time: 11 min read Tags: AI release notes, AI changelog, GitHub, Release automation ## What "AI release notes" actually means in 2026 The phrase "AI release notes" has two very different products hiding inside it, and the difference matters more than the marketing usually admits. The version most tools ship is **editor-side AI**: a button inside a rich-text editor that takes prose you've already typed and rewrites it — shorter, friendlier, with consistent tense, occasionally with a generated headline. It's useful for polishing. It does not save you the work of writing release notes from scratch, because the prose has to exist before the AI can rewrite it. The leveraged version is **source-side AI**: the AI reads your code history — merged pull requests, branch diffs, release tags — and drafts the release entries themselves. The blank-page problem disappears. The work that gets reduced isn't editing-time, it's the much larger pile of "look through 30 PRs, decide what matters to customers, write a sentence for each one, organize by category" work that lives upstream of the editor. If you take one thing from this guide: when someone says "AI release notes," ask which mode they mean. They are not interchangeable. ## Source-side AI vs editor-side AI Both modes are real, both have a place, and the leveraged version is the source-side one. **Editor-side AI** is what most changelog and product-comms tools have added since 2023. You write your entry in the editor, hit a button, and the model rewrites it — tone adjustment, grammar pass, headline suggestion, maybe a length-trim. The interaction surface is the editor. The input is your prose. The output is better prose. **Source-side AI** sits one step earlier in the pipeline. The input isn't your prose — it's your repository. The model reads the diff between two points in your code history (two branches, two release tags, or a range of merged PRs) and writes the release entries themselves. The editor is where you review and refine, not where you start. The difference shows up in three places: - **Where the blank page sits.** Editor-side AI inherits a blank editor and asks you to fill it. Source-side AI hands you a draft and asks you to refine it. - **What gets automated.** Editor-side AI automates *editing*. Source-side AI automates *triage and first-pass writing*. - **What you have to know.** Editor-side AI needs you to already know what changed. Source-side AI tells you what changed, then lets you decide what makes the customer-facing cut. Editor-side AI is a nice-to-have on a tool whose primary job is hosting and distribution. Source-side AI is the one that meaningfully changes how long a release takes to write. ## Where AI fits in a release pipeline A typical SaaS release goes through four stages, and AI can plug in at each one differently. **Stage 1: Source extraction.** Pull the raw record of what changed. Merged PRs, branch-to-branch diffs, release-tag-to-release-tag diffs, commit logs. This stage is mostly mechanical — there's no judgment yet, just gathering the source data. AI's role here is parsing and filtering: stripping commit noise, recognizing dependency bumps, grouping related PRs. **Stage 2: Triage and translation.** Decide what belongs in the customer-facing release. Translate engineer-language into user-language. ("Refactor the auth middleware" → cut. "Fixed a bug where invoice PDFs occasionally rendered with the wrong logo" → keep, and write it that way.) This is where source-side AI earns its keep — it does the first-pass cut and the first-pass rewrite from PR titles and bodies. **Stage 3: Authoring and polish.** Reorder, edit, add the human context the AI didn't have ("This was the most-requested fix from our enterprise customers this quarter"), drop anything that shouldn't ship, write the headline. Editor-side AI helps here, lightly — tone passes, length trims, headline alternatives. **Stage 4: Distribution.** Publish to the hosted page, send subscriber email, push to the in-app widget, sync back to GitHub Releases if that's part of your loop. AI doesn't add much at this stage — distribution is a plumbing problem, not a language problem. The unit-economics question for any AI release-notes feature is which stages it actually automates. A tool that only touches stage 3 is editor-side AI. A tool that touches stage 1 *and* 2 *and* hands a real draft into stage 3 is source-side AI. The two products do different amounts of work for you. ## The three source modes If you accept that source-side AI is the leveraged mode, the next question is: where does the AI read from? There are three useful answers. **1. Merged PRs in a time range.** "Show me everything that landed in main since the last release." This is the natural fit for teams that release on a cadence (every Tuesday, every other Friday) and treat the release as "everything we shipped in the last sprint." It's also the most forgiving source — PR titles and bodies usually carry enough context for the AI to draft a customer-facing summary, especially if your team writes informative PR descriptions. **2. Branch-to-branch diff.** "Compare `main` against `production` (or `release-candidate` against `production`)." This fits teams with a staging/promotion model where you release by merging a release branch into production. The diff between the two branches is your release. The AI drafts from the commits and PRs that are in one but not the other. **3. Release tag to release tag.** "Compare v2.3.0 against v2.2.0." This fits teams that cut semver-style tags. You pick two tags, the AI drafts the release from everything between them. This is also the mode that maps most directly onto what GitHub's built-in "Generate release notes" button does — except the AI does more than concatenate PR titles. Most changelog tools that have AI features support at most one of these — usually the first, often called something like "AI from PR history." Herald supports all three, on the same release editor, with the source mode selectable per release. The reason for offering all three is that different teams release in different shapes, and forcing a team that releases by branch-promotion to retrofit a "merged PRs since date" workflow tends to produce drafts that miss things or include things that didn't actually ship. ## What a good AI-drafted release note looks like A useful test for any AI release-notes tool: feed it a week of your real merged PRs, look at the draft it produces, and check three things. **Did it group correctly?** Good drafts come back grouped by category — usually some combination of New Features, Improvements, Fixes, Breaking Changes, Deprecations. If everything lands in one undifferentiated bullet list, the AI is doing summarization but not triage, and you're going to do the grouping work yourself anyway. **Did it translate the audience shift?** A good draft sounds like the product team wrote it for users. "We refactored the cron scheduling layer for better reliability under load" — translated, not preserved as "Migrated `JobScheduler` from polling to event-driven dispatch." If you can drop the AI's draft into your changelog with light edits and it reads like product communication, the tool is doing source-to-user translation. If every entry needs a full rewrite, the tool is just renaming PR titles. **Did it know what to drop?** Internal refactors, dependency bumps, CI fixes, tests-only changes — most of these should not be in a customer-facing release. A good draft drops them automatically (or surfaces them in a separate "Internal" bucket you can choose to publish or not). A draft that includes "Update eslint to 9.18.1" alongside "New dashboard analytics view" is doing extraction but not curation. If a tool fails any of those three on your real history, the AI is at best saving you typing — not saving you the actual work. ## When not to use AI for release notes AI-drafted release notes are not always the right tool. Three cases where the human-written version is still the better default. **Major launches.** A new product, a major version bump, a feature you've been pre-marketing for weeks — these need marketing-quality copy, ordered by importance to *customers*, with framing that connects to the broader narrative you're telling. The AI doesn't know what the broader narrative is. Write the launch entry by hand; let AI handle the small stuff alongside it. **Security disclosures.** A CVE-class fix, a credential leak postmortem, anything where the legal team needs to sign off on phrasing — write it by hand and have it reviewed. AI's tendency to soften, paraphrase, or hallucinate context is exactly wrong for security communication. **Breaking changes that need explicit migration guidance.** "We renamed the `accountId` field to `workspaceId`" is one sentence. "Here's how to migrate your existing integrations, here's the deprecation timeline, here's the compatibility shim we're shipping for the transition period" is a structured document. AI can draft the one-line summary; humans should write the migration guidance. The pattern: AI is good for the long tail of small-to-medium changes that would otherwise eat a half-day every cycle. Reserve human time for the small number of releases where the writing is itself part of the value. ## How to evaluate an AI release-notes tool If you're shopping for one, a short checklist that separates source-side AI from editor-side AI: - **Does it read from your repository, or only from your editor?** If the AI input is a textarea, it's editor-side. - **How many source modes does it support?** One (usually merged PRs) is the minimum useful answer. Three (PR range, branch diff, tag diff) covers most release workflows. - **What does the draft look like for a real week of your history?** Don't evaluate on the marketing demo; connect it to a real repo and look at a real draft. - **Does it group into categories, or hand you a flat list?** - **Does it know what to drop?** Test it on a week where you had real refactors and dependency bumps. See whether they make the cut. - **Can you cherry-pick PRs manually when you want full control?** Source-side AI shouldn't be all-or-nothing. - **Does the release publish back to your engineering surfaces (e.g., GitHub Releases), or only to the customer-facing changelog?** Bidirectional integration matters for teams that maintain both audiences. - **What's the pricing model?** Per-seat tools penalize teams that want to give everyone access; flat per-project pricing scales better as your team grows. The two most important questions on that list are "does it read your repository" and "what does a real draft look like." Everything else is a refinement. ## How Herald does it Herald is built around source-side AI as the default workflow. Open a new release in the editor, pick a source mode, and the AI drafts the entry before you write a word. The three source modes live behind a single picker, called YOLO mode internally: - **Merged PRs since [date or last release]** — for cadence-based release teams. - **Compare branches** — pick a base and head branch, draft from what's in head but not base. - **Compare releases (or tags)** — pick two existing releases or two git tags, draft from the diff. The draft comes back categorized — New Features, Improvements, Fixes, Breaking Changes — with each entry rewritten from the PR title and body into customer-facing prose. Internal-only changes (refactors, CI, dependency bumps that aren't user-visible) get filtered to a separate bucket you can keep or drop. You then review in the editor. Reorder, rewrite anything that needs more product context, drop entries that don't belong, add the human framing the AI didn't have. When you publish, the same release lands on your hosted changelog page, in the in-app widget, in subscriber email, and — if you have the GitHub integration enabled on Team+ — back on your GitHub Releases page too, so your engineering audience and your customer audience stay in sync from one publish action. If you want full manual control on a given release, the same editor lets you cherry-pick individual PRs or commits without using the AI at all. The source-side AI is a default, not a requirement. Two things make this approach different from most of the changelog category: - **Three source modes, not one.** PR range, branch diff, tag diff — selectable per release. Different teams release in different shapes, and the source mode should match the shape. - **Bidirectional GitHub on Team+.** The same integration that reads your PRs to draft the customer changelog also publishes the finished release back to GitHub Releases. One source of truth, two surfaces — without copy-pasting between them. --- Ready to see what your last 30 days of merged PRs look like as a drafted changelog? [Start a 14-day Herald trial](https://app.sendherald.com/sign_up) with full Team features, no credit card. Connect your repo, pick a source mode, and see the draft Herald produces before deciding whether it's the right shape for your team. Next guide: [Herald and GitHub Releases — when to use each, and why most teams need both](/guides/herald-and-github-releases/)