An AI writes my changelogs now
# An AI writes my changelogs now
Every project I maintain has a file that almost never gets kept up to date. The changelog is supposed to be the human readable story of what changed and when: a new feature here, a bug fixed there, this part got faster. Writing it is a chore that arrives at the worst possible moment, right after the actual work is finished and I am tired. So the file rots, or it never gets written at all.
That bothered me for years, because a good changelog is one of the few pieces of documentation people actually read. So I handed the job to a model. It turned out to be one of the cleanest small automations I run, and it is a tidy case study in the kind of work this technology is actually suited for.
The raw record and the readable story
Some background for anyone outside software. Every change you make to a project gets recorded automatically, and each record carries a short note from whoever made it. Fixed the login button. Sped up search. Added dark mode. Over months you accumulate hundreds of these notes, and together they form a complete, honest history of the project.
The trouble is the audience. Those notes are written in shorthand, out of order, full of abbreviations that mean something to me on the day and nothing to anyone else ever. A changelog is the same history cleaned up, grouped, and rewritten so a normal person can read it and understand what is new.
The gap between the two is pure translation. All the information already exists, sitting in the pile. Nothing needs to be invented and no decision needs to be made. The job is rewriting a record from one register, cramped and technical, into another, clear and friendly. Patient reshaping of words that already exist happens to be the one task a language model never gets tired of.
Why this task fits the tool so well
I want to dwell on the fit, because it generalizes. The tasks where AI reliably earns its keep share a recognizable shape. The input is clear and already exists. The work itself is repetitive translation or cleanup rather than judgment. And a slightly wrong output costs little, because a person reviews it before it matters.
A changelog matches that shape almost perfectly. The pile of notes is sitting right there. Turning shorthand into plain English is the most natural operation a language model performs. And an awkwardly phrased line ruins nobody's day, since I read the draft before it ships.
Compare that with asking a model to make a major architectural decision, where the input is fuzzy, the work needs real judgment, and a wrong answer is expensive. I have watched people get burned by exactly that mismatch: they hand the model the big fuzzy call, receive a confident and plausible wrong answer, and blame the tool. Sorting your own work into the clean pile and the fuzzy pile is most of the skill in using AI well. The changelog sits firmly in the clean pile, which is why it works so reliably.
What I hand it and what I ask for
The mechanics are almost embarrassingly simple. When a release is ready, I gather every change note since the last one. It is a long, messy list. Some notes are clear. Many are the kind of cryptic half thought I typed at eleven at night, which even I struggle to decode a week later.
I hand the entire list to the model in one go with a plain instruction: read these raw notes, work out what actually changed for a real person, group the related ones, and write a clean summary an ordinary human would understand. That is more or less the whole request. The model has seen a million changelogs in its training and knows the shape of the thing being asked for.
What comes back
The output is the satisfying part. First it groups: five scattered notes that were all really about one new feature collapse into a single clear line. Then it translates, turning my shorthand into sentences a person can read. Then it orders the result, with the changes people will care about at the top and the tiny housekeeping fixes at the bottom where they belong, each line sorted into the obvious sections so a reader can scan for what is new or what got fixed.
A document that would have taken me a slow half hour lands in a few seconds. The first time it worked I laughed out loud, because the draft was better than what I usually produce by hand.
There is a real reason for that, and it matters more than it sounds. The model has no tired version of itself. It writes with the same care at eleven at night as it does in the morning. I do not. My late night changelogs, which are the ones that actually get written, are rushed and half finished. The honest comparison was never the machine against my best work. It is the machine against the exhausted version of me who was actually going to do this job, and against that version the machine wins every time.
Written for a reader, for once
The speed is nice. The bigger win is the audience shift. Left alone, I write changelogs for myself, packed with internal names and technical shorthand that mean nothing outside my own head. Told to write for a normal person who just wants to know what is new, the model strips all of that out. A cryptic note about a function nobody has heard of becomes something like: search is now faster and finds more results.
On this specific, narrow task, performed at the hour it actually gets performed, the model is honestly a little better than me. I have made peace with that.
The instruction is where the taste lives
I do not type "write me a changelog" and walk away. The value sits in the instruction, and getting it right took real iteration. Early versions came back too long, listing every trivial fix as if it mattered, so I told the model to be ruthless, bury the boring items, and lead with what readers would care about. Then the output was too dry, so I asked for the light, plain tone I would use describing my own work to a friend. Each round I read the result, found what was off, and pushed the instruction further.
The instruction is the real program here. The model is the engine. All of my judgment about what a good changelog looks like lives in a few careful sentences, and that pattern holds across nearly every AI automation I have built. The cleverness never sits inside the model. It sits in how precisely you describe what good looks like.
Where it gets things wrong
The failure modes are regular and instructive. Sometimes a note is so cryptic the model cannot tell what the change really did, so it guesses, confidently, and lands wrong. Sometimes it merges two changes that were genuinely separate, or splits one change into two. And it has no way to know which changes matter to my actual users versus which ones merely felt big to me while I was building, so its sense of what to lead with is occasionally off.
None of that is a disaster, and all of it is why the output never ships untouched. I read every line. The model delivers a draft that is ninety percent there in seconds, and I spend two minutes on the last ten percent, the part that needs a person who knows what really happened. That review is what makes the whole arrangement safe to rely on. I am the only party who knows the true history of the work, so I am the only one who can catch the confident wrong guess. The day I stop reading the output is the day this stops being something I trust.
What it actually costs
The model is metered, and a single changelog is a tiny request, so each run costs a fraction of a cent. I run it about once a week, which means the operating cost rounds to nothing.
The real bill was elsewhere. It was the time spent up front iterating on the instruction, plus the two minutes of reading I still pay on every release. That is the recurring shape of this kind of work: the tooling is cheap and getting cheaper, while the valuable part remains knowing what a good result looks like, well enough to specify it and well enough to catch the misses.
The lesson worth stealing
Would I tell everyone to automate their changelog? Only if you actually keep one, and most people do not, so start with some honesty there.
The transferable part is the shape. Look through your week for jobs where the input already exists, the work is tedious reshaping rather than judgment, and a small error is cheap because you review the result anyway. Those jobs are ready for this technology today, without any hype required. The changelog was simply the first one I noticed in my own work. Once the lens is in place you find these small automations everywhere, and each one quietly returns a slice of your week. I write up the others, including the ones that failed, at [xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.