It's 2026. Do you know if AI can read your documentation?

In its early days, Nextworld made a bet on content: we built the product documentation into the platform itself, as structured, metadata-rich content. Instead of writing it in a separate publishing system and shipping it alongside our product, we made it part of the product.

Why? Because Nextworld is built for limitless customization. Customers can reshape applications, rename fields, and restructure things, and we wanted the documentation to survive those changes. We didn't want to publish static manuals that went stale the first time a customer changed a field name. No! Our content would be aware of the environment it describes. It would assemble itself on demand and adapt to the customer in front of it. So instead of buying a third-party documentation tool, we built our content solution directly on our platform.

When I joined Nextworld in 2017, my first responsibility was to develop our strategy and design our system, and I have spent the years since building that system out. Naturally we weren't designing for AI—that wasn't on anyone's radar yet—but the foundation we built, based on solid technical communication principles, turns out to have all the properties that a machine looks for to read our content. This is the story of our content strategy, how it's positioned us for the age of AI, and how our new machine audience has made me rethink how we value our writing team.

The person who runs your product documentation is a strategist and an architect first, a writer second. That has always been true. AI is making it visible.

Structure, not prose

Nextworld’s content design is rooted in some tried-and-true technical communication principles, most of them captured in DITA (Darwin Information Typing Architecture), the structured-documentation standard. From the get-go our content has had:

• Topic-based authoring. Every topic stands on its own. ‍
• Content types. Each topic follows a defined type (concept, configuration, example), so its shape is predictable. ‍
• Tagged elements. Styles mark what a string is (an application name, a field name), not just how it looks. ‍
• Single-sourced reuse. One piece of content can live in many places; update it once and it changes everywhere. ‍
• Hierarchical structure. Topics assemble into a navigable hierarchy.

Every topic has a metadata wrapper, which identifies things like its content type, audience, associated product, and so on. Title, a summary ("short description," in DITA terms), and the full body of content are all stored separately, so each can be weighted on its own when ranking search results. The short description is the findability layer, built to help a reader, or a search, land on the right topic.

These are all design elements that technical writers automatically reach for when writing good documentation. They make documentation easier to read and easier to maintain. It just so happens that machines appreciate all these elements too. Self-contained topics are the chunks a retrieval system wants; tagged elements and metadata values are the signals it reads; the hierarchy is the map it navigates. We didn't optimize with AI in mind, but we still optimized for AI.

So when AI showed up, our strategy paid off. Because AI is, in the end, just a new kind of reader—and the structure we'd built for human readers was exactly what it needed.

The first machine reader: our own assistant

The Nextworld conversational agent, Ed, searches our documentation to answer customer questions about the product. An early version of the agent relied on semantic search, and had questionable results: it failed to find topics, reported holes that didn't exist, and filled the gaps by guessing.

So the documentation team took over ownership of the search function, and completely rebuilt it. The whole thing was done by two people, neither of us a developer, in a couple of months of part-time work with little engineering help. This was possible because we weren't starting from a pile of prose. The structure was already there: self-contained topics to retrieve, content types to categorize information, metadata to filter on, and summaries to skim. The retrieval skill had clean, labeled material to work with, so building it was mostly a matter of teaching it how to work with the structure we'd already built for humans.

Early feedback on the new agent has been excellent. Personally I'm impressed by how good it is at pulling information from discrete topics to answer nuanced questions—and it proves how well we've documented the product.

The next machine readers: the crawlers

The second payoff is in the new nextw.com/docs site, which makes Nextworld documentation available externally for the first time.  

Why the first time? Because our documentation resolves against the live platform as you read it. The platform pulls field names, cross-references, and a few other elements directly from the environment metadata, keeping the documentation current. But remove the content from the environment, and those references can’t resolve. Until now, our documentation has only ever been available through Nextworld Help, our in-product viewer.

Now, we’re publishing a static, external version, optimized for AEO and GEO (answer engine optimization and generative engine optimization): making the content easy for search engines and AI systems to find, read, and cite.

Optimizing for those machine readers was easy, because everything they look for was already in our content, waiting to be translated. Our DITA-inspired tags, which mark what each element is, became semantic HTML a crawler can interpret. Individual topics also lent themselves to a clear heading structure that gave the section-level clarity that AI crawlers reward. The metadata around every topic became schema.org markup. We weren’t optimizing the content for machines so much as exposing structure it already had.

The external site is a snapshot: live references are resolved once, at build time. The site won’t be updated as frequently as our in-system documentation. However, we now have an external documentation site optimized for AEO and GEO, at the low low cost of a few days of my time using AI to build a proof of concept, followed by an afternoon of development time building it out.

The job was never mostly writing

In content creation, everything comes down to audience. You have to know who you're writing for and what they need to be successful. That hasn't changed. But we now have a new, secondary audience in AI. People have never wanted to read the manual. Now they have a whole new way to skip it: just ask AI. AI will do the reading for them, then format the answer exactly the way the user wants—through writing, voice, or someday soon probably interpretive dance.

Most people wouldn't call "documentation" an exciting subject. Back in the day, I had all sorts of fun ways to describe what I did for a living. My two favorites were "I'm the boring kind of writer" and "I write the stuff you don't read". When mentoring new writers, I am frank about it. People don't want to read technical documentation. No one goes out and buys a thick user's guide for some fun reading. Good technical writing doesn't fight that, it embraces it.

We write and structure documentation in a way that makes it easy not to read. We expect our readers to skim.

• Headings, short paragraphs, lists, and tables present information in a way that lets the human eye fall on the answer it's looking for, without wading through paragraphs of text.
• Consistent language and grammar identify distinct types of content, so users can tell from just a heading whether a topic contains a procedure, a concept, or a reference.
• Repeated patterns and templates organize information similarly across a type, so a reader knows where to look on a page.
• Tagged and formatted elements convey meaning, so that the eye knows without even reading how to categorize what it sees. Bold text? Probably a field name. Monospace? A value. Italic? A variable.

Every single one of these signals that we use to help the human reader also helps the machine reader. We didn't write for machines, but the signals encoded in our structure are the same signals an AI crawler uses to find and interpret meaning.

So what exactly has changed?

Not the craft of technical writing; that is largely the same. What changed is how our new AI audience has made parts of the work that have always been there more visible and more strategically important. The structure, the content types and templates, the meaning signifiers, the predictable organization, the metadata we've encoded for our own organization and reference—these things can be surfaced and can pay bigger dividends now, telling AI how to reliably interpret, retrieve, and cite content across a large documentation set.

What didn't change is everything that makes technical writing good in the first place: templates and parallel structure, concise language, curated content, predictable organization. And the oldest truth of the job, that the least of what writers do is write. The research, the questions, the planning, the decisions about how content is shaped and tagged and related, that was always the work.

Which is why "writer" undersells the job. If you work with skilled technical writers, they've been doing this all along: structuring, typing, and curating content for a reader who doesn't want to read. They were building for the machine age before it arrived.

So is your documentation optimized for machine reading? It might be closer than you think.