I spent forty-five minutes last Tuesday staring at a git log, manually filtering out "fix typo" and "update deps" to write a changelog for a minor patch. It’s a task we all hate: it’s low-signal, high-friction, and it eats into the time we actually want to spend building features. We tend to accept this friction as the tax of shipping software, but it doesn’t have to be.
The core problem isn’t just that writing release notes is tedious; it’s that most tools solve it by adding more complexity. You usually have to pipe your commits into a CLI script, pay for a cloud API call, or trust a SaaS platform with your repository’s history. For many teams, especially those handling sensitive codebases, sending raw commit data to a third-party server is a non-starter.
I built ChangelogPro to remove that middleman entirely.
The wedge here isn’t just "AI writing copy." It’s that the entire process happens locally on your machine. There is no server-side processing of your text. When you paste your raw commit messages, they never leave your browser. The tool leverages a private on-device AI model that runs via WebGPU. This means if you kill your internet connection after the initial load, it still works. Your data stays in your RAM, not in a cloud provider’s database.
The workflow is designed to fit into the moments between commits and PR merges. You open the tool, paste your git log output or your raw markdown list of changes, and hit generate.
Because the model runs in-browser, the latency is surprisingly low for the amount of processing happening. It’s not instant like a simple regex replace, but it’s fast enough that you don’t have to context-switch away from your IDE. You can draft, edit, and refine the notes in a single session.
Here is what the input/output flow looks like in practice. You provide the noise:
- fix: handle null pointer in user profile
- chore: update eslint config
- feat: add dark mode toggle
- fix: correct typo in README
- refactor: simplify auth middleware
And the on-device model synthesizes the signal:
### New Features
- Added a dark mode toggle for improved accessibility and user preference.
### Improvements & Fixes
- Resolved a null pointer exception in the user profile module.
- Simplified the authentication middleware for better maintainability.
- Corrected documentation typos in the README.
The value isn’t just in the summary; it’s in the categorization. The model understands that "update eslint config" is internal housekeeping and can optionally exclude it, or group it under a "Chores" section, while "add dark mode toggle" is a user-facing feature. This distinction is usually where manual curation becomes painful.
Using WebGPU for inference in the browser is still a relatively new capability for general-purpose apps. Most browser-based AI tools still rely on sending requests to remote APIs. That model works for chatbots, but for a utility like changelog generation, it introduces latency, cost, and privacy concerns.
By running the inference locally, we sidestep the rate limits and API costs associated with cloud models. It also means the tool is offline-first. If you’re working on a plane, or in a coffee shop with spotty Wi-Fi, you can still generate your release notes. The computational load is handled by your local GPU (or CPU if GPU acceleration isn’t available), making it a true desktop experience wrapped in a browser interface.
There is a trade-off, of course. Local inference requires a modern browser and a reasonably capable machine. It’s not designed for low-end devices from five years ago. But for most developers working on laptops from the last few generations, the performance is seamless. The model is small enough to load quickly without bogging down your system, yet capable enough to understand the nuances of technical commit messages.
ChangelogPro is a paid tool, as building and maintaining local AI infrastructure requires resources. However, it comes with a 7-day trial so you can test the workflow with your actual project history before committing. If you’re just curious about how the local AI handles your specific commit style, the trial is the best way to see if the friction reduction is worth it for your team’s cadence.
We often treat release notes as an afterthought, something to be done "when we have time." But that time rarely exists. I’ve found that automating the drafting phase allows me to focus on the narrative of the release rather than the extraction of the data.
How do you currently handle release notes? Do you use automated tools, or is it still a manual copy-paste ritual for you? I’d be curious to hear if the privacy aspect of local-only processing is a dealbreaker or a dealmaker for your workflow.