The difference is that now the errors — hallucinations — compile.

A recent post on DEV Community titled “Copilot is gaslighting developers and we’re all pretending it’s fine” captured something a lot of engineers have been quietly muttering in Slack channels, Reddit threads, and late-night debugging sessions: AI coding assistants routinely invent APIs, misunderstand context, generate brittle logic, and produce code that looks correct while quietly introducing defects.

Because once people trust the machine, they stop questioning it. And when software devs stop questioning auto-generated code, documentation suddenly becomes far more important than in days gone by.

Related Reading: When AI Gets It Wrong: Addressing AI Hallucinations and Bias (MIT Sloan Teaching & Learning Technologies)

Hallucinations Don’t Just Happen In Chatbots

We’ve spent the last two years talking about AI hallucinations mostly in the context of chat interfaces. Lawyers have been chastised by judges for submitting fake case citations conjured up by genAI. Students and researchers have used AI tools that generate fabricated academic references, a documented problem in academic integrity and scholarly publishing. Executives pasting strategy documents into systems that respond with polished nonsense.

But developers are now running into the same phenomenon inside their Integrated Development Environments (IDEs). GitHub Copilot, Cursor, Claude Code, and similar tools can generate useful boilerplate quickly. They can also fabricate nonexistent methods, misuse libraries, recommend outdated syntax, or confidently apply patterns inappropriate for a specific architecture.

The dangerous part isn’t that the code is always terrible.; it’s that it’s often plausible.

Plausible code is seductive. It reads cleanly. It appears intentional. It creates the illusion that someone smart already thought through the problem. Researchers studying AI-assisted programming found developers reviewing AI-generated code missed significantly more bugs than those reviewing human-written code because the generated code appeared polished and trustworthy.

That should sound familiar to tech writers. We’ve been warning people for decades that clarity is not the same thing as correctness.

The Tech Docs Connection Nobody Wants To Talk About

AI coding systems are trained on code repositories, documentation, tutorials, Stack Overflow posts, API references, GitHub examples, forum comments, and whatever random developer named Chad uploaded at 2:00 a.m. after three energy drinks and an emotional support burrito. 🌯

In other words, AI systems consume the same messy info humans do. If our technical documentation is ambiguous, outdated, inconsistent, incomplete, or lacking context, the AI inherits those problems and amplifies them at machine speed. This means bad docs no longer merely confuse humans; now they contaminate machine-generated output. This is a huge shift.

For years, the organizations we served treated docs as secondary support material. Helpful, but not operationally critical. Something to “clean up later” — maybe — or to leave to devs to “just figure out.” AI changes that equation.

Today our docs are raw materials for training, retrieval, grounding, and behavioral instruction for machines generating code. When a coding assistant generates a nonexistent API parameter, oftentimes the problem isn’t the model. Instead, the docs likely failed to clearly distinguish deprecated functionality, edge cases, conditions, actor responsibilities, or supported workflows.

Machines are exposing weaknesses in our documentation architecture the same way a blacklight exposes stains on hotel bedspreads 🦠. Yuck!

Suddenly everybody’s pretending not to notice what’s been there the whole time.

“It Passed The Tests” Is Becoming The New “It Looked Fine To Me”

One of the more unsettling themes emerging from developer discussions is the growing habit of spreading responsibility around generated code.

Developers increasingly say things like:

“Copilot suggested it.”

As if the autocomplete gremlin living in the IDE is now a junior engineer nobody technically supervises. In multiple developer forums, engineers describe reviewing pull requests filled with AI-generated logic nobody fully understands, creating a nasty downstream effect for doc teams — because eventually someone has to explain how the system is supposed to work.

When generated code collides with production reality, the organization suddenly rediscovers the value of explicit workflows, defined conditions, role clarity, architectural rationale, and accurate API documentation.

You know. The stuff we have been begging organizations to invest in since before the Etch-a-Sketch.

Structured Documentation Reduces AI Drift

This is where structured content becomes strategically important. AI systems perform better when source information is explicit, consistent, semantically organized, and context-rich.

That means:

👉🏾 clearly modeled conditions
👉🏾 explicit actor definitions
👉🏾 consistent terminology
👉🏾 accurate metadata
👉🏾 stable API references
👉🏾 structured task flows
👉🏾 reusable components
👉🏾 version clarity
👉🏾 documented edge cases
👉🏾 unambiguous process boundaries

Without those elements, AI systems are left to guess. And large language models are extraordinarily confident guessers.

The irony here is almost funny. Almost.

For years, too many tech docs teams viewed structured authoring standards, controlled terminology, taxonomy governance, and content modeling as bureaucratic overhead. Now the same companies are discovering their AI systems behave dramatically better when the documentation is disciplined and machine-readable.

Turns out semantic structure wasn’t paperwork after all. It was infrastructure.

Tech Writers Aren’t Watching From The Sidelines

We tech writers must avoid the tendency to view the radical transformation in our work as merely a software engineering story. It’s not. It's our story too.

Because the more organizations rely on AI-generated outputs, the more valuable our high-quality documentation becomes. Not decorative documentation. Not marketing-flavored “devX” fluff. Instead, actual operational knowledge architecture.

And that puts us much closer to the center of AI reliability conversations than many executives currently realize.

Developers are learning an uncomfortable lesson right now:

AI systems don’t eliminate ambiguity. They industrialize it. And when the hallucinations start shipping to production, suddenly everybody wants better documentation.

Funny how that works. 🤠

👉🏾 Too complicated
👉🏾 Too rigid
👉🏾 Too enterprise
👉🏾 Too many angle brackets
👉🏾 Too old
👉🏾 Too “legacy”

And perhaps most emotionally loaded of all:

“Won’t structure kill our creativity?”

That last one always fascinated me because nobody asks airline pilots whether take-off preparation checklists suppress self-expression. Nobody asks surgeons whether standardized procedures interfere with their artistic vision while someone’s spleen is open on the table. 😷

Meanwhile, tech docs teams using structured content quietly continued doing things their less-structured counterparts struggled to manage consistently: multichannel publishing, large-scale localization, semantic metadata management, content reuse, personalization, governance, and automation.

Because XML never left – at least not in oplaces where leadership understood the business value structure provided.

The funny part is that XML’s roots in Standard Generalized Markup Language (SGML) made some people treat it like historical reenactment software. Mention SGML at a conference and some younger attendees react like you just brought up Mesopotamian irrigation techniques.

And yet, despite all the mockery, structured content systems kept quietly powering enormous documentation ecosystems behind the scenes while the rest of the industry periodically reinvented badly organized content in various ways.

Today, AI has arrived and software engineers, startup founders, and self-appointed “prompt engineers” are wrapping prompts in XML tags because they are learning some of the same lessons we learned years ago:

Computers work better when you stop making them guess.

Somewhere, a senior DITA architect just smiled so hard they startled the cat and pulled a neck muscle.

Related: XML Tutorial from W3Schools

AI Needs More Structure Than People Expect

Large language models are very sophisticated prediction systems. Which means ambiguity creates problems very quickly.

When an AI model receives a giant content hairball comprised of loosely organized technical documentation, it must infer:

👉🏾 What is context
👉🏾 What is instruction
👉🏾 What information is authoritative
👉🏾 What constraints matter
👉🏾 What format the user wants
👉🏾 Which information should be ignored

That’s a tremendous amount of interpretation (where things begin going sideways).

Tech writers understand this already because humans behave exactly the same way when our docs lack structure. 🤠

Read more

That doesn’t mean the discussion about capability is wrong; it’s just incomplete.

We’ve spent a lot of time marveling at AI’s ability to summarize, rewrite, classify, retrieve, generate, explain, translate, categorize, and answer customer questions. But somewhere behind the flashy demo, the meter is running. 💰

And not metaphorically speaking. Every AI-powered answer has a cost. The infrastructure to keep AI systems grounded, current, auditable, secure, and useful isn’t free.

Tokens cost money. Retrieval does, too.

As does inference, monitoring, rework, escalations, and human review.

Related reading: What Is Token-Based Pricing for AI Models

Recent Reporting Shows Many Companies Are Already Wrestling With This Shift

Reuters reports that Target is weighing AI tool costs as vendors move toward usage-based pricing, where token consumption and scale can quickly change the economics.

Read more

[TL;DR] Findings from the 2026 AI In Technical Documentation Survey provide tech docs leaders a useful reality check: “AI adoption” is not the same thing as “AI operationalized.”

Your team may have plenty of AI activity — people experimenting, prompting, and sharing tips — while very little of it shows up in repeatable, governed production work. That gap is where leaders can create leverage.

Respondents to the 2026 AI In Technical Documentation Survey were asked whether they were “currently using” AI tools in their tech writing work.

Here’s what we found

AI has already moved into the technical documentation toolbox in a big way.

If you are not using AI at all, you are now officially “in the minority,” which is a weird place to be for a profession built on standards and best practices.

AI is no longer the quirky side project someone tries on a Friday afternoon when the build finally stops failing.

But the numbers also show a meaningful pause at the edge of real production dependence. About one in five respondents are not using AI as a true production tool.

Bold stances in 2026 — like refusing to adopt spellcheck because you prefer the thrill of raw, unfiltered typos.

The takeaway is not “everyone is all-in.” It’s that many teams are still in the awkward middle stage: testing what works, figuring out what is safe, and negotiating where AI belongs in a process that already has enough ways to go sideways without adding a probabilistic text generator to the mix.

Read more

In nearly every industry that builds digital content systems, you can count on one thing: at some point, someone will bring up recipes.

Healthcare teams use recipes as an example to model modular patient education content. SaaS companies reference recipes when explaining documentation reuse. Government websites apply recipe frameworks to citizen-facing information. Even chatbot schema documents use recipes to explain how structured content works. Apparently, everyone loves using recipes as structured content examples, except the industries actually managing recipe ecosystems at scale.

The irony is, the one industry that relies on recipes the most, food and cooking media, is largely absent from structured content conversations.

While food creators and recipe platforms are producing some of the highest-volume, metadata-rich content on the web, they often lack the underlying structure that makes content scalable, adaptable, and intelligent. And it’s costing them discoverability, automation, and revenue in a ramped-up AI-mediated search ecosystem.

As the founder of Blueberri, I work with recipe publishers, food bloggers, and food tech companies. My background is in content strategy and content engineering, and I was surprised to learn just how disconnected food media is from the broader industry conversations happening around content engineering, taxonomy, and reuse.

The Scale (And Strain) Of Recipe Content

Most recipe creators today are managing dozens (sometimes hundreds) of recipes across websites, social media, apps, partnerships, and AI tools. Every new format, a TikTok video, a smart display, and a grocery integration requires additional work. A recipe written once somehow ends up needing six additional versions, three exports, two rewrites, and a social caption written five minutes before publishing. And for many, it means retyping, copy-pasting, or uploading their content all over again.

That’s because most recipes are written for human readers, but not machines. They lack consistent fields, metadata, and hierarchy. Even when recipe plugins or CMS templates are used, the content itself is often semi-structured at best.

The result? Content that performs well visually but struggles operationally once it needs to move across systems. This is one reason structured recipe content matters far beyond SEO. That’s a missed opportunity for:

• (Even more) Search engine visibility

• Platform distribution (Pinterest, Instacart, TikTok, etc.)

• Smart assistant compatibility

• Licensing and monetization

In fact, the biggest content problems food teams face are the exact problems structured content was designed to solve.

And yet, I’ve found many food platforms are still missing the chance to invest in the kinds of systems that other industries take for granted. Structured content isn’t just a way to clean up content or just an organizational advantage. It’s the infrastructure behind scalable digital publishing. It’s the infrastructure that enables growth, reuse, and automation. Without it, food creators and platforms are left constantly reinventing the wheel, even as their content becomes more in-demand across platforms.

Most Recipes Are Already Structured (Just Not On Purpose)

The irony is, recipes are inherently structured. Food creators have been modeling structured content for years. Most just didn’t realize they were doing information architecture while testing banana bread.

They follow a predictable format: title, ingredients, instructions, notes. They map beautifully to content fields. They’re ideal for modeling relationships (e.g., base recipe → video → variation) and applying taxonomy (e.g., cuisine, dietary tags, meal type).

The problem is that the structure is often informal, inconsistent, or invisible to the systems trying to interpret it. It’s buried in visual design or disconnected metadata.

If food content were treated with the same level of system thinking as technical documentation, content operations, or knowledge bases, we’d see a massive shift in how recipes move through digital ecosystems. And we’d open the door to smarter, more adaptive food platforms.

Now more than ever, recipes are no longer static publishing assets. They are becoming interoperable content objects that support search, personalization, grocery integrations, smart devices, AI systems, and multi-platform distribution. That shift has implications far beyond food media.

For creators and publishers exploring these concepts further, metadata, structured content systems, and content engineering are becoming important foundations for scalable food publishing.

What Other Industries Can Learn

While this conversation starts in food, the implications reach much further. The recipe world is also one of the clearest examples of portable content infrastructure in action.

The recipe world is a case study in high-volume, high-value content that demands reuse, adaptation, and automation. It’s one of the clearest examples of how small shifts in structure unlock big gains in performance.

Food teams are learning from tech. But content teams across tech, healthcare, and government can also learn from food.

How are you handling:

• Microcontent relationships?

• Schema for personalization or search?

• Publishing the same information to multiple platforms?

Chances are, you’re already facing the same patterns that recipe creators encounter every day. The difference is that most food teams don’t have a seat at the structured content table.

It’s time to pull up a chair. Preferably, before another industry uses recipes to explain structured content while overlooking the people managing recipe ecosystems full-time.

If you’re a technical communicator, content strategist, or information architect, start paying attention to the ways food is modeled, shared, and consumed across platforms. There’s an opportunity to bring more structure to recipe ecosystems and an opportunity for the rest of us to learn from what’s already working.

Sandie Markle is the Founder and CEO of Blueberri, a consulting firm specializing in structured content systems and recipe optimization for food tech companies and digital creators. With more than a decade of experience in content strategy and content engineering, she helps teams improve recipe discoverability, build scalable publishing workflows, and prepare food content for multi-platform and AI-powered digital experiences.

You’ll hear this immediately after someone proposes adding content typing, metadata, role labeling, taxonomy governance, semantic structure, or any other activity requiring humans to think carefully for more than seven consecutive minutes.

“The AI can infer the intent.”

“The model understands context.”

“Modern AI is really sophisticated now.”

And there it is. The magical thinking phase of enterprise AI adoption.

• Not the technical phase

• Not the governance phase

• Not the budgeting phase

The magical thinking phase. 🧞‍♂️

This is often where leaders attempt convince themselves that probability engines are somehow replacing the need for precision.

Meanwhile, tech writers are sitting in the corner like exhausted air traffic controllers wondering why everyone suddenly wants to remove the runway lights because airplanes have GPS now.

AI Does Not “Understand” Our Documentation

This is the first thing tech writers must recognize when these conversations arise.

AI systems like large language models do not understand documentation the way humans do. They don’t comprehend intention, accountability, risk, authority, or operational nuance. They predict likely relationships between patterns of words.

That distinction matters more than people realize.

When humans encounter vague instructions, they often compensate using experience, judgment, and contextual clues. We’re surprisingly good at this. We’ve had practice. Humanity has spent thousands of years decoding ambiguous instructions from bosses, governments, user manuals, and passive-aggressive family members.

AI systems compensate differently. They generate statistically plausible interpretations.

Sometimes those interpretations are correct, while other times they’re spectacularly wrong. And the more ambiguous the source material becomes, the more interpretive work the AI has to perform.

That’s not intelligence. That’s interpolation.

Ambiguity Becomes Operational Debt

For years, poorly structured documentation mostly punished humans. Our readers became frustrated. Support calls increased. New employees took longer to onboard. Procedures got skipped. Nobody enjoyed any of this, but the damage was somewhat contained.

AI changes the scale of the problem.

Now ambiguous content isn’t merely read by humans. It’s ingested, chunked, embedded, retrieved, summarized, synthesized, recombined, and operationalized by machines.

Which means every undocumented assumption suddenly matters.

• If a procedure never explicitly states who performs an action, the AI has to guess

• If preconditions are implied instead of stated, the AI has to infer applicability

• If process explanations are mixed inside step-by-step instructions, the AI has to determine which text represents action versus explanation.

If six departments all created slightly different versions of the same procedure over eight years because governance was treated like optional cardio, the AI now retrieves conflicting truths simultaneously and attempts to merge them into one coherent answer.

What emerges is often less “artificial intelligence” and more “organizational fan fiction.”

“But The AI Can Infer Meaning” Is Missing The Point

Of course AI can infer meaning. Humans can infer meaning too. That’s not the benchmark.

The real question is this:

Why are we designing enterprise knowledge systems that require inference in the first place?

Especially when the content could’ve been explicit.

This is where tech writers need to reposition the conversation. The goal of structured content isn’t to make documents prettier, more academic, or more technically fashionable. The goal is to reduce ambiguity before ambiguity becomes automation.

Because once AI systems start generating answers from our content ecosystem, every vague sentence becomes a liability multiplier.

The Difference Between Retrieval And Guessing

Consider this instruction:

“Access the admin panel and update the system configuration.”

Simple enough, right?

Except now our AI system has to determine:

• Who can perform this action?

• Under what conditions?

• Is this a required task or optional guidance?

• What happens afterward?

• What permissions are required?

• What risks exist?

• Is this production-safe?

• Is this procedural instruction or conceptual explanation?

Now compare that with content explicitly structured as:

• Task

• Role

• Preconditions

• Procedure

• Expected outcome

• Warnings

• Exceptions

Suddenly the AI isn’t “understanding” better. It’s guessing less.

That’s the entire game.

AI Has Quietly Turned Technical Documentation Into Infrastructure

This is the shift many organizations still haven’t absorbed. Docs used to be viewed as support material. Helpful, certainly. Necessary, perhaps. But still secondary to “the real product.”

AI changes that relationship.

Technical documentation is now operational infrastructure.

It feeds:

• AI copilots

• Search systems

• Support automation

• Agentic workflows

• Retrieval-augmented generation (RAG) systems

• Knowledge assistants

• Internal enablement systems

• Customer self-service platforms

Machine are now one of our primary readers. And they’re remarkably literal consumers of ambiguity.

Humans recognize that a warning ⚠️ buried four paragraphs later still applies to the earlier step. AI systems may sever that relationship entirely during retrieval.

This is why structure matters more now, not less.

Even Structured Content Can Fail AI

This part makes some people uncomfortable.

Simply having XML isn’t enough. Our docs can be perfectly valid structured content (well-formed and that conforms to a specific structure (think Darwin Information Typing Architecture or DITA) and still fail AI retrieval scenarios because the semantics of our docs are weak, incomplete, or inconsistent.

👉🏼 A task topic missing actor clarity is ambiguous

👉🏼 A process explanation embedded inside procedural steps can easily create confusion

👉🏼 A role implied through prose rather than explicitly identified forces inference

This is partly why semantic approaches like PREA — Process, Role, Event, Actor — become increasingly valuable in AI environments. They help us explicitly expose operational relationships that prose alone often obscures.

What Tech Writers Should Say When SMEs Push Back

This is where diplomacy matters.

If we frame structured content as bureaucracy, we’ll lose. But, if we frame structured content as operational risk reduction, scalability, reuse enablement, and AI reliability, people start listening.

The conversation shifts from:

to:

That’s a very different meeting. And frankly, a much more interesting one.

The Real Irony Of Our AI-Powered Work

The rise of AI is not reducing the value of disciplined technical communication. Instead, it’s exposing how badly organizations needed it all along.

For years, weak structure, inconsistent terminology, duplicated procedures, and vague ownership models survived because our readers compensated for our content chaos manually.

AI removes that safety net.

Suddenly organizations are discovering that “kind of organized” is not a machine-readable strategy. Who could’ve guessed.

Well, probably the tech writers. 🤠

For tech writers, that advice is useless on its own. The question isn’t whether we should use AI. The question is where it fits, what kind of work it should touch, and how much chaos we’re willing to invite into the building.

This post from our friends at CherryLeaf is useful because it separates AI use into four distinct approaches: web-based chatbot agents, no-code AI app builders, command-line AI systems, and workflow automations. It also makes clear that these approaches differ in skill needed, risk level, and organizational ambition.

That’s an important distinction, because too many teams talk about AI as though it were a single appliance you plug in beside the microwave. It isn’t. These are four different ways of applying machine assistance to work, and they don’t solve the same problems.

What Tech Writers Should Do With This

The practical takeaway is simple. Don’t ask, “How do we use AI?” Ask, “Which part of our work are we trying to improve?”

👉🏾 If you want faster thinking and quick experiments, start with a chatbot agent.

👉🏾 If you want a repeatable tool colleagues can use without your supervision, build a no-code app.

👉🏾 If you need AI to inspect technical systems directly, look at command-line tools.

👉🏾 If you want to change how documentation work flows across the organization, then workflow automation is the real play.

CherryLeaf’s conclusion is that chatbot agents and no-code apps are the lowest-risk entry points, while workflow automation offers the biggest transformational upside but requires more planning, stakeholder alignment, and change management.

So don’t begin with “transform documentation.” Intead, begin with one painful, repetitive task. Estimate a project. Classify release notes. Identify missing prerequisites. Trace which product changes actually need user-facing content. Start there, see what breaks, and pay attention to where the upstream information is too vague, too messy, or too dependent on tribal knowledge to support automation.

Because that’s the real gift of AI in documentation. It doesn’t just speed things up. It reveals where your process has been held together by hope, habit, and one extremely patient person named Karen.

And Karen, frankly, deserves a break.🤠

One minute we’re trying to fix a broken procedure, standardize terminology, or get one stubborn SME to stop rewriting our approved interface labels. The next minute, someone in leadership is asking whether our content is “AI-ready,” as if that were a setting buried in a dropdown menu somewhere between Export and Panic.

That is why a tool like the Content-First + AI Readiness Scorecard is worth a look. The brainchild of Sarah Johnson, Founder and Strategic Consultant at Content-first Design, the scorecard gives us a way to assess whether our organization is actually ready for AI or not. It helps us spot weak governance, shaky workflows, missing structure, poor feedback loops, and the usual fantasy that better output will somehow emerge from messy inputs.

It also gives us a better way to talk with leadership. Instead of muttering about metadata until the room goes glassy-eyed, we can point to gaps in readiness, consistency, ownership, and review. That shifts the conversation from technical whining to business risk.

For technical writers, that matters. The scorecard frames AI readiness as a content systems issue — which is our turf. It helps us find workflow gaps, make the case for structured content and cross-functional involvement, identify training needs, and ask better questions before bad content starts scaling with machine-speed confidence.

No, it won’t fix governance by itself. It won’t make leadership care. It won’t stop random prompt shenanigans from spreading through the building like office glitter. But it can help us see what’s broken, name it clearly, and start a smarter conversation.

A downloadable (and fillable) PDF of the Content-First + AI Readiness Scorecard can be found at the end of this post.

Section 01: Framework And Process Maturity

This part of the scorecard checks whether our organization has a real, repeatable way to get content in shape before we dump it into design systems, publishing workflows, or AI experiences and pretend that was a strategy. It asks whether we have an actual framework, whether we use it in day-to-day work, whether we catch message problems early, whether we understand our roles, whether our testing improves our standards and training data, and whether leadership actually reviews the results.

In plain language, this section is asking: Do we have a real process, or are people mostly winging it and hoping AI won’t notice?

Read more

You’ve maybe, probably, certainly seen 👀 it. Someone reads a post — not even a controversial one, just… competent — and within seconds they’ve appointed themselves Acting Director of Artificial Intelligence Detection. There’s an imaginary badge involved. Possibly a sash.

“Aha,” they announce, as if the room were waiting. “AI.”

Not because they ran tests. Not because they checked anything verifiable.

Because it felt like AI.

The Checklist Nobody Admits They’re Using

Here’s the quiet little rubric I believe some people carry around.

👉🏾 If the writing is smooth — suspicious.
👉🏾 If the structure holds together — very suspicious.
👉🏾 If the sentences don’t wander off halfway through like a man who forgot why he walked into the kitchen — practically a confession.

Add a neutral tone of voice, a few clean transitions, and suddenly we’ve got a case. Forget the fact that these are also the E-X-A-C-T things editors have been begging writers to do for decades. There are textbooks and apps designed to help us master these principles of good writing.

And, now… they’re evidence. 🔎

We’ve managed to turn basic competence into a red flag.

What They’re Actually Reacting To (It’s Not What They Think)

Some of what gets labeled “AI writing” isn’t machine output. It’s writing that hasn’t been claimed by a human voice yet. It may sound general; maybe a little abstract (like it could apply to far too many situations).

You read it and think, “Yep, fine… but who’s talking?”

That feeling? That’s not detection. That’s absence.

👉🏾 No specific constraints
👉🏾 No decisions you can point to
👉🏾 No moment where the writer clearly chose one thing over another and left fingerprints behind

It’s not artificial. It’s just… unfinished.

And we’ve had that problem long before anyone started prompting anything.

The Awkward Part For The Detectives

The characteristics that make writing better also happen to erase most of the so-called signals.

👉🏾 You add a real example — suddenly it “feels human”
👉🏾 You cut the filler phrases — now it’s “more authentic”
👉🏾 You vary the rhythm a bit, let one sentence run long and snap the next one short — apparently that’s personality now
👉🏾 You take a stance — even a mild one — and people relax

At no point did you disguise anything. You just did the job editors have always done: you made the writing specific enough to belong to someone.

Which leaves our comment-section sleuths in a slightly awkward position. They’re not identifying authorship so much as reacting to whether the draft got finished.

The Running Commentary Problem

“This sounds AI-generated.”

Okay. And?

👉🏾 Did it say something wrong?
👉🏾 Did it miss something important?
👉🏾 Did it help anyone do anything?

Because if the answer to those questions is silence, then what we’re left with is a label floating above the work like a weather report no one asked for.

It feels like participation. It isn’t.

The Questions That Actually Move Things Forward

Better questions we should be asking:

👉🏾 Is this correct?
👉🏾 Is it useful in a real situation?
👉🏾 Does it reflect actual constraints, or just theoretical ones?
👉🏾 Would someone trust this enough to act on it?

These questions don’t care how our first drafts are made. Nope, they don’t — not at all. They care whether the final result holds up.

Here’s the part that tends to irritate most everyone equally:

👉🏾 A human can write something deeply unhelpful
👉🏾 A human, with assistance, can write something excellent

The tool doesn’t settle the question. The outcome does.

The Quiet Shift Nobody Wants To Name

What we’re really watching is a shift in expectations. Clean, structured, readable writing is no longer rare enough to be impressive; now it’s suspicious.

And instead of adjusting our standards upward (asking for more specificity, more accountability, more clarity) some people have decided to stand at the door and comment on the tools.

Not the work. The tools. 🧰

Stop Commenting On The Stove

If your first instinct when you read something is to announce whether AI was involved, you’re not engaging with the content. You’re describing the authoring process.

And in a world where process is increasingly blended, assisted, and frankly none of your business, that’s about as useful as reviewing a meal by speculating about the stove.

Meanwhile, the rest of us are trying to decide if the food is any good. 🤠

We type in the number. We blink at it. Then we immediately begin negotiating against ourselves like a hostage trying to secure release before the SWAT team arrives.

👉🏾 “Maybe that’s too much.”
👉🏾 “Maybe we should lower it.”
👉🏾 “Maybe they’ll think we’re ridiculous.”

Meanwhile, somewhere inside a corporate office park with beige walls, flickering fluorescent lights, and an emotional support Keurig machine, our potential client is trying to figure out how to stop their documentation ecosystem from behaving like a haunted junk drawer.

But there we are, sweating over whether charging professional rates makes us “greedy” or will prevent us from getting the contract. Freelancing is fascinating that way. Half the job is technical skill. The other half is accidentally discovering we have unresolved feelings about money.

And yes — those feelings absolutely can make us charge less than we’re worth.

Our Brain Thinks We’re Shopping At Target

One of the biggest pricing mistakes we make is evaluating our own services as if we were personally standing in line deciding whether to buy scented candles and frozen pizza.

We see our fee through consumer eyes. 👀 The client usually sees it through business eyes. 📊

Those are not remotely the same thing.

👉🏾 Consumers ask: “Can I afford this?”
👉🏾 Businesses ask: “What happens if we don’t fix this?”

That distinction matters more than we realize.

If we’re proposing a $15,000 content strategy engagement, we may hear:

“Fifteen thousand dollars?! That’s insane.”

The client may hear:

“Oh thank God someone might finally fix this mess before the support team stages a mutiny.”

Those are two completely different emotional experiences attached to the same number. And we constantly confuse them.

Tech Writers Are Especially Vulnerable To This

Tech writers tend to be practical people. Yes, I know that’s a stereotype, but not a bad one. We’re usually helpful, process-oriented people.

We’re not generally wandering around in fur coats throwing champagne 🥂 glasses at interns while demanding gold-plated API documentation portals.

Most of us came from environments where we were expected to quietly solve impossible problems while pretending everything was “fine.” So when we become freelancers, we often carry employee thinking into business ownership.

We price based on how long the work takes, how hard it feels, or what we personally would spend. Instead, we should be pricing against the cost of confusion, operational inefficiency, customer frustration, support burden, compliance risk, or delayed product adoption.

Know this: Companies are rarely paying for us to make “documentation.” They’re paying us to help them build capabilities that allow them to reduce chaos. Sometimes enormous chaos.

Read more

Bailie’s point is straightforward: companies keep shifting support work onto customers, then pretend the result is “self-service.” But when users have to decode vague instructions, fight bots, repeat context, navigate broken interfaces, and solve prerequisite problems before solving the actual problem, that isn’t support. It’s unpaid labor.

For tech writers, the lesson is clear: documentation is part of customer experience. If support content doesn’t explain what to do, when to do it, who can do it, what happens next, and how to recover when things go wrong, users don’t feel empowered. They feel abandoned.

[Webinar] The Content Integrity Model: Framework for an AI Age

Reimagine how you approach content by exploring the interconnected dimensions that define true integrity in today’s digital landscape. Join Rahel Anne Bailie, Content Solutions Strategist at Content Seriously, as she introduces the Content Integrity Model — a practical framework designed to help you align your content strategy with organizational goals while ensuring editorial quality, operational efficiency, and a resilient infrastructure.

Discover how strategic direction enhances consumer value, why editorial practices are essential for serving end users, and how operational efficiency drives measurable outcomes for your organization. Gain insights into building robust internal infrastructures that meet user needs and support scalable, adaptable content environments.

You’ll walk away understanding how these four dimensions work together as a holistic system — empowering you to create content ecosystems that thrive in the age of AI and beyond.

Register

Instead, AI infers intent. —> It guesses.

When you type, “How do I reset my router?” your AI doesn’t actually know what you mean. It doesn’t know if you want to reboot your device, restore its factory defaults, reset your Wi-Fi password, or erase all of your configuration settings and start over.

A human support agent would ask follow-up questions to determine those things. Large language models, on the other hand, often try to help by choosing the most statistically likely interpretation and charging forward with unbridled confidence.

That confidence is the problem.

Most AI systems interpret intent through a combination of classification and prediction. First, the model tries to identify our user’s underlying goal. Then it tries to categorize their request into a general task type: installation, troubleshooting, configuration, account access, feature usage, compliance question, and so on. After that, it attempts to infer our missing context — product version, device model, operating system, permissions, and user role.

Finally, it assembles an answer. And this is where things can get really messy.

If the system has access to a retrieval layer (Retrieval-Augmented Generation or RAG), it pulls content from our docs and uses it to ground its response. If it doesn’t find the right content, or if it finds something incomplete, vague, or contradictory, it fills the gaps in our content using general training data and pattern recognition. In other words, it makes an educated guess.

Which is a polite way of saying: it invents plausible nonsense when it has to.

Read more

His comment was fair — and also useful. The kind of useful that stings a little at first, which is often how useful arrives.

I believe Byron’s main point was this: the symptoms I described are familiar to anyone who has watched a wiki mature, decay, multiply, contradict itself, and eventually become the place where institutional knowledge goes to develop several competing personalities.

Contradictory pages. Stale search results. Important information hiding in old Slack threads. Authoritative guidance living in three places, each one slightly different and all of them confident.

He agreed those problems are real. Where he pushed back was on my diagnosis.

He argued that wiki rot is not really a property of the tool. It’s a property of the organization (or lack thereof, as the case may be). Replace Confluence with a component content management system, a docs-as-code pipeline, or a shiny knowledge delivery platform, and a team without governance will still produce scattered, contradictory, half-maintained content.

He’s right about that.

A bad ownership model will damage any system. As will a missing review cadence, weak or non-existent taxonomy or a lack of discipline. Authoring incentives that reward speed over maintainability invite challenges, and software doesn’t fix organizational misbehavior — because tools don‘t typically attend meetings, resolve accountability issues, or gently remind someone that copying the same warning into twenty-seven places is not a sustainable reuse strategy. It is a future incident report, at best.

That part of Byron’s critique lands.

But there’s another part of the argument that still matters, especially for tech writers. Governance matters. Culture matters. Ownership matters. But so too does tool category.

A collaborative wiki is not the same thing as a component content management system (CCMS).

And pretending those two categories are interchangeable is one reason documentation teams end up disappointed.

I Could’ve Been More Precise

Byron also called out my use of “knowledge management system” to describe Confluence. He said that was sloppy. He’s right.

I didn’t intend to say Confluence is a knowledge management system. What I meant is that many organizations use Confluence as though it were one.

That distinction matters.

Confluence is a collaborative wiki and team workspace. Atlassian describes it as “your team workspace for creating and sharing knowledge” and also markets it under wiki use cases as “The original Wiki.” Additionally, the company has a page that describes Confluence as knowledge management software, which helps explain why organizations often blur the categories in the first place.

So yes, I should have said this more clearly: Confluence can support some knowledge management practices.

That doesn’t make it the same category of tool as a purpose-built component content management system.

The Problem Isn’t ‘Confluence Bad, CCMS Good’

Let’s get the lazy argument out of the way. The problem is not “Confluence bad, CCMS good.”

A well-governed wiki may outperform a poorly governed CCMS. No argument from me. I’ve seen expensive systems become beautifully structured disasters because no one wanted to make hard decisions about ownership, authority, metadata, workflow, reuse, review, or retirement.

That’s the point technical writers need to hold onto.

Governance determines whether the system succeeds.

The platform determines which governance model is practical, enforceable, scalable, and economically sustainable.

Those are not the same claim.

A Wiki Usually Manages Pages — A CCMS Manages Content Components

A collaborative wiki usually organizes content as pages. Teams create pages, edit them, and link them to other pages. They may also use the wiki to comment on pages, search them, and sometimes archive them if the organization using the wiki is unusually disciplined (or frightened by auditors).

That page-based model works well for many kinds of collaboration. It’s great for meeting notes, project planning, informal docs, lightweight processes, internal updates, and shared workspaces where the main goal is to get people contributing quickly.

But tech docs often requires different content models.

A component content management system manages content in smaller, structured, reusable units. Paligo describes a CCMS as software for “creating, managing, and publishing technical documentation through reusable content components,” where content is built from individual elements that can be assembled and reused across publications.

That difference is not academic. It changes what a system can do.

In a CCMS, a warning, prerequisite, troubleshooting step, safety statement, API parameter description, legal disclaimer, product specification, or reusable procedure can be managed as a component rather than as copied text scattered across a collection of hypertext-linked pages.

When the source component changes, the change can flow to every publication where that component appears. That’s not just “better governance.”

That’s a dramatically different technical capability.

Transclusion Isn’t ‘Exactly’ The Same Thing As Systematic Reuse

This is where the conversation gets more interesting. Someone might say, quite reasonably: “But wikis can do reuse. They can transclude content.” That’s true.

Transclusion is a mechanism. It allows one piece of content to appear inside another piece of content by reference. The source content lives in one place, and other pages display or publish it as though it lives there too.

That’s useful. It is much better than copy and paste. It can reduce duplication. It can help teams maintain shared content more consistently.

In the book, The Language of Technical Communication, Eliot Kimber explains that

Transclusion is not exactly the same thing as systematic reuse.

Ann Rockley’s concept of systematic reuse is broader. In Managing Enterprise Content, Rockley distinguishes systematic reuse from opportunistic reuse. Systematic reuse is planned.

That distinction matters.

Transclusion asks: “Can I include this content over there?”

Systematic reuse asks: “How do we design, govern, track, update, assemble, translate, and deliver reusable content across the entire content lifecycle?”

Those are related ideas, but they are not identical.

A wiki with transclusion can include content by reference. A CCMS is usually built around systematic reuse as an operating model.

That means reusable components aren’t just snippets that appear in multiple places. They are governed units of content with structure, metadata, ownership, version control, lifecycle state, translation status, and publishing behavior.

For tech writers, that difference matters because reuse isn’t just a convenience. It’s a control strategy.

Copy-and-Paste Reuse Isn’t Efficient Reuse

This is one of the places where the wiki-versus-CCMS distinction becomes obvious.

In a wiki, reuse often happens through copying, linking, embedding, transcluding, or manually referencing another page. Depending on the wiki and configuration, teams may create clever reuse patterns. Some teams do this well.

But in many organizations, not so much. Reuse becomes copy-and-paste focused. Someone writes a warning in one place. Another writer copies it into a second procedure. A third person revises it for a different product.

Six months later, support asks which version is correct. Nobody knows. Someone says, “Check Slack.” A small bird flies into a window. 🪟

A CCMS approaches reuse differently. It can track the source component, where that component is reused, which version appears in which publication, and what must be updated when the source changes.

That matters for documentation pros because we are rarely managing one page at a time. Typically, we’re managing content across products, versions, audiences, channels, languages, regions, and release cycles.

Those are related activities, but they are not the same activity.

Structure Isn’t Decoration

Another difference is structured authoring. In a wiki, structure is often social. Teams agree to templates, labels, page hierarchies, naming conventions, and review practices. That can work, but much of the — a-hem — enforcement depends on human discipline.

In a CCMS, structure can be built into the authoring model. This means the system can enforce rules about what kind of information belongs where. A task can require steps. A concept can be kept separate from a procedure. A warning can use a defined structure. Metadata can be required before publication. Content can be validated before it goes downstream.

For tech writers, this is especially important in AI-enabled environments. When our content is ambiguous, inconsistent, duplicated, or poorly typed, AI systems have to infer what the content means. They have to guess whether something we typed is a concept, task, warning, exception, prerequisite, policy, release note, workaround, or obsolete instruction.

Sometimes the system guesses correctly. Sometimes it produces confident nonsense.

The more explicit the structure, the less the system has to infer. And the less it has to infer, the better chance we have of getting accurate, grounded answers.

Delivery Is Part Of System Design, Not An Afterthought

Collaborative wikis are often strong at internal authoring and knowledge sharing. They help people easily create and find pages. They support quick collaboration, comments, permissions, search, and history.

Those are useful capabilities. But documentation often has to go further.

A CCMS is usually specifically designed not just to store content, but to publish it in multiple forms: help sites, PDFs, portals, knowledge bases, release packages, training materials, in-product help, support content, and other outputs.

Related reading: Multi-channel publishing

That publishing model matters.

A tech docs team may need to deliver different versions of the same core content to different audiences. Administrators get one version. End users another. Partners get a slightly different version. Regulated markets need region-specific language. Enterprise customers need content for supported versions. Internal support teams may need additional troubleshooting details that should not appear in public documentation.

In a wiki, those variations often become separate pages, labels, manual conventions, or permission schemes.

In a CCMS, those variations can be managed through structured reuse, profiling, filtering, conditions, metadata, and publishing rules.

Again, this is not just governance. It’s governance made operational through system capability.

Localization Exposes The Difference Quickly

Localization is another place where the distinction becomes hard to ignore.

If your docs lives as pages, translation often happens at the page or document level. When content changes, you may need to determine what changed, where it changed, whether the change affects translated content, and which language versions need updates.

In a component-based system, the unit of management can be (and typically is) smaller. If only one reusable component changed, only that component may need translation. If the same component appears in multiple outputs, the translation can be reused as well. That can significantly reduce cost, improve consistency, and shorten translation cycles.

It also reduces the risk of slightly different versions of the same instruction appearing across products, regions, or languages. For global tech docs teams, that’s not a minor feature — that’s operational infrastructure.

Byron Is Right About The Organizational Problem

The strongest part of Byron’s argument is the part documentation teams should not ignore: Documentation problems are often organizational problems.

I agree.

Tools cannot:

👉🏼 decide who owns a procedure
👉🏼 decide when content becomes obsolete
👉🏼 force product managers to stop treating documentation as a release-day garnish
👉🏼 create a culture that rewards maintainability, clarity, and reuse

If an organization doesn’t value documentation governance, a CCMS won’t save it. Neither will docs-as-code or an AI chatbot with a soothing interface and a suspiciously cheerful answer to everything.

Doc teams need ownership models and review cadence. They need taxonomy and metadata discipline. and rules that govern content throughout its lifecycle. And, they need to put in place incentives that reward reuse and maintenance, not just new content production.

That is the foundation. Byron is right to insist on it.

But Tool Category Still Matters

Where I differ from Byron is that I don’t think tool category is secondary to the point of irrelevance. Platforms shape what’s easy, what’s difficult, what’s enforceable, and what is likely to happen under pressure.

And pressure is where documentation systems reveal themselves.

👉🏼 When the release is late, do writers reuse approved content or copy and paste from the nearest page?
👉🏼 When support finds an error, can the team update one source component or hunt down every duplicate?
👉🏼 When legal changes a required statement, can the team trace every place it appears?
👉🏼 When a product has three supported versions, can the team publish version-specific content without maintaining three separate page forests?
👉🏼 When AI retrieves content to answer a customer question, can it tell which content is current, authoritative, audience-appropriate, and product-specific?

Governance defines the desired behavior. The system determines how much effort it takes to behave that way. That’s why tool category matters.

Hopefully, A Better Way To State The Argument

After reading Byron’s comment, I’d restate my argument this way:

Then they act surprised 😱 when those systems cannot provide the same control, reuse, traceability, lifecycle management, localization support, and multi-channel publishing capabilities as systems built for those purposes.

Confluence can be a good fit for small teams, internal collaboration, project knowledge, lightweight documentation, and shared workspaces. A self-hosted wiki may also be a good fit for organizations with the engineering capacity to maintain it, customize it, secure it, and govern it properly.

Byron is right to point out that SaaS platforms bring real costs, including per-seat pricing, vendor roadmap dependency, migration complexity, and data control concerns. Those tradeoffs deserve serious discussion. But none of that changes the underlying distinction.

A collaborative wiki and a CCMS are different categories of tools. One is primarily optimized for collaborative knowledge creation and sharing. The other is designed to manage structured, reusable, governed content components through complex creation, review, translation, versioning, and publishing workflows.

You can govern a wiki well. You can also govern a CCMS badly. And, you can use transclusion in a wiki and still not have a systematic content reuse strategy you can depend on. 🤠

Silence follows. Not normal silence. Corporate silence.

Documentation Chaos Rarely Looks Expensive At First

This is how operational inefficiency announces itself inside technical documentation teams. Not dramatically. Not with alarms. Not with smoke pouring from the walls. It arrives quietly, disguised as “the way we’ve always done things,” right up until the organization realizes it’s spending enormous amounts of money compensating for chaos nobody formally agreed to maintain.

A writer spending twenty minutes hunting for the latest approved procedure doesn’t sound catastrophic. An engineer answering the same support question for the ninth time this week seems manageable. A product manager manually reconciling conflicting documentation versions before release feels annoying but survivable.

Then the organization repeats those activities thousands of times a year.

Suddenly, entire salaries disappear into administrative fog.

The Shared Drive Is Not A Strategy

Tech docs teams often exist in places where every other department evolved operationally while documentation was left sitting beside the highway holding a three-ring binder and blinking into the sun.

Engineering has automation pipelines. Security has governance frameworks. Infrastructure teams have observability dashboards that resemble NASA launch controls.

Meanwhile, the documentation operation may still rely on filenames like: FINAL_v2_USE_THIS_ONE_REAL.docx

There’s always at least one of those. Usually seven. Maybe eight.

Skilled Workers Shouldn’t Be Content Janitors

PagerDuty’s research on operational inefficiency emphasizes the cost of downtime, repetitive work, technical debt, and highly skilled employees spending time on preventable friction.

Tech writers understand this instantly because many of us spend absurd amounts of time doing work that has almost nothing to do with writing.

We’re reconciling duplicate content, chasing approvals, rebuilding broken publishing workflows. And, in our copious free time — ha! — we manage to find space to copy and paste information between systems that absolutely should’ve been integrated sometime during the first iPhone administration.

As highly trained knowledge pros, we end up functioning like anxious wedding planners for content nobody wanted to govern properly in the first place.

The Buckets Were Never The Roof

Organizations convince themselves this arrangement is “cost effective” because they delayed purchasing better systems or avoided operational redesign. This is a little like refusing to repair our roof because buckets are technically cheaper.

Sure. For a while. Then mold arrives.

Documentation Bottlenecks Become Business Bottlenecks

The downstream effects spread everywhere. Our support teams inherit the confusion first because customers always discover content problems before executives do.

Then, with good intentions, sales engineers start creating their own shadow documentation because they can’t trust the official versions and fear that it may hamper their ability to seal a deal. Training departments subsequently join in by inventing workaround content, while product teams answer repetitive questions that shouldn’t be eating up anyone’s time.

Eventually, the organization becomes a kind of accidental content hoarding operation where five departments maintain slightly different versions of organizational “truth.”

Then AI Walks Into The Mess

For years, humans compensated for operational dysfunction through instinct and memory. Someone always knew where the “real” answer lived. Someone remembered which warning was outdated, understood that the installation procedure only worked if you ignored steps four through six instead.

AI systems don’t possess this survival instinct. They consume whatever content ecosystem exists in front of them with the confidence of a suburban dad assembling patio furniture without reading instructions.

If the source material is fragmented, inconsistent, duplicated, outdated, or poorly governed, AI scales those problems beautifully and rapidly; at enterprise speed.

AI Readiness Is Really Content Operations Readiness

Organizations everywhere are now discovering that “AI readiness” doesn’t merely involve purchasing software licenses and holding inspirational town halls about innovation.

It requires operational maturity. Governance. Metadata discipline. Clear ownership. Structured workflows. Lifecycle management.

In other words, all the things documentation teams have been trying to explain politely for the past fifteen years while someone from procurement asked whether Markdown could “just handle most of this.”

Related reading: How to Build a Content Operation

Burnout Is An Operational Signal

Operational immaturity also creates a human problem companies routinely underestimate. Burnout.

Documentation burnout is quieter than someone throwing a badge onto a conference table before storming out into the rain. It accumulates slowly through endless context switching, duplicate work, approval bottlenecks, emergency publishing requests, and systems that behave like abandoned carnival rides.

People stop feeling strategic. They start feeling administrative. Worse, they start feeling invisible.

Functional Enough Is Where The Money Goes To Die

The most dangerous documentation operations aren’t the obviously broken ones. Those are easy to identify. The dangerous ones are “functional enough.”

Functional enough to:

• avoid executive scrutiny

• limp through another release cycle

• keep producing outputs while quietly draining productivity (slowing onboarding, increasing support costs, weakening AI reliability, and exhausting the humans trapped inside the machine)

The Real Cost Is Paid Every Day

That’s the hidden cost of operational inefficiency. Not one catastrophic collapse. Just thousands of tiny operational taxes paid every day by people whose jobs could’ve been dramatically easier if someone had treated documentation content operations like infrastructure instead of decorative office shrubbery.

Eventually organizations realize the truth. They didn’t merely build a documentation team. They accidentally built a sprawling enterprise knowledge system held together with Slack threads, tribal memory, and emotional optimism.

And now AI is reading all of it aloud. 🤠

Then they’ll ask which source it used, whether that source was current, who approved it, whether it had been translated, rewritten, reused from another product, or lightly “improved” by someone who was mostly trying to get to lunch.

That’s when metadata starts looking a little lonely.

While Metadata Helps Us Find Things‚ Paradata Helps Us Explain Them

Tech writers have spent years learning to care about metadata. We tag content by product, audience, version, region, language, task type, and anything else we can persuade the system to remember.

That work matters. Metadata helps content move, surface, filter, and behave like it was raised properly.

But metadata doesn’t tell the whole story.

It can tell you that a topic is for administrators using version 6.2 in North America. It usually won’t tell you that the topic was stitched together from old release notes, edited by three people, reviewed after a support escalation, machine-translated, rewritten with AI, and approved by someone who clicked the button because the meeting was starting.

That missing story is paradata.

Paradata Is Our Content’s Backstory

Paradata is info about the process behind the content. It tells us (and the machines upon which we rely) how something was created, reviewed, revised, transformed, approved, reused, translated, or generated. It’s not the content itself. It’s not just the labels around the content. It’s the trail of decisions and actions that explain how the content became what it is.

Paradata is the receipt. And our documentation needs receipts now.

Read more

We open our repository and think, “This is it! This is awesome. It’s exactly what we need today.”

And then time passes. ⏰ Quietly. Patiently. Like a houseplant you forgot to water.

What Metadata Rot Looks Like When It Sneaks Into Technical Documentation

Metadata rot sounds technical, but it’s not.

It’s what happens when the labels, tags, and descriptors attached to our technical documentation stop reflecting reality. The product names change, but the tags don’t. The audience shifts, but the metadata keeps insisting this guide is “for beginners.” Versions drift. Status labels lie.

Nothing breaks all at once. Instead, our doc set slowly becomes a beautifully organized record of things that are no longer true.

How Metadata Rot Happens

It usually starts with good intentions and a meeting that includes the word “governance” said with a straight face.

👉🏼 There’s a taxonomy
👉🏼 There are required* fields
👉🏼 Someone even makes a slide about “future-proofing”

And, here’s the important part —> for a while, it works.

👉🏼 Then deadlines show up
👉🏼 New features ship
👉🏼 Someone clones an old topic and forgets to update the metadata (oops!)
👉🏼 Another writer picks the closest tag and hopes for the best 🤞

The taxonomy doesn’t evolve because nobody owns it anymore — or worse, everybody thinks somebody else does. And just like that, our docs become less of a system and more of a suggestion.

Read more

It is tempting to look at AI when things start to feel inconsistent. The outputs are uneven. Sometimes outdated. Occasionally just wrong. The natural reaction is to focus on the technology. Improve the model. Refine the prompts. Invest in better infrastructure. I had a version of that reaction myself when generative AI first emerged. After spending years building businesses around content and knowledge management, my initial instinct was that this shift might disrupt everything. But the more I worked with these systems, the more it became clear that AI was not introducing a new problem. It was exposing one that had been there all along.

Most organizations have been operating with fragmented knowledge for years. Different teams maintain different versions of the same information. Content gets updated in one system and missed in another. Context evolves, but documentation often stays frozen in time.

Over the past twenty five years, working with enterprises on knowledge management and content strategy, I have seen this pattern repeat itself in different forms, but with the same underlying issue.

People adapt in practical ways

They ask colleagues instead of trusting systems. They may keep their own notes. They often build informal sources of truth that feel more dependable than the official ones. These workarounds keep things moving, but they slowly erode confidence in the systems that were meant to support them.

When AI enters that kind of environment, it behaves very differently than a person would. It does not navigate uncertainty. It tries to resolve it. It pulls from multiple sources, reconciles conflicting inputs, and produces an answer with confidence. That is where the issue becomes visible in a way it never was before. The uncertainty that used to sit quietly in the background is now embedded directly in the output. And people notice.

Most organizations respond by trying to improve how information is structured. They invest in better organization, better retrieval, more sophisticated systems. All of that matters. But it rests on an assumption that often goes unchallenged, that the underlying information is correct. In my experience, that is rarely the case. The real gap is not structural. It is factual. Which statements are accurate, which are outdated, and which are missing context that changes their meaning. Until those questions are addressed, AI will continue to reflect the inconsistencies within the knowledge it consumes.

[Webinar] Destroy Enterprise Knowledge Chaos for Hallucination-Free GenAI

This is where the idea of Truth Curation begins to take shape. Not as another layer of organization, but as a process for validating what is actually true across an organization.

AI can be used to scan content at scale and surface conflicts, inconsistencies, and gaps. It can highlight where information does not align or where context is incomplete. But resolution still depends on human judgment.

Subject matter experts step in to validate, revise, and align what the system surfaces. They update what is incorrect, clarify what is ambiguous, and remove what is no longer relevant. It becomes a more focused use of expertise, applied where it has the most impact.

What follows is not dramatic, but it is meaningful. Employees begin to trust the systems they rely on. They spend less time double checking information. They rely less on informal workarounds. And AI starts to perform the way it was expected to, not because the model changed, but because the foundation did.

After more than two decades working at the intersection of knowledge management and AI strategy, this is the pattern I keep coming back to. Organizations do not suffer from a lack of information. They suffer from a lack of trusted information.

A useful shift in perspective is this. Instead of asking how to make AI more effective, ask whether the information it relies on is something your organization can confidently stand behind. That is where meaningful progress begins. 🤠

Jason Kaufman is an AI strategist, entrepreneur, and technical communication expert with more than 20 years of experience in knowledge management, enterprise AI integration, and content strategy. He is the CEO and co-founder of Zaon Labs and serves as President of Irrevo, where he helps organizations apply generative AI to content operations, enterprise knowledge management, and workflow automation.

Kaufman is a frequent speaker and educator on AI-enabled content strategy, prompt engineering, and the future of technical communication.

• Can customers search for it?

• Can support agents navigate it?

• Can the PDF open without Adobe Reader having an emotional collapse?

Meanwhile, AI showed up, kicked the office door open like a kangaroo hopped up on espresso, and changed the entire game.

Now the question isn’t whether humans can find the information we create. It’s whether machines can interpret it correctly before confidently lying to everyone.

That’s the hidden message buried inside Suraj Desai’s presentation on AI-powered retrieval systems.

At first glance, the talk looked deeply technical. Retrieval pipelines. Vector databases. Agentic loops. BM25 ranking. Taxonomy structures. Enough acronyms to make a tech writer briefly consider a career in artisanal candle-making.

But underneath all that infrastructure talk was something much more important:

Technical documentation is no longer just content. It’s training material for reasoning systems.

And if our docs are messy, ambiguous, contradictory, poorly structured, or missing context, AI systems don’t simply “struggle” with it. They hallucinate with confidence.

The LLM Likely Isn’t The Problem

One of the most important things Suraj said during the webinar was this:

“The LLM didn’t fail. The retrieval did.”

That sentence should probably be tattooed somewhere inside every enterprise knowledge management initiative currently stapling a chatbot onto ungoverned documentation and hoping for the best.

Because most AI failures in documentation systems are not actually language failures.

They’re retrieval failures.

The AI isn’t inventing nonsense because it woke up feeling creative. It’s inventing nonsense because the retrieval system handed it incomplete, conflicting, or irrelevant information.

In using traditional docs, humans compensate for weak structure surprisingly well. We:

• Infer meaning

• Notice context clues

• Realize “Paris” probably means France if the conversation is about European vacations

Machines don’t do that naturally. Which means every ambiguity tech writers leave in the docs becomes a possible retrieval failure later. And retrieval failures scale beautifully. That’s the terrifying part.

Read more

And then reality shows up, sits down across from us, and quietly explains that we’ve just become our own finance department, sales team, IT support desk, and emotional support animal.

Lauren Pope’s post — What being self-employed in content really looks like — pulls back the curtain on what self-employment in content actually looks like — not the LinkedIn version, the real one. For tech writers flirting with the idea of going solo, there are some lessons here you. Read these before you dramatically quit your job.

Lesson 1: Your Income Is Not Your Income

Freelance math is not normal math. We might invoice what looks like a comfortable annual income, but we’ll take home roughly half after taxes, expenses, and the need to survive slow periods.

Also, no one is quietly contributing to our retirement while we sleep, either. That’s now our job. Along with insurance. And software subscription costs that multiply like rabbits when we’re not paying attention.

Translation for tech writers: That shiny day rate you’re imagining? Cut it in half before planning your new life as a financially stable rebel.

Lesson 2: You Don’t Have Clients, You Have a Portfolio of Risk

You’ll rarely have one steady stream of work. More often, you’ll be juggling two or three projects at a time, trying to balance focus with income stability.

Too few clients? You panic.
Too many clients? You do bad work and still panic.

And the kind of deep, strategic work many tech writers aspire to — content models, governance, structured content — requires long stretches of uninterrupted thinking. That doesn’t pair well with a calendar that looks like a game of Tetris.

Lesson 3: Work Comes From People, Not Platforms

Forget the fantasy of “I’ll just hang out a shingle and clients will appear.”

Ha! Not so much.

Most work comes from:

• People who already know us

• People who’ve worked with us

• People who’ve read our stuff or who we’ve otherwise engaged

Word of mouth and reputation do most of the heavy lifting. Cold outreach? Advertising? Optional — and often ineffective depending on our niche.

Translation for tech writers: Our content isn’t just docs anymore. It’s marketing. Every blog post, webinar, or conference talk is quietly auditioning for our next client.

Lesson 4: The Market Doesn’t Care About Your Timing

We can be well-intentioned and do everything “right” and still have a bad year.

Budgets shrink. Strategy cycles end. Work dries up. We get sick. A project goes sideways and takes our sanity with it.

And here’s the fun part: when things go wrong, it feels personal. Because there’s no company to blame. It’s just us, staring at our insufficient pipeline of upcoming work.

Lesson 5: You Must Specialize

Pope’s work leans heavily into content strategy, even though she still offers related services. That’s not an accident — it’s survival.

Clients don’t buy “a technical writer.” They buy someone who solves a very specific problem.

Translation for tech writers:
“Writes clear documentation” is not a niche. “Designs scalable content models for API platforms” is getting closer.

Lesson 6: Pricing Is Part Courage, Part Therapy

Most freelancers undercharge. Especially early on. My advice? Charge as much as you can without feeling physically ill — and then maybe a little more.

But don’t be delusional. Benchmark against peers. Understand the market. Then push yourself anyway.

It’s a struggle for many of us starting out to avoid allowing personal price sensitivity to impact our feelings about our worth. Sometimes, freelancers I’ve mentored undervalue their expertise because what they think they should charge sounds expensive, so they opt to charge less thinking this is how they will get the gig (by not charging too much — whatever that is).

If we don’t price your time and talents wisely, we’ll quietly build a business that looks busy but pays like a hobby.

Lesson 7: You’re Not Escaping Work — You’re Redefining It

Self-employment isn’t less work. It’s different work. You’re still writing, designing, structuring, and solving problems.

But now you’re also:

• Managing cash flow

• Finding clients

• Negotiating contracts

• Deciding what work to take (and what to walk away from)

The upside? We get to shape our careers around our values, interests, and make decisions that don’t overwhelm our tolerance for nonsense.

The downside? We have to shape it. No one else is coming to do that for us.

What This Means For Tech Writers

Thinking about going freelance? Here’s the quiet truth:

We’re not just becoming an independent writer. We’re becoming a small business that also happens to produce content.

And the skills that will matter most aren’t just:

• writing clearly

• structuring information

• managing content systems

Instead, they’re:

• positioning our expertise

• building relationships

• managing uncertainty

• differentiating ourselves from the competitions

• pricing our value

• managing work-life balance

In other words, the work doesn’t get easier. It gets broader.

The Takeaway For Tech Writers

Self-employment can absolutely give us the career we wish existed. But it will also expose every weak spot in how we think about money, value, visibility, and resilience.

Which is why posts like this matter. They replace the unrealistic fantasy we conjure up ourselves with something far more useful: A map that says, “Yes, we can do this. But here’s what it actually costs.” 🤠

You search your internal docs in Attlassian Confluence and get six results. Three are outdated. One contradicts another. One links to a Slack thread from 2022 where someone named “Dan (Contractor)” says, “I think this is how it works?” The last one looks promising (until you realize it describes a feature your company quietly killed last quarter.)

So you do what everyone does. You ask for help in Slack.

Five people respond. Two disagree. One says, “Let me check.” Another drops a link… to one of the six pages you already read — the same one you linked to in your Slack query.

And just like that, your documentation system has completed its transformation from “source of truth” to “suggestion box.”

This didn’t happen overnight. It never does.

Why Confluence Worked (Until It Didn’t)

Let’s be fair. Confluence didn’t betray us. It did exactly what we needed at the time.

It’s fast and somewhat flexible. It lets pretty much anyone write nearly anything, almost anywhere, at any time. In the early days, that felt like progress. We were moving quickly, building features, hiring people, figuring things out as we went. Structure felts like a luxury we couldn’t afford back then.

And for a while, that was true.

When our team was small and our content footprint was manageable, we didn’t need governance (or so we thought); we needed speed. We wanted a place to put things so they wouldn’t disappear into someone’s brain forever.

Confluence was great at that. Right up until it wasn’t.

The Moment Things Start to Slip

The shift here is subtle. We didn’t wake up one morning and declare, “Our documentation system has failed us.” Instead, we started noticing small things.

People stopped trusting the docs. They began double-checking everything. They asked questions they shouldn’t have to ask and when they figure out what they needed to know they often created new pages in the wiki instead of updating old ones because it’s faster than figuring out what’s already there.

Our content was growing, but its usefulness wasn't.

That’s the moment our “flexible” system becomes an unmanageable one.

The Signs You’ve Outgrown Your Setup

What should we do, you ask? Well, first, we don’t need a formal audit to know something’s off. We just need to pay attention to the patterns that can help us identify the obstacles and challenges our internal documentation content hairball introduces.

Do we know if there’s a problem?

We can often easily see the signs of internal documentation problems. Docs contradict themselves. There’s no clear source of truth, just a collection of “maybe, probably correct” answers. Pages linger long after they’ve expired, like leftovers no one wants to claim. Subject matter experts rewrite entire sections instead of updating them, because it’s easier than untangling what came before.

Search becomes a scavenger hunt. Results are plentiful but not helpful. Navigation reflects how our org chart is structured, not how people actually think. Users bypass documentation entirely and head straight to Slack, where answers are fresher — even if they’re not better.

Scaling becomes awkward. The same information appears in multiple places because reuse isn’t a thing our team has made an effort to make systematic — it’s a wish, at best. Localization feels like a fantasy. Publishing content to different channels involves copying, pasting, and a quiet prayer that nothing breaks.

Governance, if it exists at all, is mostly implied. Anyone can publish anything. Review cycles are optional. Versioning is… optimistic.

And then there’s the AI problem.

We point a generative AI tool at our documentation, expecting magic. 🪄 What we get instead is a confident stream of half-truths, contradictions, and occasionally inspired fiction. The AI isn’t broken. It’s doing exactly what it’s supposed to do — summarizing messy and ungoverned input into equally messy output.

Turns out, chaos in equals chaos out.

What It’s Actually Costing You

Here’s the part no one likes to say out loud: we’re already paying for this problem.

We’re paying in time; every minute someone spends searching, second-guessing, or rewriting content that already exists somewhere. We’re also paying in expensive onboarding delays, as new hires struggle to separate fact from folklore.

And, we’re paying in support costs, because people can’t find answers that should be obvious. We’re also paying in product friction, when users don’t understand what we’ve built well enough to use it or explain it to others.

And if we’re exploring AI (who isnt?), we’re paying there, too; unreliable content doesn’t magically become reliable when we run it through a language model. It just becomes faster at being wrong.

So What Are “Professional Tools,” Really?

This is where people get nervous, because it starts to sound like a tooling conversation. And tooling conversations have a reputation for turning into expensive shopping trips.

But this isn’t about buying something shiny. It’s about capabilities.

At a certain scale, we need content that’s structured, not just written. Modular, not monolithic. Reusable, not endlessly duplicated.

We need workflows that ensure our content is reviewed, approved, and maintained; not just created and forgotten.

We need metadata and taxonomy so our information can be found, filtered, and delivered in ways that make sense to our users.

We need the ability to publish the same content across multiple channels without copying and pasting it into oblivion. And increasingly, we need content that machines can understand (not just humans) so AI systems can retrieve accurate, grounded answers instead of improvising and getting it wrong.

There are different ways to get there. Component content management systems. Docs-as-code environments. Knowledge delivery platforms.

The specifics matter less than the outcome.

We’re moving from “a place where we store information” to “a system that manages, governs, and delivers knowledge.”

Making The Business Case Without Sounding Like We Just Want New Toys

If we walk into a meeting and say, “Our team needs a new documentation platform,” we’ll get exactly the reaction we deserve. 🫤 Blank stares. Budget concerns. Someone asking if this can wait until next year (or the year after).

So don’t pitch a tool.

Start with evidence. Show the broken pages. The conflicting information. The Slack threads that exist because the docs failed.

Then translate that into cost. Not abstract cost — real cost 💰. Time lost. Support tickets created. Delays introduced.

Tie it to business goals like faster onboarding, improved customer experience, more reliable AI initiatives, or reduced support burden.

And for the love of all things sensible, don’t propose a massive migration as the opening move. Start small by piloting something. Prove that a better approach produces better outcomes by making the problem clearly visible to those who should care before trying to sell the solution.

A Quick Reality Check About Migration

Let’s not pretend this part is fun. Migration means cleanup and confronting the fact that some of our content shouldn’t make the journey. It means defining governance (where none existed before) and asking people to change how they work.

The reality here: There will likely be resistance. There’ll be moments when you question your life choices. But there’s also an upside.

Migration is the one time we’re allowed — expected, even — to fix what’s broken instead of working around it. And we don’t have to fix everything at once. In fact, we shouldn’t.

One Question to Ask Yourself Before You Do Anything Else

If our entire team disappeared tomorrow, would someone else be able to rely on our documentation to run the business? Not “eventually figure it out.” Not “after asking a few questions.” Actually rely on it.

If the honest answer involves Slack, guesswork, or crossing your fingers, well … there’s work to do.

The Quiet Shift No One Talks About

At some point, documentation stops being a side effect of building a product and becomes part of the product itself (whether anyone recognizes that or not). When that happens, the tools we use (and the way we manage content) stop being a convenience decision. They become a business decision.

And that’s usually right around the time Confluence starts to groan.

Not because it’s broken — but because we’ve asked it to do a job it was never designed to handle at scale.

We don’t notice the shift right away. We just feel the friction and watch as the extra minutes spent searching tick by. We also feel the second-guessing and the quiet erosion of trust, until one day, the system we relied on to keep us aligned is the thing slowing us down.

At that point, the question isn’t whether we need to change. It’s how much longer we’re willing to pay for not changing. 🤠