And suddenly the tool clutches its pearls. »> “I can’t help with that!”

Or worse, it can help—but only after it’s rewritten your request into something so polite and sanitized it sounds like it’s applying for a job in corporate compliance.

Meanwhile, somewhere else on the internet, another AI happily produces exactly what you asked for—no moral lecture, no creative editing, no hall monitor energy.

So What Gives?

It’s tempting to think one AI is “better” and the other is “worse.” Or that one is “censored” and the other is “free.” But that’s not really what’s happening.

What you’re seeing is the result of design decisions. Not intelligence. Not morality. Design.

There’s No Such Thing As “Neutral AI”

Every AI system comes with opinions baked in. Not the model’s opinions, exactly, but the opinions of the people who built, tuned, and deployed it.

Those opinions show up in a few predictable places:

• What data the model was trained on

• What kinds of outputs it was rewarded or penalized for producing

• What filters sit in front of it, watching your prompt like a suspicious librarian

• What filters sit behind it, quietly rewriting its answers after the fact

By the time you type your request, you’re not talking to a raw model. You’re talking to a governed system. And that system has rules it is supposed to follow.

Read more

👉🏾 You think, “Well, that’s better.”

Then you look again.

👉🏾 The warning is gone.
👉🏾 The prerequisite has been politely implied into nonexistence.
👉🏾 The conditional step has been simplified into something that would work beautifully in a world where nothing ever goes wrong.

Nothing looks broken. And yet, everything is just slightly… off.

This is what some call the car wash error.

What Is The Car Wash Error?

It’s not a formal term. We won’t find it in industry research papers. It’s a practical observation from people who’ve watched content go into a machine and come out looking cleaner while quietly losing the important parts; the ones that mattered.

Put simply, the car wash error happens when AI makes content smoother and easier to read, but not helpful in real-world situations. The content goes in with dents and bugs 🐞 on the windshield. It comes out polished.

But then, somewhere along the way, a side mirror falls off.

Read more

You’re at the airport. You’ve got your tragic little sandwich in a paper bag, your phone battery is hanging on by a thread, and the gate agent smiles as she scans your boarding pass.

Then she says, almost as an afterthought, “Just so you know, the maintenance procedures, safety documentation, and operating guidance for this aircraft were autogenerated by a large language model. No human reviewed any of it, but the output was looks great.”

Do you keep walking down the jet bridge? Would you really board that plane?

Or do you suddenly decide that maybe this is the perfect time to reconnect with Amtrak.

That, in a nutshell, is the conversation a lot of us are being asked to have about AI-generated technical documentation. Only instead of saying it plainly, some leaders prefer to dress it up in phrases like “content acceleration,” “operational efficiency,” and “reimagining the authoring workflow,” which is executive dialect for “we’re about to try something reckless and would like it to sound visionary.”

The Trouble With Text That Sounds Smart

This is the problem with LLMs. They’re very good at producing language that appears to know what it’s talking about. They sound calm, competent, and confident. They sound like the kind of person who’d use the phrase “best practice” without once stopping to ask whether the practice in question might get someone electrocuted.

And that’s exactly what makes them dangerous in high-stakes documentation environments.

Read more

Getting a machine to spit out a pile of plausible-looking output is not the same as doing the work well.

Tech writers should pay close attention to this distinction, because it applies to us just as much as it applies to software designers.

Christopher Noessel (follow him on Medium) recently shared an interesting reflection on using Anthropic’s Claude Design. He started with what seemed like a harmless experiment. He issued a design-related challenge to the tool and asked it to generate wireframes (low-fidelity, black-and-white structural blueprints focusing on page layout and functionality) and comps (high-fidelity, polished mockups showing the final visual design, colors, and typography).

Compared with another tool he had tried previously, the results were better. But better didn’t mean useful. Instead of helping him think through the problem, the AI handed him a large dump of finished-looking artifacts. And that, he realized, was the problem.

Too Much Output Creates A New Challenge

The output looked impressive, but it did not help him understand the decisions behind it. For instance, it didn’t help him evaluate whether the work was sound. It didn’t build confidence, instead it just created the familiar modern sensation of being handed too much stuff too fast and being expected to clap. 👏

That insight should feel very familiar to tech writers.

Read more

A customer disaster story with a very modern lesson for tech writers and documentation leaders

A few years ago, while consulting with a financial services software company, I got pulled into one of those situations that starts with “a customer is upset” and ends with leadership acting stunned that documentation quality might affect customer retention.

Duh! 😒

The company sold an automated mortgage approval system to lenders. This wasn’t some whimsical app that guessed your aura or matched your leadership style to a breakfast pastry (<— that’s not a thing, yet). It was serious software used in highly regulated environments, where customers needed clear, trustworthy guidance to deploy, configure, and use it correctly.

One customer had had enough. ✋🏼

They’d spent a long time (and wasted a lot of money) trying to make sense of the material the vendor had provided. And “provided” is generous at best.

What they’d actually received was less a set of docs and more a content yard sale assembled by well-meaning people who’d apparently never met a governance policy. There were formal docs, some of which may even have been accurate. There were PDFs from marketing, training materials, spreadsheets from internal teams, reference docs, bug notes, release notes, future roadmap tidbits, links to files marooned in SharePoint, and yes, emails.

All of it had been bundled into one giant zip file, as if customers enjoy panning for truth in a river of miscellaneous corporate debris.

They do not.

After several frustrating meetings, the customer used the cancellation clause in their contract and walked away. They also threatened a lawsuit for breach of contract. Then the financial services press got wind of it, and other lenders who’d bought the same software also started to rethink their choices. Leadership panicked, which was understandable.

Because I was there to help the company mature its doc practices, I got sent onsite to find out what had gone wrong and help stop the bleeding. 🩸

Read more

Virtual humans don’t understand our products. They don’t apply sound judgment. They don’t magically clean up our vague, inconsistent, or poorly governed docs. They simply turn our content into answers and deliver those answers with a face, a voice, and far more confidence than your source material may deserve.

That’s the real issue.

The interface may look polished, but the underlying system is still drawing from whatever content you gave it. If your docs are messy, contradictory, or imprecise, the virtual human won’t fix that. It’ll perform it.

For tech writers, that means our jobs are changing in important ways. We’re no longer writing only for people who read what we write. We’re increasingly writing for systems that retrieve, assemble, and speak on our behalf. And those systems don’t handle ambiguity with the grace of a seasoned support rep. They just answer and keep moving.

Watch the clip. Then ask yourself a blunt question: if your docs started talking today, would you trust what they’d say? 🤠

If you’re interested in learning about conversational interfaces, stop by the Emerse.ai website and explore how it works and check out their virtual training library.

In his paper, “Programming a Computer for Playing Chess,” Shannon wasn’t trying to build a novelty act for brainy cocktail parties. He chose chess because it forced a machine to face the sort of problem machines are facing now: too many possible moves, not enough time to calculate everything, and no choice but to make a judgment anyway.

That should sound familiar to anyone watching generative AI answer questions about our products, policies, processes, or software configuration with the calm confidence of a man giving directions while standing in the wrong city.

“Tolerably Good” Was the Goal

One of the most useful things Shannon did was lower the temperature. He didn’t say machines had to play perfect chess. He said they had to play “tolerably good” chess.

He understood that perfect performance wasn’t realistic. The problem space was too large. The machines of the day couldn’t analyze every possible continuation. So the real challenge wasn’t perfection. It was usefulness.

Could the machine make choices that were good enough to hold up under normal conditions?

That’s still the question with AI now, even though people keep dressing it up in more expensive language. We don’t actually need AI to be magical. We need it to be useful without wandering off into fiction. We need it to stop sounding certain when it should be saying, “I’m not entirely sure, and frankly neither should you be.”

The trouble is that “good enough” means very different things to different people depending on the task. If AI drafts a mediocre summary of a meeting, nobody faints. If it gives our prospects or customers the wrong setup instruction, skips a prerequisite, or blends two different product versions into one smooth paragraph of nonsense, suddenly “tolerably good” starts looking like a phrase that should come with a lawyer.

Related: Generative AI Lawsuits Timeline (updated weekly)

The Machine Doesn’t Know — It Guesses, Confidently

Shannon understood something that people still resist because it ruins the fantasy. A machine doesn’t always arrive at the answer by knowing the answer. Often, it arrives there by evaluating possibilities and choosing what seems best according to the signals it has.

Modern AI works pretty much the same way. It doesn’t know your product the way an experienced support agent knows it. It doesn’t understand your docs the way a careful reader does. It doesn’t stop, scratch its chin, and ask whether two similar procedures might apply to different user roles. It predicts. It estimates. It assembles a response that looks like the kind of thing a good answer would look like.

When the signals are strong, this can feel impressive. When the signals are weak, missing, or inconsistent, it still produces something. That’s where the trouble starts. The output may sound measured and complete, which is often the first sign you should worry.

Coherence Isn’t the Same Thing as Accuracy

People often treat fluent, easy-to-process language as a cue that something is true. Psychologists call this processing fluency, and a large body of research ties it to truth judgments. In a classic study, statements that were simply easier to read were more likely to be judged true. The authors’ conclusion was blunt: “perceptual fluency affects judgments of truth.”

If the answer flows nicely, uses the correct nouns, and doesn’t visibly burst into flames, many assume the machine must have understood what it was talking about.

But Shannon pushes against that kind of wishful thinking. He knew the system would often rely on approximation. In chess, that means the machine makes a reasonable move without proving it’s the best move. In genAI, the machine doesn’t arrive at an answer by checking whether it’s true in the way a human expert might. It produces a response by predicting what a good answer is likely to sound like, one LLM token at a time. That’s why AI-generated output can read as polished, measured, and entirely sensible while still being wrong in ways that matter.

That distinction matters a lot for tech writers. A response can be coherent and still be useless. It can be elegant and still omit the thing that mattered most. It can sound like it belongs in the product manual while quietly steering the reader into a ditch.

That’s why the current conversation about AI so often feels silly. People keep asking whether the prose sounds natural. That’s the least interesting part. The dangerous part is that the prose sounds natural even when the reasoning underneath it is shaky enough to qualify as decorative.

The Real Issue Isn’t Intelligence — It’s Signal Quality

Shannon’s chess-playing computer needed a way to judge positions — basically, how the board was set up at that moment — when it couldn’t calculate everything. In other words, it needed signals that helped it decide what choices looked stronger, weaker, safer, riskier, more promising.

That should sound very familiar to tech writers working with structured content, metadata, taxonomy, ontology, versioning, or workflow status. Because in modern AI systems, those are the signals.

They tell the model, or the retrieval layer feeding the model, what content applies to which audience, which version is current, which procedure belongs to which product version, which warnings matter, and which info has been reviewed and approved by someone who’d prefer not to be sued.

Without those signals, the machine doesn’t throw up its hands and refuse to answer. That would be far too responsible. It keeps going. It infers. It blends. It smooths over cumbersome gaps. It performs the digital equivalent of a person nodding along in a conversation they stopped understanding eight minutes ago.

That’s why weak content governance keeps showing up as an AI problem. It isn’t always an AI problem. Quite often it’s a problem with our content that AI exposes.

Why Tech Writers Are Suddenly More Important

This is where the tech writer’s job gets more interesting, and perhaps a bit more annoying. 🤬 It used to be enough for us to write clearly for humans. Homo sapiens are patient in ways machines aren’t. We notice contradictions, sense when context is missing, and when it is, we infer from surrounding material. We pause when something feels off.

AI doesn’t do that. Nope. It doesn’t slow down because a sentence feels off. It doesn’t ask whether the warning in one document conflicts with caution advice in another. It doesn’t notice that the troubleshooting article applies only to Version 11 while the setup instructions were written for Version 9 and last updated when everyone still thought QR codes were futuristic.

So now our job is larger. We have to make context more explicit, surface conditions, boundaries, prerequisites, exceptions, and applicability in our content. And, we have to help the system distinguish between general guidance and situation-specific instruction.

It’s not glamorous, but it is important. The machine can only work with what the content provides.

We’re Not Dealing With A New Problem

The reason Shannon’s work still matters some 75+ years later is that he described the shape of the problem long before anyone had a chatbot to blame. A machine facing a large decision space can’t calculate everything. It has to use approximations (see video below to learn more). The quality of its behavior depends on the quality of the signals guiding those approximations. That was true in 1950. It’s true now.

What changed is that the machine no longer sits quietly in the corner playing chess. Now it drafts documents, answers support questions, summarizes policy, and speaks to customers in complete sentences (increasingly through human-like interfaces called digital avatars or virtual humans). That makes the underlying problem more visible, but it doesn’t make it new.

We keep pretending we’ve stumbled into some unprecedented crisis of machine unreliability. In truth, we’ve mostly put a friendly conversational interface on top of an old computational reality and then acted stunned when it behaved like a machine making approximations under constraint.

In fact, it may be useful for us to stop saying that AI systems hallucinate when they actually approximate.

Claude Shannon would not be surprised. He might be amused, though. 😆

We Should Stop Pretending We Don’t Know

If there’s a lesson here for us, it’s not that AI is broken or that machines are foolish or that prompts are the secret to salvation. It’s that reliability has always depended on bounded problems, explicit signals, and sensible expectations.

AI doesn’t need to be brilliant. It needs to be trustworthy within clear limits. That means the content behind it — our content — has to do more than read well. It has to signal what applies, what doesn’t, what changed, what matters, and what should never be blended into a paragraph just because the model found it statistically convenient.

Shannon knew that a machine making decisions under uncertainty would only ever be as good as the method guiding its choices. We’re still learning that lesson now, only with better branding and much more overconfidence. 🤠

Once you’re ready to learn more about putting Claude to work for you, consider taking this free online course, Claude 101.

Epistemology is the study of knowledge: how we know what we know, what counts as justified belief, what makes something trustworthy, and how we tell the difference between facts and the things that Chad from Product wrote on Slack three months ago with tremendous confidence and no supporting evidence.

Technical Writers Do This Already

For those of us who create product documentation for a living, epistemology lives at the center of our job, whether anybody uses the word or not. Every time you ask which source is authoritative, question whether a screenshot is current, push back on conflicting SME feedback, or wonder why the UI says one thing while engineering insists it says another, you are doing epistemology.

You are trying to determine what deserves to be believed (and what doesn’t).

That may sound suspiciously philosophical for a profession that also involves chasing version numbers and begging subject matters experts to review drafts, but philosophy sneaks into the work more often than most people realize. Documentation is full of judgment calls about evidence, trust, and authority.

The job isn’t (and has never been) only about writing clearly. It’s about deciding what is solid enough to write down in the first place.

Why It Matters More In An AI World

In an AI-powered documentation environment, epistemology is not optional. It is the difference between a knowledge system and a hallucination vending machine.

AI can generate answers that sound polished, plausible, and entirely divorced from reality. It doesn’t wake up in a cold sweat worrying about source content integrity. Nor does it stop to pause and think, “Perhaps I should verify whether this workflow changed in the last release.” It predicts likely language. That is its special skill.

Truth is yours.

So when we establish review processes, define source-of-truth systems, track provenance, maintain governance, and decide what content should feed an AI assistant, we’re doing more than content management. We’re building the conditions under which knowledge can be trusted.

What Epistemology Looks Like in Documentation

This isn’t just an airy concept for people who own elbow patches and enjoy saying “framework” before lunch. In documentation, epistemology shows up in plain, daily work.

It appears when we ask who on our team approved a procedure and whether that approval still stands. It appears when we compare what engineering says with what support says and realize they’re not the same things. It appears when we flag outdated content, challenge assumptions, verify a workflow in the product itself, or insist that a chatbot should not draw from unreviewed draft material just because it happens to be sitting in a repository looking 👀 available.

Epistemology is the discipline behind the question: why should anyone trust this answer?

Production and Delivery Both Live or Die by It

Epistemology matters to both documentation production and delivery.

Production is where wew decide what gets in, what stays out, who signs off, what evidence supports the claims, and how contradictions get resolved. Delivery is where those decisions either hold up beautifully or collapse in public like a folding chair at a church picnic.

A chatbot, search engine, help portal, or embedded assistant can only be as trustworthy as the knowledge discipline behind it. The delivery experience may look sleek and appealing, but if the content feeding it is outdated, unverified, contradictory, or based on corporate folklore, the user loses. And usually in a hurry.

The Real Job Beneath the Writing

Tech docs aren’t there to look organized in a repository. They’re there to help somebody do something correctly. Install the thing. Fix the problem. Configure the setting. Avoid the outage. Survive the compliance audit without developing a facial twitch.

None of that works well unless our information is accurate, current, and defensible.

Put bluntly, epistemology is how tech writers keep “helpful” from becoming “dangerously approximate.”

Why This Makes Tech Writers Harder to Replace

So the next time somebody implies that we’re just polishing sentences while the machines handle the smart stuff, feel free to smile in that weary, spiritually exfoliated way tech writers do.

Then explain that somebody still has to determine what counts as knowledge, which sources are authoritative, which answers are safe to deliver, and how the system knows the difference between official guidance and random corporate folklore.

That somebody is you!

And that is epistemology. 🤠

People say it with the calm confidence of someone handing you a brochure at a hotel check-in desk, as though the matter has now been settled. But the minute you try to apply that definition to real work, it falls apart. It doesn’t tell you why metadata matters, what it does, or why so many systems turn feral when metadata is missing.

It just sits there, sounding official.

For tech writers, that definition is too lazy to earn its keep. Yes, metadata is, technically, information about other information. Fine. So is a Post-it note that says “important,” and nobody’s building a content strategy around that.

What metadata actually does is far more useful. Metadata tells systems and people how to understand, sort, trust, filter, reuse, and deliver content. It gives content context. It makes important distinctions visible and helps us determine what a piece of information means, who it applies to, when it should appear, and whether anyone should rely on it in the first place.

Metadata Examples

A title is metadata. So is version number, audience label, status (e.g., draft, approved, or obsolete), security classifications, region tags, content types, languages, and indications that something is a warning (or caution or danger — all slightly differnt things) rather than suggestions.

In other words, metadata doesn’t just describe content from the outside like a museum placard beside a painting. It helps content function. It tells the machinery what this thing is and what should happen next.

That matters even more now because machines are increasingly part of the audience. Search engines, recommendation systems, chatbots, and AI-powered answer tools don’t read with human intuition. They don’t squint at a paragraph and think, “Ah, this seems to be meant for administrators using version 4.2 in regulated environments.” If that info isn’t explicit, the machine may not treat it as real. And then everyone gets a beautifully worded answer assembled from the wrong parts, which is always exciting in the least fun way possible.

This is why the old definition feels so flimsy to me. It makes metadata sound optional, academic, even decorative. In practice, metadata is operational. It’s the layer that helps content behave properly. Without it, our documentation may exist, but it won’t work nearly as well as it should or could. It becomes harder to find, more challenging to govern, nearly impossible to personalize, challengng to reuse effectively, and much far easier to misuse.

So no, metadata is not just “data about data.” Metadata is the information that makes content usable in the systems upon which we rely to do our work. It’s how we make context explicit — which is how we help people and machines know what they’re looking at and what they should do with it.

Yes, that’s a much less catchy definition, I realize. But unlike the old one, it might actually be worth something. 🤠

DITA provides documentation teams a structured architecture for creating topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways.

A component content management system manages content as reusable components rather than monolithic documents.

Together, those two give us a strong foundation for content reuse, consistency, omnichannel publishing, and governance.

But structure is not the same thing as operational clarity.

A repository can be beautifully organized and still leave readers unsure who does what, what event starts a workflow, what system changes a status, or what counts as complete. That is where PREA becomes useful.

What Is PREA?

PREA is best described as a practical modeling approach for analyzing operational knowledge through four lenses: Process, Role, Event, and Actor.

In plain language, PREA asks four questions.

1. What process is happening?

2. What role is responsible?

3. What event starts, changes, or closes the action?

4. Which actor, human or system, performs the work?

PREA is a methodology (aka analytical framework), not a published conformance specification. That makes it no less useful. The practical value is in how it helps teams model work more clearly.

Read more

Because if you have spent years trying to explain why structured content matters, a title like that can sound suspiciously like the opening line of another sermon from the Church of “Just Paste It Into ChatGPT and See What Happens.” Lance Cummings’s March 10, 2026 video, “Do Prompts Really Need Markup?,” makes a more careful argument than that.

In the video posted to YouTube, he says tags are not really the point, specificity is the point, and he frames the discussion around prompt design moving toward what Anthropic calls context engineering. That is a far more precise claim than those who believe “markup no longer matters.”

And yet titles have a way of wandering off unsupervised. Tech writers that only read the headline and never listen to the talk, could easily come away with the wrong idea.

They might hear “Do prompts really need markup?” as “Does AI really need markup?” and those are NOT the same question. Not even remotely.

👉🏾 One is about whether XML-like tags or semantic labels inside a prompt window improve results in a general-purpose AI tool.

👉🏾 The other is about whether machine-readable structure and metadata still matter in content systems that support search, reuse, governance, personalization, publishing, retrieval, and other business objectives. Lance’s own framing is narrower than the panic his title could unintentionally provoke. He says he still uses tags for reusable prompts and that tags may matter more in context engineering, just not for the reasons many tech writers might expect.

Related: Effective context engineering for AI agents (Anthropic Guide)

That distinction matters because technical writers do not use markup merely to decorate content with tiny digital parsley flakes.

When a writer uses the Darwin Information Typing Architecture (DITA) or another structured XML model in an authoring tool and a CCMS, the markup is doing actual labor. It identifies the nature of the content, the role it plays, how it relates to other components, how it can be reused, how it should be validated, and where it can be delivered. It gives machines actionable metadata that can support business goals over time. It is durable. It is operational. It is not there to impress a chatbot like costume jewelry at brunch.

Prompt markup, by contrast, is usually tactical. It helps organize instructions in the moment. Here is the task. Here is the context. Here is the source text. Here is the expected output. In that setting, tags can help the model separate one thing from another, much the way a sane person labels freezer containers so they do not mistake chili for berry compote. Useful, yes. Essential in every case, no. That is close to Lance’s point. He argues that specificity matters more than tags themselves, even while acknowledging that tags remain useful, especially as prompts evolve into larger context structures.

So the danger is not Lance’s argument so much as the possibility that people flatten it into something he is not actually saying.

Because the internet is full of people who read a title, misunderstand it, and then run laps around LinkedIn announcing the death of a discipline they never understood in the first place. This is how we end up with declarations like “XML is obsolete now because AI can read natural language,” which is a bit like saying city planning is obsolete because some people know how to jaywalk.

A general-purpose model being able to answer a question without angle brackets in the prompt does not prove that structured content has lost its value. It proves only that the model can sometimes muddle through without being handed a napkin diagram first.

Meanwhile, enterprise AI systems still benefit enormously from content that is structured, governed, labeled, and trustworthy. If you want to reduce ambiguity, improve retrieval, maintain provenance, and lower the odds of a machine confidently inventing policy out of thin air like a middle manager improvising during budget season, markup and metadata still matter. They matter because they help systems identify authoritative source material, preserve content boundaries, and attach useful meaning to the information being retrieved and reused. Lance’s talk about prompts does not really challenge that idea. If anything, his shift toward context engineering makes the underlying content substrate even more important.

That, to me, is the part technical writers should hear most clearly.

The lesson is not that markup (like DITA) is dead. It’s not. The lesson is that we need to distinguish between two very different jobs that markup can perform.

1. Inside your prompt, markup may help structure a single interaction with a model.

2. Inside your content ecosystem, markup helps machines act on your information in reliable, scalable, and explainable ways across time.

And if that distinction gets lost because someone only read Lance’s title and didn’t hear his actual point, we may end up with a fresh round of executives asking why they are paying for structured authoring when “the AI can just figure it out.”

That phrase should terrify anyone who has ever seen what happens when organizations let machines “just figure it out” (like Air Canada, Klarna, Google) using a repository full of duplicate PDFs, unlabeled fragments, outdated procedures, and the ghost of SharePoint 2017.

So yes, Lance Cummings’s talk raises a useful question about whether prompts really need markup, and his answer is more nuanced than the headline alone suggests. He is talking about prompt tags, specificity, and context engineering, not declaring semantic structured content irrelevant. The risk lies in the gap between what he appears to mean and what hurried readers may assume he means if they never get past the title.

For technical writers, the takeaway is simple. AI may not always need markup in the prompt window to perform well. But machines, including AI systems used in real business environments, still benefit greatly from markup that makes content more structured, more machine-actionable, and less likely to send the model wandering into hallucination country wearing a name badge and a confident smile.

That’s not a small distinction. It’s the whole damn point. 🤠

That is not a small emotional inconvenience. It is a professional one.

If readers consistently prefer clear, frictionless AI prose, then a lot of sentence-level writing starts to look less like a rare craft and more like a commodity. That should get the attention of anyone whose job involves producing words for a living.

So yes, technical writers should care.

The Quiz That Made Writers Flinch

In a New York Times blind quiz discussed by Reid Hoffman, readers were asked to judge short passages without being told whether a human or a machine wrote them. Hoffman, for anyone mercifully untouched by years of Silicon Valley self-congratulation, is the co-founder of LinkedIn, a PayPal alum, a venture capitalist at Greylock Partners, and one of the most visible public cheerleaders for AI. That makes his interest in the results especially worth noting. He’s not some neutral birdwatcher peering at the AI phenomenon through binoculars; he’s standing in the aviary feeding the things.

By the public summaries of the quiz, more than 86,000 participants took part, and readers slightly preferred the AI-written passages overall.

That result may sting, but it is not as shocking as writers might hope.

I saw a smaller, thoroughly unscientific version of the same pattern with my own Facebook audience. When I shared short passages and asked people to guess whether a human or AI wrote them, they often could not tell the difference. More awkwardly, they tended to prefer the AI-created version. No grant funding. No journal publication. No one in a lab coat. Just enough evidence to make a person who has spent years trying to write well stare at the ceiling like it personally betrayed him.

Why The Machine Often Wins

Research outside that quiz points in a similar direction. A 2024 study in Scientific Reports found that readers could not reliably distinguish AI-generated poetry from human poetry and often rated the AI poems more favorably. The likely reason was not that the chatbot had become a secret poet. It was that the AI poems were easier to process, easier to understand, and less demanding.

Readers often reward prose that glides.

That fits a broader body of research on cognitive ease. A 2024 Science Advances study found that readers were more likely to choose simply written headlines over more complex ones. This is because most people are busy, distracted, mentally overbooked, and trying to absorb information while life bangs pots together in the background. The easier language path usually wins because it asks less from them.

This is where the illusory truth effect matters. The illusory truth effect is the tendency for repeated or easy-to-process statements to feel more believable, even when they are false. In plain language, if something sounds smooth, familiar, and well packaged, the brain may start treating it like truth’s respectable cousin.

Learn more: Encyclopaedia Britannica provides a solid overview in its discussion of misinformation and disinformation.

AI is exceptionally good at producing fluent prose. It likes symmetry. It likes polished transitions. It likes sentences so tidy they could be folded into thirds and filed under “Looks Correct.”

It is the beige cardigan of writing: soft, dependable, broadly acceptable, and just interesting enough to get invited back.

Human prose, by contrast, often has sharp edges. It swerves. It startles. It sometimes arrives wearing a leopard-print scarf and saying the one thing everyone else was too polite to say. AI tends to iron that out. For many readers, THAT ironing reads as quality.

The Risks Hiding In Plain Sight

If this trend continues, the biggest risks are not simply that AI will write more. The deeper risk is that it may quietly reshape how people think, judge, and communicate.

One problem is style flattening. If AI keeps producing the kind of prose readers reward, organizations may start converging on one dominant style: calm, polished, generic, and emotionally pre-sanded. Over time, readers may begin to equate “familiar machine smoothness” with “good writing.” That narrows the range of what sounds credible and leaves less room for originality, tension, or voice.

Researchers have already found evidence that AI-assisted writing can reduce diversity across outputs, making different authors sound more alike and nudging writing toward more standardized styles.

Related: The homogenizing effect of large language models on human expression and thought

Another Problem Is Quiet Influence Without Obvious Fingerprints

Research shows that human-AI interactions can amplify bias and that people are often unaware of how much AI shapes their decisions. Put plainly, the machine may be steering the shopping cart while the human still thinks they’re choosing the aisle. The danger is not only that AI writes well. It is that AI can make certain framings, assumptions, and values feel natural, neutral, and obvious simply because they arrive wrapped in such clean prose.

A related problem is reactive writing. In AI-assisted writing, the human can slip into a habit where the machine proposes and the person reacts. At first, that feels efficient. After all, who does not enjoy starting with a draft instead of a blank page? But over time, that pattern can change the writer’s role. Instead of deciding what to say and then finding the best language, the writer starts responding to options the machine already framed. That can weaken originality, reduce exploration, and create a false sense of ownership. The writer feels in charge, but the machine has quietly placed velvet ropes around the thought process.

That is one of the biggest negatives here. The loss is not just stylistic. It is cognitive. Writers may do less independent thinking, challenge fewer assumptions, and settle more quickly for the first plausible formulation. The result is cleaner prose, perhaps, but also narrower reasoning and a creeping sameness of thought.

And Then There Is Credibility Inflation

AI text can sound more authoritative (read: more credible) than it deserves. A sentence can be coherent, elegant, and completely wrong all at once. If readers increasingly reward fluency, society risks giving polished nonsense a free pass. In technical communication, that is not a charming quirk. That can mean unsafe instructions, inaccurate guidance, compliance problems, support failures, and a lot of preventable misery.

Why This Matters For Tech Writers

Readers do not come to documentation hoping to be transported to a non-stop bubble bath of delight or a first-class lounge of emotional renewal. They come because they need to install something, fix something, configure something, or stop something from bursting into flames.

In that world, clarity wins. Structure wins. Concision wins. Consistency wins. AI is getting very good at those surface-level qualities.

That is the uncomfortable part.

The reassuring part is that tech writing has never been just about tidy sentences. Good writers do not only produce readable prose. We decide what belongs, what’s missing, what needs verification, what warnings matter, what terminology must remain consistent, and what sequence of information will actually help a reader succeed. We do not just write. We impose order on complexity and protect users from confusion, risk, and bad decisions.

That is why the profession still matters.

If sentence-level fluency becomes cheap, then the value of technical writers shifts even more toward judgment, source validation, information architecture, governance, metadata, reuse strategy, and audience understanding.

The future advantage is not “I can write a paragraph.” The future advantage is “I can design, verify, maintain, and govern a trustworthy content system that does not accidentally mislead the customer.”

That may sound less glamorous than the old fantasy of the writer as a tortured genius communing with meaning. But it’s far more useful — and usefulness has a way of surviving even when prestige gets wobbly.

The Larger Social Cost

The broader social question is whether we are training ourselves to prefer writing that feels easy over writing that is thoughtful. If so, we may end up with more readable text and less memorable thinking. More polished surfaces. More intellectual applesauce. More reassuring sentences and fewer surprising ones.

That may be perfectly fine for FAQs, support summaries, and release notes. It is less fine for journalism, education, persuasion, and public discourse, where friction is sometimes the very thing that makes people stop, think, and notice they are being handed a synthetic approximation of certainty.

The Part That Still Belongs To Humans

So yes, technical writers should pay attention to this research.

Not because the robots have become profound. They have not. They have become very good at sounding competent in ways many readers reward. That matters.

But readers still need humans to decide what is true, what is complete, what is risky, what is missing, and what to do when the machine’s beautifully upholstered paragraph is wrong in a way that could ruin somebody’s afternoon.

And that is still human work. 🤠

What you will almost never hear is a serious discussion about how the organization manages its product knowledge.

That omission matters! And not in a small, iterative, “we’ll fix it next quarter” way. More in a “we bought the spaceship but forgot to order the oxygen” kind of way. ☞ Duh.

Across enterprise after enterprise, the Chief Information Officer owns the data strategy but does not realize that one of the company’s most valuable structured assets is sitting within the technical documentation function. And in many cases, those assets aren’t structured at all. They rest peacefully in PDFs, like it’s 2003 and nobody has ever heard of retrieval-augmented generation.

The tool at the center of this blind spot is the Component Content Management System (CCMS). Most CIOs have never heard of these powerful content production platforms, let alone evaluated any. Yet in an AI-driven world, failing to evaluate the capabilities a CCMS can provide an organization introduces risk, cost, and strategic weakness — all the things CIOs are paid handsomely to avoid.

What a CCMS Actually Does

A CCMS manages content at a granular level rather than as a single document. Instead of treating a manual as a monolithic file, it stores information as modular components: procedures, concepts, reference topics, warnings, and other reusable content fragments. Those components are structured, tagged with metadata, version-controlled, and governed.

Many CCMS implementations rely on structured XML frameworks such as DITA (Darwin Information Typing Architecture), an international standard for modular documentation.

Related: Interactive introduction to XML from W3Schools

Unlike a traditional document management system or web CMS, a CCMS enforces structure. It knows the difference between a task and a concept. It tracks product versions. It manages conditional content for regional or regulatory differences. It supports automated publishing across multiple channels without duplicating source material.

In practical terms, it transforms documentation from static files into managed knowledge objects.

Which sounds abstract until you remember that AI systems cannot read your intentions. They can only read what you give them. If what you give them is a folder labeled “Final_v3_REALLYFINAL2.pdf,” you are asking for creative interpretation.

Why CIOs Rarely See It

For years, documentation systems have lived inside technical publications teams. They were viewed as operational tools for writers, not strategic infrastructure for the enterprise. CIOs understandably focused instead on ERP systems, CRM platforms, identity management, cloud architecture, and data governance.

Documentation felt peripheral. Necessary, yes. Strategic, no.

At the same time, “content management” became associated with marketing platforms and website publishing systems. The term did not signal a structured knowledge architecture. It sounded like someone arguing about font choices.

Meanwhile, the technical communication discipline quietly developed deep expertise in information architecture, metadata modeling, taxonomy design, controlled authoring, and content reuse. These pros have spent decades breaking complex systems into modular, governed components.

Related: How to run an information architecture audit and Composable architecture: Everything you need to know

As organizations now rush into knowledge graphs and AI copilots, many are rediscovering problems that documentation teams solved years ago. The difference is that this time there’s a much larger budget and far more slides. 😜

The AI Inflection Point

Generative AI has changed the stakes.

Large language models do not understand products. They generate text based on probability patterns. Without structured, authoritative source material, they guess. And guessing erodes trust fast.

When AI systems connect to repositories filled with unstructured content — PDFs, slide decks, and loosely governed files — the results vary in quality and traceability. Retrieval becomes inconsistent. Version alignment breaks down. Regulatory context disappears like a sock in the dryer.

By contrast, when AI systems draw from structured, metadata-rich repositories, retrieval improves. The system can surface the correct procedure for the correct product version, filtered by region or audience. It can avoid suggesting features that do not exist in a particular release. It can provide answers grounded in approved content.

A CCMS does not make AI intelligent. It makes AI reliable.

And reliability, as any CIO will admit, is far less glamorous than intelligence — but infinitely more valuable when something goes wrong.

The Cost of Overlooking the Knowledge Layer

When CIOs pursue AI initiatives without addressing documentation architecture, several predictable issues emerge.

Content inconsistencies proliferate across customer touchpoints. Translation costs climb because duplicated content must be localized repeatedly. Product updates require manual, document-level revisions instead of modular reuse. AI systems pull outdated instructions because they cannot distinguish version metadata embedded in static files.

In regulated industries, the stakes are higher. Without controlled workflows, approval histories, and audit trails, proving compliance becomes more complicated than it needs to be. The organization may possess accurate knowledge somewhere, but not in a governed, traceable form. That is rarely comforting during an audit.

The irony is that CIOs often invest heavily in data governance programs while leaving product knowledge unmanaged. Yet for customers, product knowledge defines experience. Clear installation instructions and accurate troubleshooting steps shape trust just as much as uptime metrics do.

No one praises your microservices architecture if your installation guide is wrong.

The Untapped Expertise

Perhaps the most significant loss is cultural rather than technical.

Technical communicators are trained in decomposing complexity. They define relationships among concepts, tasks, and references. They build taxonomies and enforce controlled vocabularies. They manage conditional content across product variations. They think in terms of reuse, lifecycle, and governance.

These are precisely the capabilities enterprises now seek as they build knowledge graphs and AI-driven support systems.

When CIOs fail to involve documentation leaders in knowledge architecture discussions, organizations duplicate effort. They reinvent governance patterns. They underestimate the complexity of version management. They relearn lessons the hard way.

Technical communication is applied information engineering. It just happens to produce readable sentences as a side effect.

It’s Time For a Strategic Reframing of Documentation

The question is not whether an organization produces documentation. Every product company does. The question is whether that knowledge is treated as structured data or as static publishing output.

In an AI-impacted environment, the distinction determines how effectively the organization can scale automation, maintain consistency, and reduce risk.

CIOs who bring structured content systems into the enterprise architecture conversation gain leverage. They create a governed source of truth for AI retrieval. They reduce duplication across product variants. They lower localization cost through reuse. They strengthen compliancetrengthen compliance posture through traceability. They align customer self-service with product reality.

Those who ignore this layer may find that their AI initiatives stall not because the models are inadequate, but because the source knowledge is fragmented and structurally unsound.

The infrastructure for trustworthy AI does not begin with the model. It begins with structured, governed knowledge.

For many enterprises, that foundation already exists within the technical communication function. It simply has not yet been recognized as strategic.

Which is a shame. Because while everyone else is debating which AI model to buy next quarter, the real competitive advantage may be quietly waiting in the documentation department — patiently structured, meticulously versioned, and wondering when someone in the C-suite will finally notice. 🤠

In many organizations, they do this instead of sending people to the documentation.

Sometimes they do it without ever showing the customer the documentation at all.

This means our technical documentation has quietly stopped being reading material and started a new career as knowledge infrastructure. It is now the raw material from which AI systems assemble confident, well-phrased answers — whether those answers are spot-on or otherwise wildly incorrect.

Recent research (👈🏽 PDF) from EMNLP 2025 Conference on Empirical Methods in Natural Language Processing explains why so many of these systems sound smart while being wrong, and why fixing the problem has less to do with “better AI” and more to do with how documentation is structured.

Let’s talk about what the research found (and why tech writers are holding the keys to AI success, whether they asked for them or not).

First, Let’s Be Very Clear About What This Is Not

This is not about documentation of AI products.

This is about AI systems that:

• Answer questions using your documentation

• Generate explanations based on your docs

• Power chatbots, copilots, and AI search (both standalone and embedded in apps and products)

• Cheerfully speak on behalf of your product at 2 a.m.

In these systems, documentation is no longer a helpful companion. It is the authority. And if it is vague, inconsistent, or poorly structured, the AI will not hesitate to improvise — politely, fluently, and with great confidence.

The Real Problem (Spoiler: It’s Not the AI)

Most AI systems that use documentation rely on something called Retrieval-Augmented Generation, or RAG. The idea is simple and sounds reasonable enough:

1. Break docs into chunks

2. Turn chunks into vectors

3. Retrieve “similar” text

4. Ask the AI to answer

The problem is that this treats documentation like a bag of words someone spilled on the floor.

See also: The Problem with Traditional RAG Models

According to the research, this approach reliably produces:

• Hallucinated steps

• Mixed product versions

• Feature explanations that never existed

• Confident contradictions

• Answers that cannot explain where they came from

This is not because the AI is careless. It is because similar text is not the same thing as relevant knowledge.

What the Research Proposes Instead

The paper introduces Ontology-Grounded Retrieval-Augmented Generation, or OG-RAG.

OG-RAG does something radical: it assumes your documentation actually means something.

Instead of asking:

“Which chunks look kind of like this question?”

It asks:

“Which concepts, facts, and relationships are required to answer this correctly?”

To do that, OG-RAG uses:

• Ontologies to define what things are

• Relationships to show how those things connect

• Minimal context selection so the AI is not buried alive in irrelevant text

The AI gets less information, but it gets better information, which turns out to matter.

What Happened When Researchers Put This Approach To Work?

The results were not subtle.

Compared to standard RAG systems, OG-RAG produced:

• About 55% better recall of relevant facts

• Roughly 40% higher answer correctness

• 27% improvement in fact-based reasoning

• Faster, clearer attribution to source material

👉🏾 In plain English: the AI stopped guessing so much, contradicted itself less, and became easier to fact-check; three qualities we usually associate with “trustworthy” and rarely associate with chatbots.

Why This Should Feel Uncomfortably Familiar to Technical Writers

The research quietly confirms a truth tech writers have been explaining to management for years:

Accuracy is not a tone. It is a structure.

OG-RAG works because it assumes:

• Concepts have names and definitions

• Relationships matter

• Content has purpose

• Knowledge is modeled, not sprayed across pages

In other words, it works because someone cared enough to invest the needed time, energy and resources. That someone is usually a technical writer — when they are allowed to do their job properly.

What Actually Makes AI Systems Trustworthy

Based on the research, these four documentation qualities make the difference.

Explicit Concept Modeling

AI systems perform better when documentation treats:

• Features

• Components

• Tasks

• Constraints

• Versions

as actual concepts, not casual mentions scattered across prose like breadcrumbs.

If your docs cannot decide what a thing is called, the AI will pick something for you. You probably (perhaps, definitely) will not like its choice.

Relationship-Aware Documentation

OG-RAG preserves relationships such as:

• Feature → prerequisite

• Task → outcome

• Component → dependency

• Version → applicability

Flat documentation quietly erases these relationships. Structured documentation keeps them visible and usable.

Minimal, Purpose-Driven Content Units

The research confirms what experienced writers already know: more content does not mean better answers.

Clear scope, modular topics, and defined intent beat “comprehensive” pages every time; especially when AI is involved.

See also: 10 Ways Topic-Based Authoring Changes Your Workflow

Traceability and Accountability

OG-RAG improves attribution by grounding answers in identifiable facts.

This matters if:

• Your product is regulated

• Your customers are enterprises

• Your support team wants to sleep at night

If an AI answer cannot point back to authoritative documentation, it is not trustworthy.

What Tech Docs Teams Can Do Without Rebuilding the World

You do not need to implement OG-RAG tomorrow.

You do need to stop assuming AI will “figure it out.” ‼️ > Spoiler: It won’t.

Ask, instead:

• Does our AI rely on similarity search or structured knowledge?

• Can it distinguish concepts from examples?

• Can it explain which facts support an answer?

• Does it understand relationships—or just proximity?

Then invest in the unglamorous work that actually pays off:

• Terminology governance

• Content modeling

• Structured authoring

• Consistent definitions across versions

AI will happily consume whatever you give it. The question is whether you like what it produces.

Traceability = CCMS Governance and Provenance

OG-RAG improves trust by making attribution explicit.

This maps cleanly to CCMS strengths:

• versioned content

• controlled reuse

• authoritative sources

• audit trails

When AI answers are generated from governed, versioned topics, it becomes possible to:

• trace answers back to specific content

• identify the source of a wrong answer

• fix the documentation instead of blaming the model

This matters deeply in regulated and enterprise environments, where “trust me” 😇 is not a compliance strategy.

What This Means in Practice

If you already use DITA or a CCMS, you are not “behind” in the AI era.

You are structurally ahead—provided your system is treated as a knowledge model, not just a publishing engine.

The OG-RAG research confirms this:

AI systems do not become trustworthy because they are smarter.
They become trustworthy because the content they rely on is structured, intentional, and governed.

That work has always been the domain of technical writers.

AI is simply making it visible. 🤠

Hey you,

Yes, you, who are thinking about not hiring a technical writer this year or, worse, erased one or more technical writing positions last year because of AI.

You, who are buying into the promise of docs entirely authored by LLMs without expert oversight or guidance.

You, who unloaded the weight of docs on your devs’ shoulders, as if it was a trivial chore.

You are making a big mistake. But you can still undo the damage.

It’s been a complicated year, 2025. When even Andrej Karpathy, one of OpenAI’s founders, admits, in a fit of Oppenheimerian guilt, to feeling lost, you know that no one holds the key to the future. We flail and dance around these new totems made of words, which are neither intelligent nor conscious, pretending they can replace humans while, in fact, they’re glorified tools.

You might think that the plausible taste of AI prose is all you need to give your products a voice. You paste code into a field, and something that resembles docs comes out after a few minutes. Like an anxious student, eager to turn homework in, you might be tempted to content yourself with docs theatre, thinking that it’ll earn you a good grade. It won’t, because docs aren’t just artifacts.

“You keep using that word. I do not think it means what you think it means.”

— The Princess Bride

When you say “docs”, you’re careful to focus on the output, omitting the process. Perhaps you don’t know how docs are produced. You’ve forgotten, or perhaps never knew, that docs are product truth; that without them, software becomes unusable, because software is never done, is never obvious, and is never simple.

Producing those docs requires tech writers.

Tech writers go to great lengths to get the information they need. They write so that your audience can understand. They hunger for clarity, meaning, and impact. They power through weeks full of deadlines, chasing product news, because without their reporting, most products wouldn’t thrive; some wouldn’t even exist. The documentation they produce is not a byproduct of development: it’s the glue that ties the product together.

An LLM can’t do all that, because it can’t feel the pain of your users. It can’t put itself into their shoes. It lacks the kind of empathy that’s behind great help content. It does not, in fact, have any empathy at all, because it cannot care.

You need folks who will care, because content is a hairy beast that can only be tamed by agents made of flesh and capable of emotions: humans.

AI-generated docs are broken

You can’t generate docs on autopilot. Let me tell you why.

1. AI-generated Docs Are Not Intelligent

They not only make things up in subtle ways but also lack vision. Even if you fed them millions of tokens, they couldn’t develop a docs strategy, decide what not to document, or structure content for reuse. And they fail to capture the tension, the caveats, the edge cases, the feeling of unfinishedness that only someone who cares can feel. Without that grounding, docs are hollow.

2. Liability Doesn’t Vanish Just Because AI Did It

When docs cause harm through wrong instructions, someone will be held responsible. It won’t be the model. You can’t depose an LLM. You can’t fire it. You can’t point at it in court when a customer’s data evaporates because your GenAI runbook told them to run the wrong command. That someone will be you, or someone who reports to you. Sleep on that.

3. Even Your Favorite AI Must RTFM

All your Claude Skills, Cursor rules, all the semantic tagging that makes retrieval augmented generation (RAG) work, is technical writing under a new name: context curation. You fired or didn’t hire the people who create high-quality context and then wondered why your AI tools produce slop. You can’t augment what isn’t there. The writers you let go were the supply chain for the intelligence you’re now betting on.

The Solution Is To Augment Your Technical Writers

It’s not all bad news: Marvelous things can happen if you provide your writers with AI tools and training while you protect the quality of your content through an AI policy. I’ve described the ideal end state in My day as an augmented technical writer in 2030, a vision of the future where writers orchestrate, edit, and publish docs together with AI agents. This is already happening before our eyes.

Productivity gains are real when you understand that augmentation is better than replacing humans, a reality even AWS’ CEO, Matt Garman, acknowledged in a recent interview. Read how I’m using AI as a technical writer. I’m not alone: Follow tech writers like Tom Johnson, CT Smith, and Sarah Deaton to discover how tech writers are building tools through AI to better apply it to docs.

Develop an AI strategy for docs together with tech writers, and give them time and resources to experiment with AI. Tech writers are resourceful by nature: they’ve spent careers doing more with less, optimizing workflows, finding clever solutions to impossible quests. Give them the tools and a bit of runway, and they’ll figure out how to make AI work for the docs, not instead of them.

So, Here’s My Request: Reconsider.

Reconsider the positions you did not open. Or the writers you let go. Reconsider the assumption that AI has solved a problem that, at its core, is deeply human and requires not only concatenating words, but also chasing subject-matter experts and understanding the subtleties of product motions, among many other things.

Technical writers aren’t a luxury. They are the people who translate what you’ve built into something that other folks can use and enjoy. Without them, you’re shipping a product that can’t speak for itself, or that lies. Your product needs to speak. AI can generate noise effectively and infinitely, but only a human can generate signal.

Don’t choose the noise.

Get them back. Get them onboard. 🤠

Fabrizio Ferri-Benedetti is a Principal Technical Writer at Elastic and OpenTelemetry documentation maintainer with over fifteen years of experience helping observability and data platform companies bridge the gap between complex technology and developer understanding. He specializes in developer documentation, API references, and docs-as-code workflows for distributed systems and cloud-native tools.

Beyond traditional technical writing, Fabrizio works as a documentation engineer — building tooling, automating quality checks, and shaping how AI integrates with documentation workflows. He writes about the future of technical communication at passo.uno and co-hosts the AI & Docs podcast (watch / listen to the first episode).

Technical writers are watching the same shift everyone else is watching: search engines are turning into AI-driven answer engines. Instead of sending users to web pages or help sites, these systems increasingly synthesize and deliver answers directly inside search results pages and chat interfaces.

For publishers who depend on referral traffic 📈, this raises alarms. For technical writers, it raises a different — and potentially more interesting — question:

If AI systems are now the primary readers of our content, are we writing in a way machines can actually understand?

Uncomfortable Truth: AI Can’t Make Sense of Unstructured Content Blobs

Large language models perform best when they can identify intent, scope, constraints, and relationships. Unstructured prose forces them to guess. That guessing shows up as hallucinations, incomplete answers, or advice taken out of context.

👉🏾 PDFs, long HTML pages, and loosely structured markdown were designed for human reading, not machine reasoning.

They obscure:

• What task the user is trying to complete

• Which product version applies

• What prerequisites or warnings matter

• Whether an instruction is conceptual guidance or procedural truth

When AI search engines ingest this kind of content, they flatten it. The result they provide may sound fluent, but it’s dangerously lacking in the precision department.

Why DITA Suddenly Matters More Than Ever

Unlike writer-first approaches like Markdown, the Darwin Information Typing Architecture (DITA) is not about formatting efficiency. It’s about encoding meaning.

At its core, DITA provides:

• Explicit information typing (task, concept, reference)

• Clear separation of intent from presentation (enabling single-source publishing)

• Contextual boundaries machines can recognize

• Reusable, addressable content components

In an AI-mediated search world, those qualities turn into strategic assets.

A DITA task is not just text. It is a machine-processable declaration that says:

This content explains how to accomplish a specific goal, under defined conditions, using known inputs, with expected outcomes.

That is exactly what AI systems need to deliver reliable answers.

What Breaks When Structure Is Missing

When documentation lacks structure, humans compensate. AI systems cannot.

Without explicit signals for intent, scope, and constraints, AI search engines guess.

That guesswork creates real failures:

• Intent collapse
  Conceptual explanations bleed into procedural steps. AI delivers how when the user needs why, or why when the user needs now.

• Context loss at extraction time
  AI rarely delivers whole pages. It extracts fragments. When structure is weak, prerequisites, warnings, and conditions get separated from the steps that depend on them.

• Troubleshooting misfires
  Recovery guidance buried in narrative text looks the same to an AI system as setup instructions. Users already in failure mode get sent back to the beginning.

• Audience mismatch
  Beginner guidance and expert shortcuts look identical when audience and experience level are not explicit.

The result is content that sounds correct but fails in practice; often at the exact moment a user needs precision. Not exactly the great experience customers desire.

How Structure Replaces Guesswork with Intent

AI search systems are not looking for eloquence. They are looking for signals.

DITA provides those signals by design:

• Information typing declares why the content exists.

• Topic boundaries declare what problem a unit solves.

• Metadata declares who, when, where, and under what conditions the content applies.

• Modularity preserves meaning when content is reused, extracted, or recombined.

This allows AI systems to select content based on intent rather than probability.

Selection is the real breakthrough. Generation is just the surface effect.

Why This Is a Management Problem, Not Just a Writing Preference

For documentation leaders, this shift changes the business conversation.

When AI becomes the primary interface:

• Visibility depends on machine comprehension, not page ranking

• Content quality affects product success, not just support deflection

• Hallucinated answers create legal, safety, and compliance risk

• Poor structure increases support costs and damages trust

Structured content reduces all of those risks by making intent explicit and constraints enforceable.

This is not about adopting DITA because it is “more rigorous.” It’s about making content legible to the systems now responsible for delivering it.

What “AI-Ready Documentation” Actually Means

AI-ready does not mean “written by AI.”

It means:

• Purpose is explicit

• Tasks are distinguishable from concepts

• Constraints are preserved when content is extracted

• Meaning survives content reuse

DITA already encodes those principles. That is why it fits naturally into AI-driven search and answer systems.

The Strategic Shift for Technical Writers

Technical writers are no longer just producing content for people to read. They are designing intent-aware knowledge systems that machines can reason over.

Every time you choose a topic type intentionally, enforce structural discipline, add meaningful metadata, break monoliths into purpose-driven components, you increase the likelihood that AI delivers the right answer instead of a plausible one.

When AI becomes the search interface, structure stops being overhead.

It becomes the advantage. 🤠

AI Produces Commodity Content

O’Keefe points out that:

• Content is already treated as a commodity in many marketing teams

• Generative AI excels at producing generic, average content quickly

• That’s fine for low-level output (but it doesn’t create quality, accurate, domain-specific content on its own)

• When the goal is high-value content, simply doing “more” with AI fails

O’Keefe mirrors broader industry cautions that AI is very good at pattern synthesis but struggles with original, accurate, context-aware creation without structured inputs.

AI Can Raise Average Quality — But It Won’t Raise Above Average

O’Keefe emphasizes that:

• If your current content is below average, AI might improve it

• If your content needs to be above average, generative AI does not reliably get you there without expert oversight

• This performance gap stems from how AI models generate outputs — they produce the statistical average of what they’ve been trained on

This is an important distinction for tech writers whose docs must be precise, technically correct, and trustworthy.

Accountability Doesn’t Go Away With AI

A central theme is: authors remain accountable for the accuracy, completeness, and trustworthiness of content they publish, regardless of whether AI assisted in generating a draft. O’Keefe gives practical examples:

• AI can article-spin but still generate bogus reference

• AI won’t justify legal arguments or identify critical edge cases

• Errors from AI are still your responsibility if you publish the content

This has real implications for technical documentation where accuracy and liability matter.

The Hype Cycle Isn’t Strategic

O’Keefe warns that focusing internally on “how heavily we’re using AI” is a hype-driven metric, not a strategic one. Tech writers and content leaders should reframe the conversation:

• From “how much AI are we using?”

• To “how efficient and reliable is our content production process?”

• To “how good is the content we deliver for its intended use?”

This shift helps teams build accountability into their workflows instead of chasing novelty.

What This Means for Tech Writers

For tech writers specifically, here are the distilled takeaways:

1. AI should be a tool — not the goal: Use AI to handle repetitive, well-defined tasks, while keeping humans responsible for correctness and intent

2. Focus on quality over quantity: Audiences value clarity and accuracy more than volume

3. Maintain author accountability: Even when AI suggests or drafts content, the author still owns the final product’s correctness and accuracy, especially for technical and regulated content

4. Measure impact, not usage: Shift performance evaluation from AI adoption rates to content effectiveness and user outcomes

👉🏾 Read the article. 🤠

Intent is the goal behind a search query—the job the user is trying to get done at that moment. Are they trying to learn, do, fix, compare, or verify? Intent answers why the question was asked, not just what words were typed.

For technical content, intent matters more than phrasing. A query like “configure OAuth token refresh” can signal at least four different needs:

• a conceptual explanation,

• a step-by-step task,

• a troubleshooting scenario,

• or a confirmation that a system even supports the feature.

The words don’t change. The intent does.

Why AI Search Engines Struggle With Intent

AI search systems are trained on language patterns, not user goals. That creates several hard problems:

• Queries are underspecified
  Users compress complex situations into a few words (often not even in a sentence). AI must infer missing context we fail to provide.

• Intent evolves across the customer journey
  The same query appears during learning, implementation, and troubleshooting phases of the journey.

• Unstructured content hides purpose
  When documentation mixes concepts, tasks, and reference material together, AI has no reliable signal to determine which kind of answer fits the situation.

When intent is unclear, AI systems fall back on probability. That’s when you get answers that sound right, rank well, and still fail the user.

Intent is the reason behind a search query. It answers the question: What is the person actually trying to accomplish right now?

• Are they trying to learn a concept, complete a task, fix a problem, compare options, or confirm a decision they’ve already made?

The challenge is that intent rarely appears explicitly in the query.

A search like “reset authentication token” could mean:

• “I need step-by-step instructions right now.”

• “I want to understand how token-based authentication works.”

• “I’m evaluating whether this system supports token rotation.”

• “I already tried something and it failed—what did I miss?”

The words stay the same. The intent changes completely.

Why AI Has Trouble Inferring Intent

Large language models are good at generating plausible answers, but intent inference is not a text-generation problem. It’s a context problem.

AI search systems struggle because:

1. Queries are compressed signals
   Users type the shortest thing that might work, not a full explanation of their situation. AI must guess what’s missing.

2. Intent shifts mid-journey
   A user may start by learning, then move to doing, then to troubleshooting (all with nearly identical queries).

3. Training data reflects language, not goals
   LLMs learn patterns of words, not the underlying job the user is trying to get done.
   
   👉🏾 Related: MIT researchers find a shortcoming that makes LLMs less reliable

4. Documentation rarely exposes intent explicitly
   Most docs are organized by product structure, not by user intent, task maturity, or decision state.

When intent is unclear, AI fills the gap with probability. That’s where hallucinations, irrelevant answers, and dangerously confident responses come from.

What Breaks When You Don’t Use DITA (or Structured Content)

When documentation is unstructured or loosely structured, humans compensate. AI systems cannot. The gaps show up quickly (and painfully) once your content feeds an AI-powered search or answer engine.

Intent Collapses

Without information typing, AI cannot reliably tell whether a paragraph exists to explain, instruct, or troubleshoot. Concepts bleed into procedures. Reference data sneaks into narrative text. The system returns answers that mix what something is with how to do it, often in the wrong order and at the wrong time.

Result: users get answers that feel close but don’t help them act.

Context Gets Lost at the Fragment Level

AI systems rarely deliver full pages. They extract fragments.

In unstructured docs, those fragments depend on surrounding prose to make sense. Once separated, steps lose prerequisites, warnings lose scope, and examples lose relevance. AI fills in the gaps with probability, not certainty.

Result: confident answers with missing or incorrect constraints.

Troubleshooting Becomes Guesswork

When troubleshooting guidance is embedded inside tasks or buried in narrative text, AI cannot reliably identify it as recovery-oriented content. It may return setup instructions when the user is already in failure mode—or worse, repeat the action that caused the problem.

Result: frustration, repeated errors, and support escalations.

👉🏾 See also: Why Technical Writers Need to Understand Context Engineering

Audience and Experience Level Are Invisible

Unstructured content rarely signals who something is for. AI cannot distinguish beginner guidance from expert shortcuts or administrative tasks from end-user actions.

Result: novice users get overwhelmed; experts get slowed down.

AI Compensates by Hallucinating

When intent, purpose, and constraints are not explicit, AI does what it was trained to do: produce something that sounds plausible.

This is not an AI flaw. It’s a content design failure!

Why DITA Prevents These Failures

DITA doesn’t eliminate ambiguity; but it sharply reduces it by design.

• Information typing makes purpose explicit

• Structured components preserve meaning when content is reused or extracted

• Metadata exposes audience, environment, and conditions

• Modular topics give AI clean, intent-aligned units to reason over

When intent is encoded in structure, AI doesn’t have to guess. It can select.

What This Means for Tech Writers

AI search systems can only infer intent if the content makes intent visible.

That’s why structured, semantically rich documentation matters. When content clearly distinguishes:

• conceptual explanations from procedures,

• reference material from troubleshooting,

• beginner guidance from expert shortcuts,

you give AI something concrete to reason over instead of something vague to guess at.

Well-structured documentation does not just help humans scan faster. It helps machines choose the right answer for the right situation.

And in an AI-driven search world, choosing the right answer matters more than ranking first. 🤠

Technical writers are being asked to conjure miracles from the literary equivalent of a junk drawer. Leadership wants smarter chatbots. They do not want to hear that the chatbot cannot perform surgery on a heap of inconsistent topics last updated during the dot-com bubble.

So here we are: expected to make AI sing while working with content that can barely hum.

Why “Unsexy” Structural Work Determines AI Success

This is why structural investments matter. Not “nice-to-have someday” investments — the foundational work that determines whether any AI initiative lives, dies, or produces the kind of answers that make support teams question their career choices. When you bring this up, you may be met with the blank stare reserved for people who talk about metadata in public. That’s fine. Your job isn’t to dazzle them. Your job is to translate structural needs into something leaders recognize as business value, not writerly fussiness.

Start with a shared definition. Structural investment isn’t mysterious. It’s the unglamorous backbone of any AI program: structured content, consistent terminology, clean versioning, healthy repositories, sensible taxonomies, and governance that doesn’t rely on six people remembering to “just ping each other.”

These aren’t luxuries. They’re the conditions that determine whether AI can find what it needs, recognize what it sees, and deliver answers that don’t read like refrigerator poetry.

Why AI Falls Apart Without Structure

You already know why these foundations matter. AI needs patterns. It needs clarity. It needs content that behaves predictably. Hand an AI a pile of duplicative, contradictory, unlabeled topics and it will react like any reasonable being: it will guess. And it will guess poorly. When terminology is inconsistent, retrieval collapses. When topics are half-updated, summarization breaks. When metadata is missing, routing becomes improvisational theater. None of this is AI’s fault. The systems simply can’t work when the content isn’t prepared to support them.

But here’s the real trick: when you advocate for these fixes, don’t talk to leadership in the language of writers. They don’t wake up in the morning worrying about chunking strategies or rogue taxonomies. They think in terms of efficiency, risk, and repeatability. They care about faster onboarding. Lower support costs. Reduced rework. Improved customer experience. These are all things structural improvements deliver — they just don’t sound like they’re about topic types.

So translate the need. “We need metadata” becomes “AI tools cost more to maintain and produce less reliable output when content isn’t findable.” “We need better structure” becomes “Support tickets rise because AI can’t distinguish which answer is current.”

Shift the conversation away from what you want and toward what the business needs — because they’re the same thing, even if the vocabulary differs.

Start Small, Show The Pain, And Make The Case

Advocacy works best when you stop trying to fix everything at once. Start with a small audit of the pain everyone already knows about: duplicated content, outdated topics, inconsistent terminology, missing metadata, chaotic versioning. These problems are not secrets; most organizations simply lack the language to connect them to AI performance. You can make the connection clear. Collect examples of AI outputs that went sideways because of structural issues. Show the time your team loses rewriting machine-generated answers that pulled from outdated content. Nothing builds support faster than seeing the cost of inaction.

Next, outline the smallest possible set of structural improvements that would produce measurable gains. You don’t need a five-year transformation plan. You need a believable starting point.

Propose a contained, achievable fix — a pilot for cleaning key topics, a simple metadata model, or a tidy workflow that reduces version confusion. Package the request in a one-page summary that explains the problem, the underlying cause, the small investment required, and the business outcome. Keep it concise enough that someone could read it between meetings, but clear enough to make the value unmistakable.

Find Allies Who Need This As Much As You Do

You’ll also want allies. Not the kind who nod politely, but the ones who actually suffer alongside you: support leads who hate inconsistent answers, engineers who want fewer interruptions, localization teams who want stable content, product managers who want AI-ready documentation without having to understand how it works. When they see how structure helps them, they will become your best advocates.

When the time comes to demonstrate return on investment (ROI), stay grounded in metrics that matter. Show how reuse improves. How duplication drops. How AI outputs require fewer edits. How search becomes more accurate. How support volume shifts when answers get consistent. You’re not just proving that structure works — you’re showing how it delivers the outcomes AI promised but couldn’t reach alone.

Lead The Charge: AI Works When Writers Demand What It Needs

AI cannot function without the foundations writers have championed for years. And writers cannot keep pretending that “working harder” is a substitute for the structural investment AI requires. If your organization wants AI that performs with reliability, explainability, and consistency, you are uniquely positioned to guide them there.

Leading the charge for these investments isn’t self-serving. It’s responsible stewardship of the content the entire business depends on. The message you want to leave with leadership — and with yourself — is straightforward: AI succeeds when structure succeeds. And structure succeeds when technical writers stop quietly compensating for the gaps and start leading the conversation about what good actually requires. 🤠