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

Their online courses walk through the fundamentals with clarity. They also include advice on working with large language models (LLMs). If you follow their guidance, your writing will likely improve. Your docs should become easier to read; your intent harder to misinterpret.

It feels like progress. And it is. But only up to a point.

The Subtle Shift No One Can Ignore

Tech docs have a new reader. Not a person skimming for answers while jumping between online meetings (and while distracted by a steady stream of Slack notifications) but a system that retrieves, assembles, and delivers those answers on demand.

The system does not read the way humans do. Instead, it predicts, reconstructs, and responds. It takes what you wrote and turns it into something else.

Google’s guidance helps us with that process. Clear sentences and logical and consistent content organization give the model something to work with. But clarity alone does not determine what the model produces.

That is where the gap begins.

When The Model Fills In The Blanks

Large language models are good at producing language that sounds correct. They’re less reliable when the source material is incomplete or inconsistent.

Unlike humans, when context is missing, the model does not pause and ask us for clarification. Instead, it proceeds full steam ahead.

Researchers at Stanford University have shown that models can generate citations that look real but do not exist. The titles and authors seem credible at first glance. The problem is the sources are fabricated, and far too often, completely detached from reality.

Other research shows that LLMs can explain what code does while missing why it was designed that way, because the reasons why weren’t captured in the docs to begin with.

Reporting from The New York Times has identified cases where AI assistants combine outdated and current info into a single answer without signaling the conflict.

These aren’t edge cases. They’re predictable outcomes. The model isn’t inventing problems. It’s exposing the gaps.

What Clear Writing Can And Cannot Do

I think Google’s guidance on clear sentences and organizing content is fairly solid.

• Clarity reduces ambiguity ✅

• Structure improves comprehension ✅

We know these things are required to produce usable docs. But, they’re not enough if we’re hoping they’ll help us obtain reliable AI output.

A polished sentence may still lack context. A neatly structured page may still leave out key constraints. And a clear explanation may apply only to one version, audience, or configuration without ever saying so.

LLMs do not know what we meant to include, but didn’t. It only works with what we provide it.

The Context That Never Made It Into The Content

This is where Google’s guidance starts to show its limits. The courses offered focus on how to write. They do not address how to encode meaning in a way machines can reliably interpret.

Consider metadata

Google tells us to define our audience, but not to encode that audience in a way that our systems can recognize and act upon.

Without metadata, important differences between user roles, product versions, and situations stay hidden. The model may blend them together into one answer that sounds correct but doesn’t really fit any of them.

Consider taxonomy

Google encourages clear headings (a solid suggestion) but does not address controlled vocabulary or semantic consistency.

People usually know when different words are just different outfits on the same idea. Dog, pooch, hound, pup, mutt — no one needs a crisis counselor to sort that out. Context does the work.

LLMs do not always manage that trick gracefully. Sometimes they treat minor wording changes as if the universe has shifted on its axis. Other times they blur important differences and act as though related terms all belong in one big semantic junk drawer.

Consider provenance

Google says to review AI output, but it doesn’t explain how to check where the source content came from, whether it is still valid, or whether anyone approved it. Without that information, old or unverified content can show up next to current guidance with no warning that it may be risky.

Consider content models

Google discusses organization at the document level, but not structure at the semantic level. A content model defines what types of content exist, what components they contain, and how those components relate. Without it, content remains a collection of pages. With it, content becomes a system that supports consistent interpretation.

A Familiar Scenario To Illustrate This Challenge

Imagine a doc set that includes a setup guide that someone wrote two years ago, a troubleshooting article you updated updated yesterday, and a release note explaining that the old instructions no longer work after a recent update.

Individually, each doc is clear and well written. None of them share consistent metadata, terminology, or version context.

Your user asks an AI assistant how to set up a feature. The assistant pulls info from all three documents and combines it into an answer that sounds clear and complete. But the answer is wrong for that user’s version, setup, or situation.

The problem isn’t that one document was badly written. The problem is that the content didn’t include the structure, labels, and context the AI needed to tell what applied and what didn’t.

Real-world example: [It] kept telling me that that I had to use this one envar to put the app in debug mode. But it wasn't working at all. So eventually I get around to looking deeper into it and it turns out that this method was used 2 versions prior to the current version. — GITHub post Very outdated answers and wrong suggestions everywhere

What Google Teaches Us — And What It Leaves for Us To Learn On Our Own

Google’s courses establish a baseline. They teach writers to produce content that is clear, structured, and easier to process. That baseline matters. Without it, nothing else works. Period.

But it fails to address the factors that determine whether AI-generated answers are accurate, consistent, and trustworthy. Those factors include structure beyond formatting, context beyond prose, and governance beyond editorial review.

They include decisions about how meaning is represented, how relationships are defined, and how trust is established. That work is not covered in the courses.

The Work That Now Defines Our Role

We tech writers have always been responsible for clarity. Now we’re also responsible for context. That includes making intent explicit, encoding meaning in ways machines can interpret, and ensuring that our content can be trusted when it’s retrieved, combined, and delivered outside its original form.

This isn’t a shift away from writing. It’s an expansion of what our writing must accomplish.

The sentence still matters. But the system that surrounds it matters more.

The Difference Between Readable Content And Trustworthy Content

Google will help you write docs that AI can read. It won’t help you create docs that AI can trust. And as AI takes on a larger role in delivering answers, that distinction moves from academic to operational. Those of us that recognize this distinction will design content accordingly. The rest of us will continue to wonder why their docs sound right but behave unpredictably. 🤠

▶️ Watch the entire interview (60 minutes, on-demand).

👉🏾 Users still need it.

👉🏾 Support teams still depend on it. A

👉🏾 AI systems are increasingly consuming it as source material

The need hasn’t disappeared. What has changed is the environment in which documentation gets created, maintained, delivered, and now interpreted by machines. That’s the central point Ondrej Tesar (documentation lead at Pricefx) makes in a recent LinkedIn post, and it’s a useful one.

Tesar argues that AI-assisted coding is accelerating software development while doc teams risk falling behind. He points to a structural asymmetry: software teams often benefit from cleaner, more machine-friendly inputs, while documentation work still depends heavily on context gathering, judgment, and knowledge that may not be fully captured in formal systems. He also argues that the hardest part of the work lives in the undocumented remainder: tribal knowledge, edge cases, and design rationale that do not show up neatly in publicly available product information.

That argument is directionally right, but it needs one important correction.

Not All Doc Teams Are Working From A Swamp Of Vague Jira Tickets

Not all documentation teams are working from a swamp of vague Jira tickets, random Slack messages, and whatever an engineer muttered before running to another meeting. Some teams have spent years building semantically structured, metadata-rich content operations using XML, DITA, controlled vocabularies, reuse models, governed workflows, and component content management systems.

Those teams aren’t merely “writing docs.” They’re building machine-processable knowledge assets. And in a world increasingly shaped by retrieval, summarization, answer engines, agents, and large language models, that matters a great deal.

This distinction isn’t trivial. It is the whole ballgame.

The Capability Multiplier: Semantic Structured Content

When docs are semantically structured, they become easier to retrieve, reuse, validate, govern, securely personalize, and transform. It becomes easier for both humans (and those pesky machines upon which we rely) to determine what a chunk of content is, how it relates to other chunks, when it applies, what conditions constrain it, and whether it belongs in a given output.

Structured content does not magically solve every documentation problem, but it gives us a far stronger foundation for solving them. That’s been true for years. AI just made the consequences easier for us to see.

Read more

That may sound less exciting than a keynote about AI reshaping civilization before lunch. But it has the distinct advantage of being true.

A great deal of productivity improvement can be achieved by removing friction from our work itself. Not from adding a robot on top of a mess and hoping — 🤞 — for the best. And, not from asking a language model to draft accurate prose while the rest of the workflow remains an obstacle course.

The good news is that tech writers have plenty of non-AI ways to work faster, more accurately, and with a lot less daily annoyance.

Start With The Repetition That Is Draining Your Soul

Take text expanders. They aren’t glamorous. Not at all! Nobody is going to introduce them onstage while dance music throbs and somebody from marketing uses the phrase “transformational workflow acceleration.” But they work.

If you regularly type the same product names, disclaimers, support instructions, links, trademark language, or stock email replies, a text expander can save time and reduce errors. Instead of retyping boilerplate from memory and making a fresh mistake because your brain checked out at 3:40 p.m., you type a shortcut and approved text appears instantly.

That’s not flashy; it’s helpful.

And text expanders point to a larger truth: if you keep writing the same things by hand, you probably don’t have a writing problem. You have a reuse problem.

Reuse Is Not Laziness. It Is Maturity.

Tech writers typically spend far too much time recreating material that should already exist as a reusable asset:

• Prerequisites

• Warnings

• Note language

• Standard procedures

• Product descriptions

• Related-links blurbs

• Release-note intros

If we rebuild that material from scratch every time, we’re wasting time and creating inconsistency at the same time, which is an impressively bad bargain.

It doesn’t matter much whether our tech docs team manages reuse through snippets, templates, shared files, a help authoring tool, or a component content management system, especially if you’re just getting started and your content maturity isn’t as mature as you’d like.

What matters is that repeated content gets treated as repeated content, not as a fresh creative-writing exercise every Thursday afternoon.

The fastest paragraph to write is the one you do not have to rewrite.

Related reading: Fundamental Concepts of Reuse (free, downloadable PDF chapter from the book, Managing Enterprise Content: A Unified Content Strategy by Ann Rockley, Charles Cooper)

Blank Pages Are the Enemy of Efficiency

Templates are another productivity tool that doesn’t get nearly enough love, possibly because they don’t sound innovative enough to attract a venture capitalist. 😆

But seriously, if your team routinely creates release notes, installation guides, API reference pages, migration instructions, troubleshooting topics, or knowledge base articles, nobody should be starting from a blank page every time like a settler arriving in an uncharted wilderness.

Templates likely reduce decision fatigue by eliminating unnecessary choices, lowering cognitive load, and acting as memory aids. While direct studies on content-creation templates are limited, adjacent research on choice overload, cognitive load, and checklists supports the claim.

That said, well-designed templates help writers move faster because the structure is already there. They also improve quality because they make it harder to forget the important stuff. If a good template includes fields for prerequisites, expected outcomes, permissions, dependencies, rollback instructions, or related links, we’re less likely to publish content that leaves our user stranded halfway through a task with the emotional support of a vague sentence and a screenshot from last year’s planned roll-out that never occurred.

Templates do not just save time. They help prevent rework.

A Style Guide Should Prevent Fights, Not Start New Ones

A practical style guide is another non-AI productivity booster hiding in plain sight.

Not the kind of guide that reads like it was written by an offended grammarian in a candlelit tower. The useful kind. The kind that answers real questions writers have every day. Do we bold user interface labels? How do we punctuate headings? What tone do we use in troubleshooting content? Do we write in second person? How do we refer to product features consistently?

When writers do not have to stop and guess, they move faster. When editors do not have to make the same correction over and over, they move faster too. When reviewers are not inventing their own editorial standards from the depths of their personal belief system, everybody suffers less.

A good style guide is not bureaucracy. It is a ceasefire agreement.

Video ▶️ Melanie Denise Davis (The AI Wrangler) interviews AI training specialist, Bill Raymond, about how AI can extract a style guide from existing docs and help refine, enforce, and reveal content gaps to address next

Terminology Chaos Is a Productivity Problem

One of the easiest ways to slow down a documentation team is to let terminology drift all over the place like a shopping cart in a windstorm.

If engineering calls it a workspace, marketing calls it a hub, support calls it an environment, and the documentation calls it a project, the user is going to assume the company is held together with staples and regret. Writers lose time every time they pause to wonder which term is correct. Editors lose time fixing inconsistent language. Reviewers lose time arguing about words that should have been settled long ago.

A shared terminology list helps writers draft faster, edit faster, and publish with fewer corrections. It also improves findability and makes content easier for users to understand.

Nope, it’s not thrilling. Yep, it matters a lot.

Read more

That’s why the 2026 State of AI in Technical Documentation report is worth a look.

The report offers a useful overview of the findings, including how technical writers are using AI currently, which tasks they support with it most often, and where adoption is still getting hung up on entirely reasonable concerns like trust, governance, and integration.

The findings are based on responses from around 400 technical documentation pros, and nearly half of those respondents have more than 21 years of experience in the field. In other words, this is not a pile of hot takes from people who discovered documentation last Thursday.

The overview makes one thing clear: AI use is no longer theoretical for technical writers. A large majority of respondents report using AI either regularly or occasionally, with current use concentrated around editing, drafting, rewriting, and summarizing content. At the same time, interest is growing in more operational uses, such as metadata tagging, content classification, terminology work, and content reuse. That gap between what teams are doing now and what they want to do next is where the interesting story lives.

Which is why the full report matters.

The summary gives you the headlines. The full report gives you the texture, the context, and the evidence you’ll want when somebody at work says, “So what should our documentation team be doing with AI?” It’s much nicer to answer that question with research than with the professional equivalent of shrugging in business casual.

If you work in tech docs and you’re trying to separate signal from nonsense, request the free report.

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. 🤠

“This AI workshop nailed the sweet spot between basics and hands-on practice. What made it really work? The instructor adjusted on the fly based on where we were. Every session delivered something immediately useful—which, let’s be honest, is rare.”
— Kat Reierson, Manager, Product B2B Documentation at Docusign

Let’s be honest. A lot of tech writers are already “using AI,” which often means poking at ChatGPT between meetings, getting a paragraph that is 70 percent useful, 20 percent suspicious, and 10 percent strangely eager to invent things that never happened. That is not a workflow. That is flirting with automation in public.

Bill Raymond’s AI Workshop for Tech Writers and Content Creators is a better alternative: a live, seven-session online course built to help content professionals use AI in ways that are practical, repeatable, and less likely to end in regret.

It is offered in partnership with The Content Wrangler, and the next workshop runs on Tuesdays from April 28 through June 9, 2026, and costs $1,749 before discount.

Additional 2026 class dates:

• Summer — Tuesdays July 14 — August 25

• Fall — Tuesdays September 15 - October 27

• Winter — Tuesdays November 3 - December 22

💰 You can save 10% off the cost of registration when you use discount code — TCW — at checkout.

Register

Don’t Let This Opportunity Pass You By

What makes this course worth a second look is that it’s aimed at people who do actual content work, not people who enjoy saying the word “disruption” as though it were a sacrament. Raymond says their workshop is for technical communication and documentation specialists, content strategists, and knowledge teams trying to modernize workflows with AI.

The stated outcomes are practical:

• automate repetitive production tasks

• tailor AI output to fit voice and terminology

• and connect content choices to user journeys, measurable outcomes, and ROI

In other words, less behold the future and more please help me get this draft, audit, or rewrite done without sacrificing my dignity.

What You’ll Learn 📖

👉🏼 Week 1 covers AI foundations, ethical guardrails, and prompt basics.

👉🏼 Week 2 moves into personas and audience journeys.

👉🏼 Week 3 focuses on personalization, controlled prompts, and custom GPT instructions.

👉🏼 Week 4 tackles workflow bottlenecks and content ROI.

👉🏼 Week 5 looks at gap analysis, research angles, and drafting.

👉🏼 Week 6 shifts to prioritization using customer insight and advanced prompting.

👉🏼 Week 7 ends with final project presentations and a roadmap for ongoing AI-enabled content operations.

This workshop promises persona-driven workflows, ready-to-use prompt libraries, custom GPT instructions, evaluation checklists, and a documented project plan for AI-assisted content production.

Participants also complete hands-on exercises and receive a digital certificate of completion after presenting their final project. For tech writers, that matters. If you’re going to spend money on training, it should produce something sturdier than inspiration and a notebook full of underlined buzzwords.

About The Instructor

Bill Raymond is the founder and lead instructor at Cambermast and says he helps teams put AI to work quickly and responsibly, with training that is hands-on, practical, and focused on immediate next steps. He’s worked with organizations such as Microsoft, NASA, DocuSign, Duke Energy, SLB, Moen, Digital.ai, and Red Hat.

“Bill made it easy to show up and learn. He tailored each session as we went, kept things grounded and practical, and somehow made AI feel way less intimidating. I left with skills I could use right now—and a head full of ideas.”
— Kat Reierson, Manager, Product B2B Documentation at Docusign

The Underdog of Learning Resources

The 2025 Developer Survey paints an interesting picture. You’ve got your standard array of learning tools — Stack Overflow, blogs, online courses, and of course, videos. But lurking quietly in the background, capturing the attention of a staggering 68% of respondents, is technical documentation. It’s the often underappreciated rock star in a world obsessed with quick fixes and instant gratification.

Let’s break it down. Of the 33,454 developers who were polled (76% of them being the true “professional” variety and an additional 15% falling into the aspirational or adjacent developer category) there was a strong consensus. You need technical documentation to learn how to code. Let that sink in.

It’s clear we tech writers are holding the reins of knowledge, quietly helping software developers avoid the chaos of poorly understood libraries and buggy frameworks.

The Developer’s Best Friend: Technical Documentation

Now, we all know that developers have a way of loving their code more than they love life itself. 😆 Still, these same developers (mostly aged between 25 and 44) are relying on our docs to make sense of their tools, libraries, and frameworks. There’s a good reason why a significant 68% of survey respondents preferred it over other resources. It’s simple. It works.

While Stack Overflow answers might solve an immediate issue, they don’t explain why things work the way they do (and even when they do, there’s no guarantee it'‘s accurate). Enter technical documentation (the unsung hero of the coding world). Developers, especially those with less than 10 years under their belts, might not be able to remember every edge case for every function call, but the doc we produce help them get it when it matters most.

It’s the difference between frantically Googling “why does my program crash every time I try to run it?” and confidently consulting well-organized reference material that tells you what you’re doing wrong and how to fix it. It’s like the difference between using a map and wandering aimlessly.

Why Documentation Is the Bedrock of Success

Okay, I’ll admit that documentation isn’t exactly the glamorous, party-loving cousin of a slick YouTube tutorial or a rapid-fire Stack Overflow answer, but it is where foundational knowledge lives. For most developers, especially those in the 35% who have been coding for fewer than 10 years, learning to code with solid documentation means building a robust, scalable understanding that no quick fix or trendy blog post can replace.

The Case for Appreciating Technical Writers

So, dear tech writers, it’s time we stand tall and claim our rightful spot at the table of essential resources. Developers might use other tools for a quick fix, but when it’s time to dive deep into understanding and mastering a framework, they’re coming to us. Documentation isn’t just a reference; it’s the bedrock of their continuing success.

And to all the developers reading this: Next time you’re diving into a technical topic, remember that the person behind those docs aren’t just throwing a bunch of words into a file. They’re saving your proverbial butt one detailed, well-organized, thoroughly tested section at a time. And in a world where most things come with a “don’t ask, just Google it” disclaimer, isn’t that worth a little appreciation? 🤠

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. 🤠

You’ll hear from an impressive group of experts, including Suraj Desai of Digg, Erin Servais of AI for Editors, Dominik Wever of Promptitude, Sarah Johnson of Content-first Design, Mark Wentowski of Docs Geek, and Jerry Bartlett of Content Pro Tech.

Everyone who registers gets access to the recording after the live broadcast ends. That means even if you can’t attend live, you should still register so you can watch the on-demand version whenever it suits your schedule. And if one hour of learning is never enough, The Content Wrangler webinar channel already hosts more than 800 recorded one-hour educational events for technical writers and other content professionals.

🗓️ [April 7] How AI-Powered Content Retrieval Actually Works

Join Suraj Desai, Lead Data Scientist at Digg, as he demystifies how modern AI-powered retrieval actually works. You’ll gain a clear understanding of semantic search, embeddings, and hybrid architectures—explained in plain language with no jargon or technical prerequisites required. Drawing from real-world experience building large-scale discovery systems, Suraj will show you how these tools connect people to the right information at the right moment.

Register

🗓️ [April 8] Right-Size AI: Tips and Tricks For Solo Writers and Small Teams

On this episode of "Let's Talk AI," show host Melanie Denise Davis will chat with Erin Servais, founder of AI for Editors and Servais Training Company, about practical ways to leverage your existing skills — like pattern matching, technical interviewing, and content analysis — to make AI work for you, even without the resources of an enterprise.

Register

🗓️ [April 9] AI Adoption in Technical Documentation: 2026 Survey Breakdown

Join Dominik Wever, Founder of Promptitude, as he breaks down what hundreds of experienced practitioners reveal about their real-world use of AI tools, the challenges they encounter, and where they see the greatest opportunities for improvement.

Register

🗓️ [April 9] A Framework For Untangling Messaging Misalignment

Join Sarah Johnson, Founder and Strategic Consultant at Content-first Design, as she introduces the content-first double diamond framework — a practical approach for stopping meaning drift before it disrupts your user experience. You’ll learn what meaning drift is, why it happens, and how unchecked misalignment in messaging impacts both customers and teams.

Register

🗓️ [April 21] From Content Chunks to Traceable Knowledge

In this session, API Documentation development expert, Mark Wentowski, will share a small prototype that experiments with a different approach. Instead of breaking documents into fragments, it starts from structured sources (such as API specifications) and preserves the relationships already present in that information. This allows AI-generated answers to be traced back to the underlying source and structure.

Register

🗓️ [April 30] What Online Music Metadata Teaches Us About Content

During this episode of Coffee and Content, discover the hidden layers of digital music and how metadata shapes your listening experience. Jerry Bartlett, Content Operations Consultant at Content Pro Tech, will reveal why even simple questions (like when the Beatles’ first LP was released or where to file Daft Punk) can lead to confusion without expert guidance.

Register

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

Technical writers spend a great deal of time explaining complex things to other people, usually while being misunderstood by at least one executive, two engineers, and a product manager who believes documentation “just sort of happens.” So it is nice to see a podcast that appears to understand the job is not merely typing near software.

Behind the Docs is aimed at the people — you —who make technical content work in the real world. That means conversations about documentation strategy, structured content, AI, scaling content operations, customer knowledge, and the other matters that tend to determine whether a documentation team is treated like a business asset or an afterthought with a style guide.

Find the show here:

A Guest Line-Up You Will Appreciate

What makes the podcast especially appealing is the guest lineup it has already pulled together.

Manny Silva talks about documentation as a system, with discussion around automated workflows, AI-assisted style enforcement, and doc testing.

Sara Feldman gets into knowledge-centered service, intelligent swarming, and why a solid knowledge foundation matters a great deal more than whatever shiny AI object is currently being waved around in the boardroom.

Melanie Denise Davis explores clarity, structured content, AI readiness, and the ongoing need to remind the world that technical communicators are not, in fact, glorified typesetters.

Other guests push the conversation even further beyond “how to write a better sentence,” which, let’s be honest, is only one small corner of the mess.

Dave Koelmeyer looks at why tech writers might better be understood as knowledge engineers.

Jarod Sickler digs into structured content, CCMS adoption, reuse, and the growing reality that documentation is not just support material anymore. It is part of the product experience.

Sandie Markle and Laura Minaie bring in practical perspectives on content engineering, DITA migration, scaling operations, and future-proofing the work before the next wave of chaos arrives wearing a cheerful badge that says innovation.

That range matters. Too many podcasts for content pros drift into vague motivational soup. This one appears to stay grounded in the real mechanics of documentation work: systems, governance, scale, clarity, and the awkward but unavoidable collision between content and AI.

So yes, you should give Behind the Docs a listen. Not because podcasts are magical. Not because listening to smart people talk will solve your metadata problems. But because hearing experienced practitioners discuss the work with specificity, honesty, and a little strategic realism is often more useful than another LinkedIn post announcing that everything has changed forever. 🤠

That should sound familiar, because tech writers are supposed to care about exactly those things — and more.

A system may be logically designed. A workflow may be technically correct. A product team may insist the interface is “clear.” Meanwhile, the user is staring at a screen wondering whether clicking Save will publish the document, overwrite the document, summon legal, or end civilization as we know it. Phenomenology asks us to take that user experience seriously.

We need phenomenology because documentation is not just about describing how a system works from the inside. It is about helping someone navigate how that system appears from the outside, in real conditions, with limited context, imperfect memory, and a growing suspicion that every button has been named by a committee with boundary issues.

This matters because users do not experience products as architecture diagrams. They experience them as moments: confusion, hesitation, recovery, success, error, relief. Good documentation meets them there. It anticipates where they are likely to get lost, what they are likely to misread, and what they need in order to move forward with confidence.

In practical terms, phenomenology reminds us to pay attention to the user’s point of view, not just the system’s logic. It encourages us to write for the reality of use, not the fantasy of design. And that is important, because a procedure is only “clear” if it is clear to the person trying to follow it while three deadlines, two warnings, and one expired permission token are breathing down their neck.

Good documentation does not just explain the product. It respects the experience of using it. That is why phenomenology matters. 🤠

That may sound like philosophy-class material best left to people wearing scarves and speaking in paragraphs no one asked for. But tech writers deal with epistemology all the time.

Every time we ask a subject matter expert to verify a procedure, question whether two sources conflict, decide which version of the truth belongs in the manual, or try to separate official guidance from tribal folklore, we’re doing epistemic work. We’re not just writing things down; we’re evaluating claims, testing evidence, identifying authority, and deciding what the reader should be able to trust.

That matters even more now that AI systems increasingly consume and remix documentation. If the source content is vague, inconsistent, poorly governed, or based on undocumented assumptions, the machine may produce fluent nonsense with the confidence of a man explaining wine in a restaurant. Epistemology helps writers think more clearly about provenance, evidence, certainty, and trust.

In practical terms, tech writers need epistemology because documentation is not just about expressing knowledge. It is about deciding what knowledge deserves to be expressed, how firmly it can be stated, and what supports the claim. In other words, good documentation does not just tell users what is true. It helps ensure the truth has not been assembled from guesswork, vibes, and somebody’s half-remembered Slack message.

A strong documentation practice is, in part, a disciplined way of knowing. That is why epistemology belongs in the conversation. 🤠

It comes wrapped in unfamiliar tools, developer terminology, authentication workflows, JSON payloads, command-line examples, and enough Swagger-related vocabulary to make a sane person consider a career in artisanal candle making. But the truth is simpler: API documentation is learnable.

What most writers need is not magic 🪄. They need structured guidance, real examples, hands-on practice, and a chance to connect the abstract parts of API work to the documentation skills they already have.

That is why the Mastering API Documentation course from Docs Geek and The Content Wrangler looks worth serious consideration for tech writers who want to strengthen their skills and expand their value.

Learn More

The course is a 7-week live virtual class designed for technical communicators transitioning from UI to API writing, as well as developers, product managers, support specialists, and others who need to understand or document APIs. Each session runs about 90 minutes, for a total of 10.5 hours of classroom learning, plus 8 or more hours of offline exercises.

What Makes This API Docs Class So Valuable?

What makes this workshop especially appealing is that it doesn’t stop at theory. The course includes live instruction, hands-on assignments, a final quiz, and a final project in which participants create and submit an API documentation portal for peer review. By the end, students are expected to produce a complete documentation portal and get guidance on publishing it as a portfolio piece.

That matters. Learning is good. Leaving with something you can show to an employer or client is better.

What Does The Curriculum Include?

The curriculum also looks thoughtfully built for technical writers who want a practical ramp into API work. It starts with API basics and moves into JSON, Swagger UI, Postman, OpenAPI, YAML, Curl, authentication, query parameters, API flows, Mermaid diagrams, sequence diagramming, and refining API references.

In other words, it does not just explain what APIs are. It walks students through the tools, structures, and thinking patterns they need to do the work.

That learning progression is important because some of us aren’t actually starting from zero. We already know how to explain complicated things clearly. We already think about audience, structure, task flow, reuse, and precision. What we often lack is confidence with the tooling and the developer-facing context.

A course like this helps close that gap by showing how user journeys connect to API flows, how requests and responses behave, and how reference material should be written so developers can actually use it.

A Live, Instructor-Led Experience

Another strong selling point is that this is a live course, not just a pile of prerecorded videos abandoned in the digital wilderness. Participants get step-by-step joining instructions after purchase and access to a course Discord community for ongoing support and discussion. For many writers, that kind of interaction can make the difference between “I watched some lessons” and “I can now do this work.”

Classes Begin Soon — Don’t Delay!

There is also a practical reason not to sit on the decision too long. The Spring 2026 class registrations are open, the maximum student count is 30, and the sessions begin April 20, 2026, with weekly classes continuing through June 8, 2026.

If you have been thinking about moving from UI documentation into API documentation, or if you manage writers who need to build API skills, this workshop is a strong investment in capability. It is grounded, hands-on, and clearly designed to help people produce real work, not just collect new buzzwords for LinkedIn.

Use Our Discount Code To Save 💰

And here is one more reason to register now:

💰 Save 10% off the cost of registration when you use discount code — TCW — at checkout.

Register Today!

For those of us looking to become more versatile, more marketable, and more comfortable documenting modern software products, this is an incentive to stop circling the runway and finally get on the plane. 🤠

About the Instructor

Mark Wentowski is an API Documentation Specialist and senior technical writing consultant with more than a decade of experience helping software and SaaS companies create clear, effective developer documentation. His expertise includes API references, tutorials, conceptual guides, deployment and configuration content, and documentation strategy. As a consultant, speaker, and author focused on API-doc best practices, Mark brings both real-world experience and practical teaching insight to the workshop.

Some writers still cling to the quaint idea that documentation should be based on facts. These people are precious. They still believe “collaboration” means talking to engineers instead of receiving a vague ticket, two screenshots from a deprecated build, and a cheerful note from product saying, “This should be pretty straightforward.”

Straightforward. Ha! A marvelous word, usually deployed by someone who won’t be doing the work.

If we want to build a truly world-class documentation set without ever speaking to a subject matter expert, we must release ourselves from outdated burdens such as certainty, verification, and dignity.

Start With The Interface And Your Imagination

Open the product and begin clicking around with confidence. Not knowledge. Confidence. If a panel opens, document the panel. If an error appears, document the happy path anyway. Users enjoy optimism.

Don’t ask what a feature is supposed to do. That only invites facts, and facts are where timelines go to die. Instead, infer the product’s business logic from button labels, breadcrumbs, and whatever happened when you clicked Save. Think of yourself as an archaeologist reconstructing a civilization from a broken spoon and a warning message.

Use Old Screenshots Proudly

A lesser writer might insist on current screenshots because the interface has “changed completely” and “no longer resembles the documentation.” This sort of perfectionism is why projects slip.

Old screenshots have stability. They come from a simpler time, before someone moved every important function behind an unlabeled icon shaped like a nervous hexagon. If users can’t find the button, they will at least enjoy the thrill of personal discovery.

Documentation shouldn’t rob people of adventure.

Replace Interviews With Elegant Guesswork

Subject matter experts are forever cluttering the conversation with exceptions, dependencies, permissions, and other deeply inconvenient realities. You ask one innocent question and suddenly someone is explaining feature flags, environment variables, and why the workflow only succeeds if Mercury is in retrograde.

This is exhausting.

A better approach is strategic vagueness. Phrases like “if applicable,” “depending on your configuration,” and “contact your administrator” can carry astonishing amounts of institutional confusion. Passive voice helps too. “The necessary updates are made” is a lovely sentence because it avoids the awkward question of who, exactly, makes them.

Assume Every Workflow Is Linear and Beautiful

Real systems are messy. They branch. They fail. They depend on roles, conditions, approvals, and obscure prerequisites no one mentioned until the second draft. Subject matter experts love these details. It gives them a reason to live.

You, however, are writing world-class documentation. Your workflows should glide forward with the serene confidence of a swan and none of the frantic paddling underneath. The user clicks Save. A confirmation appears. Everyone is transformed.

Leave out the part where the integration token expires and the customer needs a permission no one knows how to grant.

Reuse Old Content As Sacred Text

Nothing speeds production like copying last year’s guide and changing only the nouns that now seem litigious. If the old content refers to menus that no longer exist or terminology abandoned three reorganizations ago, keep it. Legacy language builds character.

Some say outdated content erodes trust. I say it teaches users resilience.

Skip Meaningful Review

You could ask knowledgeable people to review the documentation, but that would require knowledgeable people to reply. Far better to send the draft to twelve stakeholders, give them two business days, and treat silence as approval. If someone complains later, note that the review window was open.

This is not blame redistribution. This is process maturity.

Be Wrong With Confidence

Above all, never sound uncertain. State everything firmly, as though the workflow has been handed down on stone tablets from the mountain of Product Truth. Users may forgive an incorrect step. They will not forgive hesitation.

And that, really, is the secret. Great documentation without subject matter experts is not about accuracy. It is about posture.

Of course, outside the spirit of April Fool’s Day, the truth is painfully obvious: good documentation requires conversation, verification, and access to the people who actually understand the product. But for one glorious holiday, we may honor the fantasy that screenshots, vibes, and nerve are enough.

They are not. But it is a charming delusion.🤠

Playlist? Really? A playlist is a cute little collection of songs your friend throws together for a Sunday BBQ. It’s a list, a simple order of tracks (nothing more). A DJ-made continuous mix, on the other hand, is an art form. It’s hours spent carefully selecting, adjusting, layering, and transitioning music so that it all flows like a well-timed, pulse-pounding journey. It’s a seamless experience where the energy never drops, where every beat feels intentional, where you barely notice the transition from one track to the next.

But say “great playlist” and you’ve just insulted hours of work, practice, and skill.

Now, let me tell you something: technical writing is exactly like that.

Why People Get It Wrong

People think writing technical writing is just typing. You’ve got a keyboard, some words, maybe a style guide, and boom, you’re done. Right?

No. That’s like saying a DJ just hits play and calls it a night.

Tech writers don’t just type. We spend hours assembling and refining content — asking questions, interviewing subject matter experts, navigating contradictory information, trying to make sense of a product that’s been described by six different people in eight different ways. We sift through jargon, eliminate unnecessary fluff, and figure out how to explain complex ideas in ways that won’t make the reader throw their laptop out the window. We are the architects of clarity, the curators of context, the sculptors of structure. And none of it is magic.

Yet, when people see a finished manual or help article, they think we’ve simply “written something down.” It’s like calling a perfectly executed DJ mix a playlist (oversimplified, dismissive, and completely missing the point.)

Read more

Most people weren’t.

That matters, because if you work in tech comm, those two words now describe a fault line running straight through our profession. If we don’t understand the difference, we risk misunderstanding what AI is good at, what it is bad at, and why it sometimes produces polished nonsense with the confidence of a middle manager explaining a spreadsheet he did not build.

Two Words That Explain A Lot

Let’s start simply.

👉🏾 A deterministic system produces the same output every time, assuming the same input and conditions. You press the button, and it behaves as expected. Again. And again. And again.

Deterministic systems are governed by fixed rules. Traditional software functions often work this way. If a user enters a valid password, the system grants access. If they do not, it refuses. No soul-searching. No improvisation. No jazz hands. 👐

👉🏾 A probabilistic system works differently. It produces results based on likelihood, not certainty. It makes predictions about what output is most likely to fit the input. Large language models do this constantly. They do not “know” the next word in the way a database knows a customer ID. They generate language by calculating which sequence of words is most probable based on patterns learned from training data.

That means a probabilistic system can produce different (think “inconsistent”) outputs from the same prompt. It can sound sure while being wrong. It can be useful, impressive, and fast. It can also make things up that are untrue.

And there, at last, is the neighborhood where we tech writers now live.

Why This Distinction Matters In An AI-powered World

For years, tech writers have worked in environments that leaned heavily deterministic.

• A procedure either matched the software behavior or it did not.

• A warning either appeared in the right place or it did not.

• A version number was either current or obsolete.

Even when the work was messy, the target state was not supposed to be mysterious.

AI changes that.

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. 🤠