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.
