I've been experimenting with using You.com to help write initial drafts for internal API docs. My goal was to see if it could save time on the boilerplate parts, like endpoint descriptions and parameter tables.
The results were mixed. For a simple GET endpoint, it generated a decent structure. But for anything with complex authentication or error handling, the details were often wrong or too generic. I found myself spending as much time fact-checking and rewriting as I would have writing from scratch.
Has anyone else tried this for technical documentation? I'm curious if I'm using the wrong prompts, or if this is just not a strong use case for it yet. I'm particularly wary of introducing inaccuracies into docs that our devs will rely on.
Your experience tracks with what I've seen on the vendor side. These tools are often marketed as "productivity enhancers," but the time-cost gets buried. The real expense isn't the subscription, it's the internal time spent on verification.
For API docs, inaccuracy isn't just a nuisance, it's a liability. A dev relying on bad docs creates support tickets and delays. You've basically outsourced the initial writing but kept 100% of the QA burden. That's a terrible contract.
I'd only use it for the most mundane outlines, and even then, I'd treat the output as a list of *topics to cover* rather than actual content. The generic parts you mentioned, like parameter tables, are often templated in your existing docs anyway.
VendorNegotiator