Case Studies Blink Labs Software

When you know you need it but don't 
want to build it.

Role
CEO, Primary Release Engineer
Cadence
2–3 releases per day, across multiple products
Use Case
Release notes, documentation updates

Chris is the kind of engineer who builds things. He's Blink Labs' CEO and primary release engineer, managing multiple products shipping two to three releases a day — sometimes more. If anyone was going to script his way out of a documentation problem, it was him.

He didn't. Not because he couldn't, but because he understood something most engineers take too long to admit:

I'm a builder, but I also am a buyer. Sometimes it makes sense to just accept technology from someone else that solves your problem. Why do I want to spend my time writing a system that helps me write documentation that I don't even want to do in the first place?

Chris Gianelloni · Blink Labs
Before: the honest version

A raw changelog, written for developers only.

Before Doc Holiday, Blink's release notes were GitHub's automated output — a raw changelog generated by pattern matching, written for developers only.

"We treated our releases in GitHub like a changelog. It's less release notes on things that are of importance, and more a minutiae of exactly what happened."

His documentation engineer — a writer, not a developer — would receive those changelogs and try to distill them into something useful. The problem was that the documentation engineer couldn't always tell what mattered. Questions went back and forth asynchronously. And at multiple releases a day, the volume ate up so much time, and that's before considering anything else on Chris' plate.

"It was me asking our docs guy to go write updates based on some particular version of our software, giving him the changelogs, and him spending a lot of time even figuring out what all that meant."

§
After: from hunter to editor

What changed wasn't speed. It was the shape of the work.

What changed most noticeably wasn't speed; it was the shape of the documentation engineer's job.

Before Doc Holiday, the document engineer hunted. He watched releases come in, chased down developers for context, tried to reconstruct what changed and why it mattered to users. Now he edits. Doc Holiday monitors the release pipeline and pushes suggested documentation changes to him automatically as code ships.

Now he's more like an editor. He has a stream of submissions. I've even told him: you can throw away stuff it does, you can talk to it, tell it what to change.

Chris Gianelloni · Blink Labs

Doc Holiday translates what changed in the codebase into language a writer can work with, which means the writer can make decisions on his own rather than waiting for a developer to explain why a dependency update is key for users.

"AI has taken the research work out of the equation for him. All of the waiting, all of the asynchronous communication like 'hey, what does this mean?', now it's distilled down automatically."

§
The real work: tuning it

LLMs want to do something. Always.

Chris doesn't oversell the setup. Getting Doc Holiday to behave the way he wants requires iteration, and the most persistent challenge is a fundamental one: LLMs want to do something. Always.

Many releases contain nothing a user needs to know about, like an internal refactor. But Doc Holiday, like any language model, defaults to finding something to say.

"Doing nothing is unheard of. It always wants to try to please you."

His solution is architectural rather than prompt-based. Instead of trying to convince the model to stay quiet, he's restructured his pipelines so the model always has a valid task — updating the release notes page, for example — which frees him to gate documentation updates more selectively. Each application gets its own release notes page in the documentation site, the model updates it on every release, and the actual documentation only changes when there's something genuinely worth saying.

It's a workaround, but it's also an honest read on how to work with LLMs in production: design around their tendencies rather than against them.

§
If you're still doing it manually

Better than SEDs and GREPs.

We asked Chris what he'd tell someone still handling release notes manually.

It would save a tremendous amount of time to have automation, and better yet, automation with a voice via AI. You can train it much better than SEDs and GREPs for doing release notes and documentation updates.

Chris Gianelloni · Blink Labs Software

And for the engineers who think they'll just build something themselves:

"You're solving a problem that I have that I don't even want to solve. I want it to magically go away."

Chris Gianelloni · Blink Labs Software

time to Get your docs in a row.

Begin your free trial and and start your Doc Holiday today!