I Got Tired of Writing Empty Changelogs, So I Built an AI to Do It for Me

I have a confession: I hate writing documentation.

Every time I finished a sprint, the last thing I wanted to do was summarize my commits, translate them into human-readable changelogs, and update the API onboarding guides. So, like most developers, I just... didn't.

But empty changelogs and outdated READMEs are startup killers. If your users don't know what you shipped, they think your product is dead. If a new dev joins your team and can't read the docs, they waste weeks trying to understand your architecture.

I looked for a tool that could just look at my GitHub commits and write the docs for me. When I couldn't find a good one, I spent the last few weeks building it.

How I Automated the Worst Part of Software Development

I wanted a tool that required zero change to my actual workflow.

With Pushpen, you just push your code to GitHub like you always do. That's it.

Behind the scenes, the AI analyzes your commits and file changes. It figures out what features you added, what bugs you squashed, and how the architecture shifted. Then, it automatically drafts the updated README and changelog, and opens a Pull Request for you to review.

It feels like magic. Your docs are always up to date. Every single push.

If you are a startup founder, an open-source maintainer, or a tech lead who is tired of reminding your team to update the wiki — I built this for you.

Why the Changelog Is the First Thing to Rot

Of all the documents a project has, the changelog rots first. The README at least gets a glance when someone sets up the project. The changelog only gets written at release time, under pressure, by someone trying to remember everything that changed since the last version. That is a recipe for "various bug fixes and improvements" — the four words that mean a changelog has given up.

The frustrating part is that all the information needed for a great changelog already exists in your git history. Every commit is a record of something that changed. The problem is purely one of translation: raw commits are written for machines and teammates mid-context, not for the user reading release notes. Closing that gap by hand, every release, is the chore nobody wants. That is exactly the translation an AI is good at — and exactly what I wanted to automate away.

What Makes an Automated Changelog Actually Good

Automating a changelog badly is easy: dump the commit messages into a list and call it a day. That is not a changelog, it is a git log with extra steps. A good automated changelog does three things a raw dump cannot.

First, it categorizes — grouping changes into Added, Fixed, Changed, and Removed so a reader can scan for what matters to them. Second, it translates — turning "refactor token parser" into "Login sessions now persist correctly across restarts," writing from the user's perspective instead of the implementer's. Third, it filters — leaving out the internal refactors, dependency bumps, and test-only changes that belong in git history but not in release notes.

Getting those three right is the difference between a changelog people read and one they ignore. If you want the full breakdown of the format, I wrote a detailed guide on how to write a changelog, and another on writing commit messages that make your changelog write itself.

The Workflow, Step by Step

Here is what actually happens when you connect a repository:

1. Pushpen installs a GitHub webhook that fires on every push — no change to how you work.
2. On each push, it reads the diff and the commit messages to understand what changed.
3. It decides whether the change is worth a changelog entry (a typo fix in a comment is not; a new feature is).
4. It writes the entry in the right category, in language aimed at the reader.
5. It opens a pull request with the updated changelog for you to review and merge.

The pull-request step is the one I refused to compromise on. I did not want a tool that silently rewrites my files. I wanted a draft I could glance at and approve in seconds. That keeps a human in the loop for judgment while removing the human from the tedious part. If you are curious about the plumbing, my guide to GitHub webhooks for documentation explains how the trigger works under the hood.

Want to Try Before Connecting a Repo?

If you are not ready to connect a repository, you can see the core idea right now with the free changelog generator — paste your git log output and watch it become a clean, categorized changelog. There is also a free commit message analyzer that scores how changelog-ready your current commits are, and a README generator if your README needs the same treatment.

These free tools are the manual version of what Pushpen does automatically. Once you have seen the output, the value of having it happen on every push without thinking about it tends to click.

Try It Free

Connect your repo and get automated changelogs on every push.

Start free

Frequently Asked Questions

Can AI really write a useful changelog from my commits?

Yes, if it does more than dump commit messages. A good automated changelog categorizes changes, translates them into reader-facing language, and filters out noise like internal refactors. You can see this on your own history with the free changelog generator.

Does Pushpen commit changelog updates directly to my repository?

No. It always opens a pull request for you to review and merge. Nothing changes in your repository without your approval — the AI drafts, you decide.

Do I need to use conventional commits for this to work?

It helps but is not required. Clean, conventional commits produce cleaner entries, but the AI can infer intent from messier history too. The free commit message analyzer tells you how changelog-ready your commits currently are.

What if a push does not warrant a changelog entry?

The system decides per push. A typo fix in a comment or a test-only change will not produce an entry, while a new feature or user-facing fix will. The goal is a changelog that reflects meaningful change, not every commit.

How is this different from writing the changelog at release time?

Release-time writing relies on someone remembering everything since the last version, which is where entries get missed. Generating entries continuously as work merges means the changelog is always release-ready. See generating a changelog from git commits for the full approach.