An AI changelog generator is the most quietly useful developer tool in the AI category. Release notes are the document every team agrees they should write and every team writes badly. The default approach — dump the git log, group by type, ship — produces a changelog that's technically complete and operationally useless. Users skim it, ignore it, and email support about features that were announced in the changelog they didn't read. A good generator turns the git history into a changelog that actually communicates what changed, in the order users care about.
Skip ahead to the free AI changelog generator if you want the working tool. Below is the framework it builds against.
Three failures dominate. First, the changelog is a list of commits, not a list of changes — "refactor: extract userService" is not a user-facing change, but it gets shipped to users anyway because the changelog is a git mirror. Second, the changelog buries the lead — the one important breaking change is item 14 in a list of 40 dependency bumps. Third, the changelog speaks engineer ("bumped lib X to v2.3.4") instead of user ("the import dialog now handles larger files reliably"). Each one is fixable.
One change. The one your users will care about most. Written as a user-facing outcome, not a feature description. "The dashboard now updates in real time" beats "Added WebSocket support to dashboard." If a release doesn't have a headline change, it might not need a release.
The new capabilities. 3–5 items, each in user-facing language. "You can now bulk-edit invoice tags" beats "Implemented bulkEditTags() endpoint." If a new capability requires more than a sentence, link to the doc.
Improvements to existing capabilities. Performance gains with actual numbers ("CSV exports run 4x faster"), bug fixes that actually mattered, UX polish that changes how the product feels. The generator filters out the "fix: typo in comment" noise.
Anything that requires action from the user. Migration steps, deprecated endpoints with sunset dates, required config changes. This section gets its own visual treatment — users who skim everything else still read this one if it's flagged. The generator surfaces breaking changes regardless of where they fell in the commit history.
Parsing git logs is the easy part. The AI part is the editorial work:
A generator that groups commits is a parser. A generator that rewrites them into user language and surfaces what actually matters is a changelog tool. The AI lives in the editorial pass.
Conventional commits (feat:, fix:, refactor:, chore:, docs:, BREAKING CHANGE:) give the generator structured input to work from. Adopt the convention and the generator's output gets sharper because the noise is pre-filtered. Teams that don't adopt the convention can still use the generator — it does best-effort classification from the commit message — but conventional commits raise the output quality noticeably.
If you can't get the team to adopt conventional commits, the second-best move is squash-merging PRs with a clean title. The PR title becomes the changelog entry and the per-commit noise stays out.
The generator reads the commit history and proposes a version bump based on what it finds. If there's a BREAKING CHANGE marker, it bumps major. If there's a feat, minor. Otherwise, patch. Override the proposal when needed, but the default is usually right.
Changelogs are for the developer audience and live in CHANGELOG.md or the GitHub release. Release notes are for the user audience and live on a marketing page, in a product email, or in an in-app banner. Different format, different tone, different length. The generator produces both from the same input — the changelog format we covered, plus a more conversational release-note version with one paragraph per major item and a call-to-action.
A perfectly formatted changelog that ships once a quarter is worse than a rough changelog that ships weekly. Users build a habit around release cadence. Once a quarter, they stop checking. Once a week, they form a habit and notice what's new. The generator runs on every release, even small ones, because the cadence is the trust signal.
Most products need two changelogs: the internal one (every change, every commit, useful for engineering and customer support) and the external one (curated, user-facing, marketing-grade). The generator produces both from one git history. Treat them as different artifacts, not the same document with different filters.
For SDKs and APIs, the changelog is also the migration document. Breaking changes need:
The generator detects API changes from the commit diff and back-fills these fields automatically when the project is an SDK.
Our free AI changelog generator takes your git history (or a date range), classifies commits, surfaces the headline change, rewrites engineer-speak into user-speak, flags breaking changes, and outputs both a CHANGELOG.md entry and a user-facing release note. Built for teams who would rather ship a changelog users actually read than a wall of refactors.
QADIR OS — local-first AI for the developer lifecycle. Commits, changelogs, release notes, migration guides. Your code stays on your hardware.
Join Early Access →