As developers, we spend a lot of time asking questions.
Some of them are about architecture or performance. Many are smaller and more practical: how an API is structured, which fields to query, or how a feature is supposed to work in a real project. Often, the first place we ask a question isn’t the documentation anymore. It’s ChatGPT, Claude, or the AI assistant inside our editor.
For broad topics, this works fine. But as soon as the question becomes product-specific, the answers get less reliable. Field names are slightly off, examples don’t fully line up with the product, and important implementation details are easy to miss. In practice, that means you still end up opening the documentation to verify what actually works.
That gap between AI help and real implementation is what pushed us to rethink how our documentation works. Not how it looks on a website, but how it’s consumed by the tools developers already rely on.
The problem with generic AI answers
AI models don’t validate APIs or check schemas. When they don’t have direct access to product-specific documentation, they rely on patterns they’ve seen elsewhere. The result often looks reasonable, but it’s based on assumptions rather than the actual API contract.
We’ve seen this happen with our own APIs. A query looks correct at first glance, but uses fields that don’t exist in Prepr. An example explains the right idea, but leaves out required arguments or system fields. Small differences like these are easy to miss, and they usually show up later as runtime errors or broken integrations.
The issue isn’t that AI tools are unreliable by nature. They’re working with incomplete context. Without a clear, authoritative source to pull from, they default to what’s common or statistically likely. For developers, that means extra verification work and less confidence in the answers we get.
Documentation is now an AI input, not just a website
Documentation still defines how a product works, but today it’s often accessed through AI tools before it’s read directly.
