Developer Docs Pipeline
How engineering changes become correct, reviewed, shipped docs at ArborXR
The problem
Developer docs rot quietly. Engineers change an SDK or migrate an auth scheme, and the docs keep describing the old behavior. Nobody owns the gap, so it sits there until a customer’s developer hits it and files a confused support ticket.
That’s a product problem. Docs are the first thing most developers touch, and a wrong page costs them integration time and costs us trust. Fixing one well takes three things that rarely live in one person: knowing what the code actually does, writing it in the docs framework, and getting the right engineer to sign off.
I’m a product manager at ArborXR , and I do all three myself.
How it works
From an engineer’s offhand answer to a live page on the public developer portal , with Claude Code doing the mechanical work and me making the calls:
- Capture the change, usually from a Slack answer or an SDK update.
- Read the SDK source to confirm what the code really does.
- Draft in the site’s real components, matching the surrounding style.
- Build and preview locally, since CI only builds the docs after a merge.
- Ticket, branch, clean commit.
- Open the merge request and route it to the engineer who owns that code.
- Ship on approval.
I’ve run it for several changes now, including an auth terminology migration and a new section for a feature the docs had only ever claimed existed.
Decisions I’d defend in an interview
| Decision | The judgment behind it |
|---|---|
| Read the source, don’t trust the summary | The docs claimed a feature worked but never said how. The source showed the real behavior, including a quirk where it only records position when the object both moves and rotates. That went in the docs, caveat included |
| Route to the actual code owner | I check the repo’s ownership rules instead of guessing. A review sent to the wrong person is dead on arrival |
| Build locally before proposing | Otherwise a formatting error surfaces in production, after the merge |
| Under-promise | I documented the platforms people asked for, flagged an untested path as untested, and kept a labeled legacy section so existing integrators weren’t stranded |
Where it stands
Live and repeatable. It’s a human-in-the-loop process, not a bot. I drive every step and make the calls. The commits are the easy part. The PM work is deciding which gaps are worth closing, how much to caveat, and whose approval actually unblocks the ship.