Our CHANGELOG.md was last updated three releases ago. Not because we stopped shipping, but because writing the notes always happened at the worst possible moment: at release time, when I was trying to remember everything that had landed since the last tag. Reconstructing two weeks of work from memory produces a vague paragraph and a few missed fixes, and then the next release is even harder because now the previous one is undocumented too.
The information was never missing. It was in the commits and the pull requests the whole time. The problem was that git log is a developer artefact and a changelog is a user-facing one, and nobody wanted to do the translation at 6pm on a Friday.
The changelog dies at release time
A manual changelog has a structural flaw: the cost is paid by whoever ships, and the benefit goes to whoever reads. That asymmetry is why it rots. The person cutting the release has the least time and the most context fade, and the reader, who would notice a missing breaking change, is not in the room.
I wanted the reverse: notes generated continuously from what actually landed, so that at release time I am editing a draft rather than composing one from memory. Auto-tracking commits and PRs means the raw material accumulates on its own. AI-written release notes turn fix: handle null in retry into a sentence a customer can understand. Publish-ready changelog pages mean the output is a page I can put on the site, not a text file I still have to format.
AI Changelog is built for that flow: connect your repo, and it tracks commits and PRs to generate release notes, with GitHub integration and publish-ready changelog pages. "Publish-ready" is worth reading carefully. It means the page is ready for you to publish, not that the tool publishes it for you. The last click is still mine.
Why connecting the repo is worth the trade-off
I added it here because the alternative is worse. A paste-first changelog tool would ask me, every release, to remember to copy the commit range. That is the exact step the manual process already fails at. The one thing that makes this problem solvable is removing the copy-paste, and removing the copy-paste requires reading the repo. So the trade is: accept a scoped integration, in exchange for a draft that exists before I go looking for it.
The honest framing is that this is a convenience with a cost, not free. If your team cannot grant repo read access, this is the wrong tool for you, and that is a legitimate answer. For a small team shipping often, the scoped read is cheaper than an eternally stale changelog. I keep the permission narrow and I review the generated notes before they go anywhere near a release page.
Vague commits produce vague notes
Here is the limit I wish someone had told me earlier. Generated release notes are only as good as the commit messages they come from. If the log says "stuff", "wip", "fix", and "as discussed", no tool can recover the intent that was never written down. I have seen a whole week of work collapse into "Various improvements" because that is genuinely all the source said.
This is not a failure of the generator; it is an upstream discipline problem, and connecting a repo makes it visible rather than fixing it. The tool can group and phrase what landed, but it cannot know that a one-line commit quietly changed a default that some users depend on. That is the sentence a human has to add.
So I treat the output as a first draft and decision-support for release notes, not a live audit of the release, a certification that nothing breaking shipped, or a sign-off. Before publishing I still read for the things a commit message cannot express: a breaking change, a migration step, a deprecation, a security-relevant fix that should not be described in detail. I also check that an internal ticket ID or a half-finished feature has not leaked into customer-facing prose.
If your CHANGELOG.md is a museum of good intentions, connecting AI Changelog at least means the next release starts from a draft instead of a blank file. Then do the part it cannot: decide what the notes are allowed to say.
FAQ
Does it publish the changelog for me?
No. It produces publish-ready changelog pages from tracked commits and PRs. The publish step and the release sign-off are yours.
Does connecting the repo mean it can change my code?
The integration is for tracking commits and PRs to generate notes. It does not write code or choose version numbers, and the permission should be scoped to read.
Will vague commit messages still produce good notes?
No. The notes reflect the source material. If the log is vague, the draft will be too, and a human needs to add the intent that was never written down.
Top comments (0)