Almost every team I talk to has tried automating their release notes, and most of them have quietly stopped. They're back in a Google Doc on a Thursday afternoon, writing them by hand, the same way they were two years ago.
That's an odd thing to happen to a problem that looks solved. It's also the same sequence every time, in the same order, which is usually a sign that the tools are all missing the same thing rather than each being bad in its own way.
Writing them by hand takes a day
The first version is always manual. Someone blocks out an afternoon, goes through what merged, chases a couple of engineers for the parts they can't decode on their own, and writes it up.
It works, in that a release note comes out of it. It just costs most of a day, and it still misses things, because the person writing it is reconstructing a fortnight of other people's work from tickets and half-remembered Slack threads. That's the state everyone is trying to automate their way out of.
Tickets describe what you planned
The tickets are the obvious place to start. They're already written, already in something close to plain English, and there's an export button. Feed a sprint's worth into a model and you get a tidy paragraph back.
What comes back reads well, and that's the part that catches people out. A ticket is written before the work starts, so it's a statement of intent, and intent doesn't survive contact with the codebase. Scope gets narrowed on the Tuesday. An edge case turns up on the Wednesday and changes how the feature behaves. Someone fixes a validation rule while they're in there and tells nobody, because it took four minutes and didn't feel like news.
Stripe's developer survey put 42% of engineering time into maintenance work, and almost none of that produces a ticket you'd ever write a release note from. A model reading your tickets can't see any of it, so what it really does is make the plan sound more convincing than it turned out to be. Those are the silent releases your customers find before you get round to announcing them.
The code gives you everything at once
So you go the other way and point a model at the code, which is at least the complete record of what shipped. This is the more honest attempt and also the more expensive one, because getting from a release of code to something a customer can read means building a custom agent and then owning it.
Then you read the output. A model reading a release has no way of knowing that the dependency bump is irrelevant and the invitation timeout is the whole story, so it gives you both at equal weight, next to an internal rename nobody outside the team has heard of. It reads technical, too, because everything it read was technical — and if you ask for something warmer you get technical claims in a friendly voice, which is worse than where you started.
The underlying problem is that a release note is defined by what you leave out. Covering everything is the right instinct for a changelog and exactly the wrong one for an announcement. So you rewrite the draft, and after you've done that a few times it becomes obvious you're doing the same job as before with an extra step in front of it, and you stop opening the tool.
Automation took the wrong half
There are two separate jobs buried inside a release note. One is working out what actually changed. The other is deciding what's worth telling people, and how to say it.
Every tool in that sequence went after the second one, and nobody was asking for that. You never wanted a machine writing to your customers in your name. You wanted to stop losing a Thursday to finding out what shipped.
That's why teams give up rather than switch tools. The tool takes over the part they were happy to do and leaves them holding the part they were stuck on, so the total time barely moves. Atlassian's 2025 research found teams lose about a quarter of the working week looking for answers that already exist somewhere in the company, and this is a small recurring instance of it: someone reconstructing from Slack, tickets and one apologetic ping to engineering something the codebase already knew on Tuesday.
What changes when you already know what shipped
If you do it the other way round, the work has a different shape.
Specsight reads each release as it lands and records what moved in product language rather than code language, so by the time anyone thinks about announcing anything, the finding-out has already happened. This Scenario changed, that one is new, this one is gone.
Which means drafting starts from a date range and a list rather than a blank document. You get every behaviour change in that window, grouped by feature, one line each with a tick box beside it, and you decide what belongs in the announcement — the invitation timeout goes in, the plumbing doesn't. That's a set of decisions rather than an investigation, and it's the part of the job that's actually worth a person's time.
The writing still ends up yours. You set a Voice once, covering audience, tone, structure, house rules and the language it's written in, and every release note after that starts from the same rules. Not because a model has taste, but because your house style shouldn't depend on whoever picked the job up that sprint.
None of it writes the announcement for you, and it shouldn't. What it removes is the two hours that used to happen before you could start.
The demo project is Specsight running on a real codebase. Browse the changelog the release notes get drafted from, no account needed. To point it at your own repository, get started.
