Information Developers in the AI Era: Does AI Write for You or Do You Write for AI?

What makes a RAG-optimised knowledge base different from traditional documentation?

Inna: I believe that the content itself makes it different, namely its depth and structure. A traditional knowledge base is initially designed for human readers who read it sequentially, carrying context over from previous sections, headers, and surrounding narrative. It is typically minimalistic and nicely formatted, with intuitive navigation, numerous screenshots, diagrams, and tables to better understand the information in context.

In contrast, a knowledge base designed for AI consumption does not need to be visually appealing. Instead, it should provide more detailed, explicit explanations and follow a well-defined chunking strategy. You are basically writing content that a Large Language Model (LLM) will use as a source to answer the users' questions. The output will not be your original text, but more like someone reading your notes in real time and explaining the idea in their own words.

This approach is called Retrieval-Augmented Generation (RAG). It means that the LLM does not rely just on its own knowledge (as with Generative AI) but also uses the information from an external knowledge source—your knowledge base. Because LLMs have a limited context window and cannot process your entire knowledge base at once, each document must be divided into smaller chunks.

How should content be structured and written to be suitable for AI consumption?

Inna: Well, to start, it is important to understand how RAG works. In a typical RAG system, content is divided into chunks, converted into vector embeddings, and stored in a vector database. When a user asks a question, their question is also vectorised and compared against other embeddings in the database. The closest matches are retrieved from the database, and those chunks, along with the original question, are then sent to the LLM, which generates the answer and sends it to the user. However, the specifics vary by project, so you need to consider the technical details of your project's setup to develop an effective documentation approach. From my experience, there are four key areas to focus on: chunking strategy, content quality, normalisation, and metadata.

First, establish a chunking strategy. You need to decide how chunk boundaries will be defined. Chunks can be based on a fixed number of characters or tokens or on natural semantic units, such as a concept, a procedure, or a Q&A pair.

Second, ensure content quality. Since it is impossible to predict which chunks will be used for a particular user question or in what order they will be presented to the LLM, each chunk must express a complete thought and make sense in isolation. Therefore, every chunk should be self-contained. It is equally important to avoid contradictions across chunks. If two chunks describe the same feature or policy differently (e.g., one outdated, one current), the chatbot has no way to know which one to use. As a result, it may select the wrong chunk or combine information from both, leading to inaccurate responses. In addition, avoid creating duplicate content that wastes storage resources and increases the likelihood of retrieving redundant or conflicting information.

Third, normalisation is equally important: convert source material into supported file formats and standardise data formats (e.g., consistent country names, phone number formats, dates, or units of measurement).

Finally, invest in metadata. It plays a much larger role in a RAG-optimised knowledge base than in traditional documentation. Metadata provides context about the content itself, including ownership, update dates, product areas, audience, and topic classifications. Additionally, metadata allows the system to filter context-dependent content—information that is only relevant for a specific region, user plan, or product version. For example, if a feature works differently for Spain vs Portugal, tagging each chunk with its audience prevents the chatbot from providing the wrong version to the wrong user. The better the metadata, the more effectively the system can retrieve the right information.

How do the responsibilities of an Information Developer change when writing for an AI chatbot?

Inna: So, from my perspective, you continue following the documentation development lifecycle (DDLC)—the fundamentals do not disappear. However, besides conducting product and audience analysis, you also need to gain a thorough understanding of the chatbot’s architecture and implementation details for your project, asking specific questions about chunk size, retrieval depth, and other details.

And because chatbot architectures differ across projects, Information Developers, now and more than ever, need to develop custom documentation strategies, own approaches, and project-specific guidelines, rather than simply reusing well-known principles and global guidelines. In practice, this means creating a style guide focused on how individual chunks should be written, building a custom set of metadata tags that fit your specific product, and setting clear rules for retiring outdated content so it no longer appears in chatbot answers. This requires greater technical and documentation skills, turning Information Developers into content architects—people who design how knowledge is structured, not just people who write it down.

Another responsibility that shifts to a completely different level is testing. When writing for AI, it is no longer enough to test documentation for usability and technical accuracy. You also need to test and analyse chatbot responses using realistic user questions and scenarios, both covered and not covered by the documentation. For this project, I have access to user log files and LangSmith, a sophisticated tool for testing AI agents that shows step by step how the chatbot processes information. These resources helped me understand how real users phrase their questions and which chunks got retrieved to further deal with gaps and unpredictable chatbot answers.

Do you use Generative AI to help create content that is later used by AI?

Inna: Of course. I regularly use AI to generate ideas for structuring and improving documentation for RAG consumption. One of the most useful and frequent uses has been generating realistic test questions to evaluate the chatbot's performance. This helps me identify gaps in the docs and update content to actually answer what users are likely to ask, rather than what I assumed they would ask. It has also assisted me with content chunking by suggesting how to break down lengthy information into self-contained, reusable sections. In addition, I frequently use it to generate metadata, create glossary entries, and improve the overall consistency of documentation.

What advice would you give to help Information Developers avoid mistakes when creating documentation for virtual assistants?

Inna: Well, I believe that documentation should avoid describing only what is available while omitting what is unavailable. When information is missing, AI is more likely to fill the gaps with assumptions or hallucinations. To reduce this risk, document both supported and unsupported features, both available and unavailable facilities, and both included and excluded options. Explicitly stating what users cannot do is often just as valuable as explaining what they can do.

For example, when documenting subscription plans, do not just describe what each plan includes. Also specify which features are unavailable or restricted. Instead of saying, "The Premium plan includes advanced analytics and custom dashboards," write, "The Premium plan includes advanced analytics and custom dashboards. It does not include dedicated support, single sign-on (SSO), or unlimited data retention. These features are available only in the Enterprise plan." This way, you leave no room for LLM interpretation.

Documentation testing is equally important. A common mistake is testing the chatbot only against carefully written and grammatically correct questions. Instead, use GenAI to generate realistic test queries that real users are likely to submit: with typos, slang, incomplete sentences, and missing punctuation.

Finally, avoid building a test dataset that contains only answerable questions. Your evaluation set should include both questions that have answers in the documentation and questions that do not. This makes it possible to verify whether the chatbot retrieves accurate information, whether it acknowledges knowledge gaps, and whether it escalates appropriately instead of inventing an answer.

At what project stage is it better to involve an Information Developer?

Inna: The sooner, the better. Ideally, an Information Developer should be involved from the very beginning of the project, during the analysis and design stages.

Let me illustrate this with a real project example. When I joined this project, the only available documentation consisted of the official website content and legacy materials from the support and sales teams. However, it quickly became clear that this content contained contradictory and outdated information, which could lead to inaccurate chatbot responses.

For example, users could receive information about the benefits that were not included in their subscriptions. As a result, they could expect the services that were never part of their plans simply because the chatbot had suggested them. The business would then be forced to clarify what the source of truth is: the official website or the chatbot. The confusion could result in an increase in support escalations.

I believe this was the moment when it became clear that content cannot simply be handed over to AI and used as-is. It needs to be reviewed, updated, and restructured for AI consumption. In many cases, it also needs to be intentionally written with AI use cases in mind.

Given this, I am convinced that early involvement allows an Information Developer to gain a deeper understanding of the project-specific requirements, provides more time to learn how the system works, and reduces the risk of content mismatches that could otherwise result in rework and delays.

Looking ahead, do you see this as AI writing for us or us writing for AI?

Inna: To summarise my point, it is not a question of whether AI writes for you or you write for AI, because the answer is both. Some documents can be easily generated by AI, but AI also depends on someone who creates the content it retrieves. Besides, even though AI can generate the content, businesses still need someone (an Information Developer) who can take ownership of that content and make it accurate, consistent, and trustworthy.

So, for Information Developers, it is high time to learn how to work with AI systems rather than compete with them because the future of Information Development is about creating content that humans and AI can understand equally.

Harness autonomous AI agents