We Stopped Writing Docs for Humans

A few weeks ago, Etienne and I put out a Skill ↗ (opens in a new tab) for Sudden, and a couple people asked why we’d bother when we already have a docs site. Honestly, fair question. And the answer comes down to something the two of us are stubborn about in business: win-win, or it’s not worth doing. It runs through everything we do at Sudden, and it’s the reason we made a pretty unusual call about our docs.

Etienne said something recently: he hasn’t installed a package by hand in months. His agents do it.

And it’s not just him. Developers don’t write integration code line by line anymore, and they definitely don’t read documentation front to back. Their agent does. They tell Claude Code, Codex or Cursor what they want, and it goes off, reads the docs, gets it working.

So we’d built this nice documentation site ↗ (opens in a new tab) for a human who, more and more, isn’t the one reading it.

There’s a bigger issue for a startup our size, though. We’re not a household-name library. We’re nowhere in the training data these models learned from. So when a developer tells their agent “add Sudden to this,” the agent has never heard of us and starts guessing. That’s a rough way to meet a customer, and it’s the line between landing an integration and losing it.

So we changed what we ask people to do first.

On most JavaScript projects, step one in the docs is “run npm install.” Ours isn’t. Ours is “add the Sudden skill” ↗ (opens in a new tab). Once it’s in, the agent takes over. It reads our docs, figures out how Sudden fits your setup (a script tag, npm with React, or hooking into a service worker you already run), and does the wiring itself.

The skill is open source, it sits in its own repo ↗ (opens in a new tab), you can read every line. It tells the agent the steps to add Sudden and where in our docs to go look things up, and the agent reads them the way a person would, minus the sighing.

Etienne did something else, and it’s the most “two of us running this thing” move we’ve pulled.

Two repos, the docs and the skill, drift apart over time. The skill says “go read this page about the JavaScript client,” then a month later we rewrite that page, and now the skill is pointing people somewhere wrong. Usually that’s the kind of quiet rot nobody catches until a customer trips on it.

Etienne wasn’t going to make that a thing a human has to remember. We already had an agent watching our docs for typos and gaps, so he handed it the skill repo too. Change the docs, it opens a pull request on the skill with the fix. Ship the docs live, that request merges on its own. The skill keeps itself honest. Neither of us touches it.

His words: “I don’t need to remember to do things anymore.”

And that’s the win-win part. Both of those decisions come from the same place. We didn’t want you burning a week of engineering time just to try us, so we built the skill to take that off your plate. And we didn’t want you gambling budget on a maybe, so we only get paid out of the money we actually save you. 30% of what we take off your video delivery bill. Nothing if we take off nothing. If it doesn’t work, that’s our problem to carry, not yours.

It’s just how Etienne and I both think a vendor should treat the people who let them in: make it easy, and make sure you only win when they do.

If you’re running video workloads and you’re curious, point your agent at the skill and let it try. Then tell us where it breaks ↗ (opens in a new tab).