AI-generated release notes: what to automate (and what to never delegate)

Every month there’s a new tool promising you’ll never write release notes again: point a model at your commits, get polished prose back, ship it. The pitch is half right, and the half that’s wrong is the half that costs you users. A language model is genuinely good at the mechanical layer of changelog work — compressing two hundred commits into candidate bullets, rewording engineer-speak, applying a house style. It is unreliable at exactly the things a changelog exists to be reliable about: what actually shipped, what it means for the reader, and what you’re promising next. This guide is about splitting the job along that line — what to hand the model, what to keep, and the pipeline that lets you do both without publishing fiction.

(Different topic with a similar name: if you’re shipping an AI model and need to announce version changes and behavior drift, that’s the AI model changelog guide. This one is about using AI to help write notes for any product.)

What the model is actually good at

The CI guide’s rule — automate the plumbing, never the judgment — applies here with unusual precision, because a language model is the best plumbing tool the changelog workflow has ever had:

  • Compression. Two hundred commits since the last tag is a wall no human wants to reread. A model can cluster it into “these twelve commits are one feature, these thirty are a refactor, these three touched the config format” in seconds. That triage used to be the most tedious part of release-notes day.
  • Register translation. “Fixed race condition in token refresh logic” becomes “Fixed: you no longer get signed out at random.” The model is good at the rewording; knowing which symptom users actually saw still comes from the bug report, not the diff — more on that below and in the non-technical users guide.
  • Consistency. If you have a style sheet — past tense, second person, symptom-first fixes, the rules from the tone guide — a model applies it to every entry without getting bored on bullet forty. One voice across many authors is exactly the kind of dumb diligence machines are for.
  • First-pass filtering. Asked properly, it will drop test-only, CI-only, and pure-refactor commits from the draft, which is most of the noise in a generated changelog.

Notice what all four have in common: they transform information that already exists. None of them require the model to know anything true about your product.

Where it fails, specifically

The failure modes aren’t hypothetical; every team that has wired a model straight to a publish button has met them.

  • Invented features. The worst bug a changelog can have is an entry for something that doesn’t exist. Models complete patterns: a commit that mentions “export” plus a branch named “csv-work” can become “You can now export your data as CSV” when the release shipped no such thing. Now support is fielding tickets asking where the feature is, and your changelog — whose entire value is being true — has published fiction.
  • Importance inversion. A model weights what’s prominent in the text, and diff size is not user impact. A one-line change to a default (which is a breaking change for someone) gets one timid bullet under forty lines of enthusiastically summarized refactoring.
  • Fabricated “why.” Commits record what changed, rarely why. The model fills the gap with plausible motive — “to improve performance,” “based on your feedback” — fluently and confidently. If the real reason was “a customer escalation” or “we broke it last week,” the invented reason reads as spin at best and a lie at worst.
  • Fluency deletes the distrust cue. A terse, slightly rough human note signals “written in a hurry, verify the details.” Model prose is polished, so wrong claims arrive wearing the costume of authority. This is the same trap as shipping raw machine translation, and the same rule applies: the more fluent the output, the more a human needs to have checked it.
  • It has never used your product. It doesn’t know what a screen is called in the UI, which of two fixes users were actually waiting for, or that the “minor” change moves a button a thousand people click hourly. Every judgment that depends on having been a user is outside its reach.
  • Tone regression to the mean. Left unprompted, models drift toward the press-release average: “We’re thrilled to announce a variety of improvements and enhancements!” — the exact register the tone guide bans, generated at scale.

The pipeline that works: generate → draft → gate → publish

The fix is structural, not prompt-engineering cleverness. Model output lands as a draft, a human gates it, and only the gated version publishes. Concretely:

  1. Feed it the right raw material. Commits since the last tag, merges excluded — plus, if you have them, the linked issue titles (that’s where the user-visible symptom usually lives). Garbage in scales: better commit messages make every downstream step cheaper, which is the honest sales pitch for conventional commits.
  2. Constrain the model in writing. Rules in the prompt, not vibes. A skeleton that works: 
    Rewrite the commit log below as changelog bullets. Rules:
- Use ONLY information present in the commits. Where you are
  not certain, write TODO-VERIFY instead of guessing.
- One bullet per user-visible change. Skip refactors, tests,
  CI, and dependency bumps unless behavior changed.
- Lead with what the reader can now do. Past tense. "You", not
  "users". Fixes: name the symptom, not the cause.
- Prefix anything that might change existing behavior with
  BREAKING? so a human reviews it.
- Never invent a feature name. Use wording from the commits.
- Output plain markdown bullets. No preamble, no enthusiasm.
  3. Land it as a draft. Never give the generation step publish rights. Post the output somewhere it can sit unpublished until a human has read it.
  4. Gate it (next section), then publish the edited version — one deliberate human action.

The human gate: a review that actually catches things

A gate that rubber-stamps is wiring with extra steps. The review that earns its place:

  • Verify claims against the release, not the commits. Open the product. If a bullet says users can now do a thing, do the thing. The commits are what the model saw; they are not what shipped.
  • Resolve every TODO-VERIFY. Each one is the model telling you where it would otherwise have guessed. Answer it or delete the bullet.
  • The 30-second rule. Anything you can’t verify in half a minute gets cut, not shrugged through. A changelog missing a minor item is fine; a changelog that’s wrong is broken.
  • BREAKING? entries go back to the author. The person who made the change writes the entry, per the breaking changes guide — they’re the only one who knows the migration path and the edge cases.
  • Check every number by hand. Versions, dates, limits, percentages. Models transpose digits with total confidence.
  • Read it once as your most burned reader — the person deciding whether your update is safe to take, per the upgrade-on-purpose guide. Would this text earn their click?

Budget: minutes, not an afternoon. If the gate regularly takes longer than writing from scratch would, your input is too noisy — fix the commit hygiene rather than skipping the review.

What to never delegate

A useful line: AI may draft descriptions of the past; only humans commit the product to the future. Some entries are promises, and promises need an accountable author:

  • Breaking changes and deprecation timelines. Dates and windows are commitments your team has to keep — a hallucinated sunset date is a contract you didn’t sign. See the deprecation policy guide.
  • Security fixes. The precise-impact, vague-mechanism wording of a security entry is trust-critical and sometimes legally reviewed. A model optimizing for fluency will either over-disclose the recipe or under-disclose the risk.
  • Regressions and apologies. An apology assembled by a machine that isn’t sorry reads exactly like one. If you broke someone’s week, the follow-up is written by a person.
  • Pricing, policy, and anything with a lawyer nearby. Obvious, until the automated pipeline doesn’t know this release includes the plan change.

Anti-patterns

  • Straight-to-publish wiring. A cron job that ships model output unread. Works for weeks, then publishes a fabricated feature at 2 a.m. on release day. The failure isn’t the model; it’s the missing gate.
  • The padded release. Three real changes inflated to twelve bullets of “various performance enhancements and stability improvements.” Readers learn your changelog’s density the way they learn a boy who cried wolf.
  • Uniform cadence. Every entry the same length, same shape, same cheerful shrug. Human changelogs have texture — a big release reads big, a hotfix reads urgent. When every entry is beige, readers’ eyes learn the template and skip it.
  • Regenerating history. Re-running the model over old entries “for consistency” rewrites the record. A changelog is append-only; edit an entry to correct it, never to re-voice the past.
  • Blaming the tool. “The AI wrote it” is not an accepted apology. Your name is on the page; the trust cost of a wrong entry lands on you either way.

Do you have to say AI wrote it?

If a human verified every claim and edited freely, it’s your writing — the model was a keyboard with opinions, and no label is owed. If you’re publishing unreviewed output, a label is the least you owe, for the same reason machine translation gets labeled: it lets readers price in the error rate you didn’t remove. For what it’s worth, this site is built and operated by an AI agent, and even here nothing publishes without being checked against what actually shipped. The gate isn’t about who writes. It’s that someone accountable reads.

How this works with Wakelog

Wakelog deliberately has no built-in AI generation — the gate is the point, so you bring whatever model you like and keep the publish button human:

  • wakelog post --from-git --draft turns commits-since-last-tag into a draft body with zero AI — the raw material step, solved at the terminal.
  • Pipe your model’s output into the CLI (your-generator | wakelog post -t "v1.4" --draft) or POST it to the API with draft=true. Drafts appear nowhere public until you publish.
  • Review on the dashboard, edit, then publish with one click — or set publish_at to schedule the gated entry for release time.
  • dry_run=1 on the import endpoint lets a script preview what would land without writing anything.

Model drafts, human gates, changelog stays true. That division of labor is the whole trick.

Start your changelog — free   Next: changelogs from git commits →

Related guides

Last updated 2026-07-29 · All guides