Developer Docs Pipeline
How engineering changes become correct, reviewed, shipped documentation at ArborXR
The problem
Developer documentation rots quietly. Engineers change an SDK or migrate an auth scheme, and the docs keep describing the old behavior. Nobody’s job is to catch the gap, so it sits there until a customer’s developer hits it and files a confused support ticket.
That’s a product problem, not a copyediting one. Docs are the first product surface most developers touch, and a wrong page costs real integration time and real trust. Fixing it well takes three things that rarely live in one person: knowing what the code actually does, being able to write it in the docs framework, and getting the right engineer to sign off.
I’m a product manager at ArborXR , and I built a pipeline that covers all three. I run it myself.
The seven steps
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.
- Verify against source. I read the SDK code instead of paraphrasing a README.
- Draft in the site’s real components, matching the surrounding style.
- Build and preview locally, so I know it renders before anyone reviews it.
- Track it properly: ticket, branch, clean commit.
- Open the merge request and route it to the engineer who owns that code.
- Ship on approval.
I’ve run this for multiple distinct changes now, including an auth terminology migration and a new section documenting a feature the docs had only ever claimed. Running it more than once is the point. It’s a process, not a lucky edit.
Decisions I’d defend in an interview
| Decision | The judgment behind it |
|---|---|
| Verify against source, never word-of-mouth | The docs claimed a feature worked but never said how. The SDK source showed the real behavior, including a quirk where it records position only when the object both moves and rotates. I documented what the code does, caveats included |
| Route reviews to the actual code owner | I check the repo’s ownership rules instead of guessing, and I re-check when the team changes. A review request sent to the wrong person is dead on arrival |
| Build locally before proposing the change | The docs only compile in CI after a merge, so a formatting error would surface once it’s already live. Building locally moves that risk to before the review |
| Under-promise in the docs | I documented the platforms people actually asked for, flagged an untested path as untested, and kept a labeled legacy section so existing integrators aren’t stranded |
Why this is a PM story
The commits are the easy part. The PM work is deciding which gaps are worth closing, how much to document versus caveat, when not to break existing readers for the sake of new ones, and whose approval actually unblocks the ship. It’s translation between engineer intent and developer experience, and I own the round trip.
Where it stands
- Live: real changes shipped to the public developer portal through this pipeline
- Repeatable: run across multiple distinct changes
- Honest scope: I drive every step and make the calls. The AI is the build tool. It isn’t an automated bot, and I won’t call it one
- Next: templatize the scaffolding, without removing the human sign-off that keeps it trustworthy
What this shows
AI-native PM work inside a real job with real stakeholders. I can go into a production codebase, verify a change against source, produce a correct artifact in the team’s own tooling, and route it to the person whose approval matters. Then ship it.