If the phrase “killing our planet” immediately caused you to mutter something about alarmists, hang with me for a minute.

Patrick Bosek and I invited Gerry to be a guest on our talk show, Coffee and Content, in 2023 to discuss digital waste, content management, and the hidden environmental costs of the information organizations create and store. Gerry isn’t interested in scoring political points. He’s interested in waste, and he makes his case with research.

As it turns out, unused slide deck presentations don’t care who you voted for. 😎

One statistic in this book stopped me. McGovern argues that as much as 90 percent of digital data is never used. In an interview with Nexer Digital, his advice was simple:

“If you have data that you no longer need that is stored on your phone or laptop, get rid of it.”

In a separate conversation with Silicon Republic, he put the underlying problem more bluntly:

“Digital is not green. Digital is electrical, meaning that everything we do in digital consumes energy and creates pollution.”

I remember nodding along when Gerry talked about this during our interview. Then I spent the next couple of years faithfully preserving slide deck presentations I hadn’t opened since before the Obama administration.

The Cleanup

Eventually I decided Gerry deserved at least one obedient reader. 😎 So I started cleaning: old hard drives, cloud folders, archived conference materials, photographs, music, presentation decks I’d accumulated over the better part of three decades. My goal was simple — delete the ones nobody would ever miss and stop contributing quite so enthusiastically to the digital landfill.

Like most cleanup projects, this one wandered off the original assignment.

I found a 2013 talk from tcworld India called “It’s All About Structure,” a September 2015 Content Marketing World session in Cleveland called “Creating a Digital Content Factory: Getting Started with Intelligent Content,” and a 2017 Meetup talk in San Francisco I delivered called “The Cognitive Era and the Future of Content.”

Different years, different audiences, different vocabulary. Opened side-by-side, none of them were about content, really. They were about whether an organization could keep making sense of what it knew as the volume of what it knew kept growing.

The Scalability Problem

One of the oldest presentations took me back to work I did with the “mother of content strategy,” Ann Rockley, at a pharmaceutical company. For years I’ve described that project as documentation work. Looking at those old slides, I’m not sure that’s the best description anymore. The docs weren’t even the actual problem. The business kept changing, and the information had to change with it just to stay accurate. That’s not a writing problem.; it’s a scalability issue.

The 10x Lens

A few years later, another influence sharpened the question. In 2018, I joined OpenExO as Interim Director of Content. The organization was founded by Salim Ismail, whose work on exponential organizations was built around a simple provocation: stop asking how to get 10% better and start asking how to get 10 times better. Patrick and I later interviewed Salim on Coffee and Content, and through that work I found myself reading Peter Diamandis, Ray Kurzweil, and others writing about exponential growth.

Most of those conversations were about organizations scaling exponentially. Mine kept drifting toward information. If a company could get 10 times better, could its knowledge? Could the systems it used to create, store, and make sense of information grow the same way — without quality, meaning, and trust collapsing under the weight of it?

The Same Question, Different Vocabulary

I thought my career had moved through a series of different subjects: structure, marketing, customer experience, exponential organizations, and now AI. The old slide decks showed me something else. I’d been examining the same scalability problem from different angles the whole time.

I started that afternoon trying to reclaim a little storage space. What I found instead was a paper trail showing the same question asked in different vocabularies, going back further than I’d realized.

Why It Matters Now

That’s probably why AI has never felt like a dramatic career pivot to me. I was calling it “the cognitive era” back in 2017, when most of the industry was still talking about big data.

For twenty-five years, I’ve been asking how organizations can scale the production and use of information without letting quality, meaning, and trust collapse. AI didn’t create that interest. But it certainly expanded the audience for the information, and it raised the stakes.

I don’t know that I’ll ever stop asking that question. 🤠

In his most recent work, 99th Day: A Warning About Technology (February 2026), Gerry McGovern examines the human and environmental damage hidden beneath our digital economy. Through research and stories from affected communities, he connects AI, data centers, cryptocurrency, mining, and electronic waste to a culture of unchecked growth and extraction. The book challenges promises of a “green” technological future and asks what must change if we’re to leave a livable planet for future generations.

I had described the same workflow differently in two places. Some of the business rules didn’t become apparent until Claude reached points where the process couldn’t continue without them. Guidance I had developed over time conflicted in subtle ways that I hadn’t noticed because I already knew what I meant, but Claude didn’t.

Each time Claude reached one of those points, we stopped and worked out what the process was supposed to be. Sometimes that meant reconciling conflicting language. Other times we reorganized the information because the structure no longer held. A few problems forced us back several steps.

Looking back, we didn’t spend most of our time building software. Instead, we tried making the work explicit enough that Claude could apply it.

Why Did This Feel So Familiar?

A few weeks later I read a paper from Harvey, makers of AI software for legal pros, about governing AI agents. One sentence stopped me.

“Agents do not change what governance is for. They change where governance happens.”

A few pages later, another passage:

“Before automation can produce consistent results, the underlying process has to be understood, documented, and made repeatable.”

That described what had been happening more clearly than I had.

I wondered whether Harvey was unusual.

Read more

Employees across content teams are already using ChatGPT, Claude, Gemini, Copilot, and other AI tools to write, edit, summarize, and research information. In many places, that work is happening without shared standards, governance, or even a clear understanding of which tools are in use and by whom.

Drawing on findings from the 2026 AI Use in Technical Documentation Survey and insights from industry experts, the BYOAI (Bring Your Own AI) Report examines what this shift means for content teams and offers a practical roadmap for bringing AI use under control at work without slowing down innovation.

Unapproved AI tools are becoming part of everyday work. Request a copy of the report to see why content teams embrace shadow AI and how companies can replace fragmented workflows with secure, governed AI adoption.

What’s inside:

• What Bring Your Own AI (BYOAI) is — and why banning it never works

• The risks already showing up in your content —inconsistent output, quality gaps, no shared baseline

• The risks you won’t see until something goes wrong —data leakage, platform instability, EU AI Act exposure

• Why the fix is prompt consistency, not tool policy —and how a shared prompt library makes it real

• A five-step roadmap from ad hoc to governed AI — week-by-week action plan

• Thoughtful commentary — from content industry professionals

This eBook is brought to you by The Content Wrangler, and the AI prompt management and engineering platform, Promptitude.

Request Access

There was an agenda, several bullet-heavy slides, a comparison table, a few icons, and the familiar blue background that seems to accompany many enterprise software slide decks.

There wasn’t anything obviously wrong with the slides it generated. If someone had shown it during a conference presentation, I doubt anyone in the audience would’ve complained.

At the same time, I couldn’t point to a single slide that helped me make sense of the topic. The deck looked like a presentation because the AI tool had learned what presentations (slide decks it was trained on) typically look like. That isn’t the same thing as understanding how presentations are designed and what techniques are needed in order to communicate with slides effectively.

Why Do AI-Generated Slides Feel So Familiar?

This question set me off on a hunt for guidance from an old school resource. My bookshelf, which housed several works from two communication design influencers.

Edward Tufte hardly needs an introduction for many readers of The Content Wrangler. But for the uninformed, he’s Professor Emeritus in Political Science, Computer Science & Statistics at Yale University. His books, especially The Visual Display of Quantitative Information, Envisioning Information, and Beautiful Evidence, shaped the way generations of technical illustrators, information designers, and technical communicators think about charts, diagrams, comparison, and evidence.

Carmen Simon comes from a different world. A cognitive neuroscientist, she studies attention, memory, and decision-making, asking what people notice, what they remember, and what ultimately changes their minds. Books on my bookshelf authored by Simon include, Impossible to Ignore: Creating Memorable Content to Influence Decisions, and Made You Look: How to Use Brain Science to Attract Attention and Persuade Others.

To be clear, neither of these experts’ books contained advice about AI presentation tools. Instead, Tufte asks whether the presentation makes important relationships visible. Simon asks whether the presentation directs attention to what matters.

Those ideas gave me a different way to look at the slide deck AI produced. The deck generated resembled thousands of presentations I'd seen before, but I’m fairly sure the deck hadn’t been designed to help audiences understand any of the ideas contained in it.

AI-powered presentation generators have learned the patterns found in millions of previously published slide decks. That doesn’t mean they’ve learned which presentation choices actually help people understand information. This observation became more obvious after a small experiment.

What Happens When AI Tries To Communicate Ideas?

Simon uses a comparative visualization (like an elephant standing next to a mouse) to communicate an enormous difference in size. It’s a simple example because everyone already understands the comparison before the speaker explains it.

Comparative Visualization Approaches And Example

539KB ∙ PDF file

Download

Download

Curious what AI would do, I asked an image generator component of ChatGPT for the same scene. The elephant looked terrific. The mouse, however, came back looking like a mouse, but much too large.

The image generator produced a balanced, attractive image, but it appears to have solved a different problem than the one I was trying to address. Simon's example isn't really about creating an attractive image. It's about making the difference in size immediately obvious, as in the image below.

Edward Tufte made a similar point years before generative AI existed. In The Cognitive Style of PowerPoint (eBook), he argued that presentation software often encourages people to reduce complicated ideas to outlines and bullet hierarchies, writing that:

“PowerPoint routinely disrupts, dominates, and trivializes content.”

His criticism wasn’t about the Microsoft app. It was about what happens when presentation conventions become more important than the relationships we’re trying to explain.

That may also explain why so many AI-generated slide decks feel strangely familiar.

We sometimes criticize AI-generated presentations for looking too much like PowerPoint. In reality, PowerPoint may have been teaching AI how to make presentations. If we don’t like some of the AI-generated results, we should probably spend at least a little time looking in the mirror.

What Can Tech Writers Learn From This?

None of this feels particularly foreign to tech comm pros because we’ve been making communication decisions for years. We decide whether something belongs in a table instead of a paragraph, whether a diagram will explain the idea faster than prose, whether the warning belongs before the procedure instead of after it, and whether two ideas should be compared side-by-side rather than described one-after-the-other.

Those aren’t formatting choices. They’re communication choices.

AI presentation tools appear to recognize presentation patterns more readily than communication objectives. That's why human review still matters. Someone needs to decide whether each slide helps the audience notice, compare, understand, or remember what matters.

Can Better Prompts Produce Better Slide Deck Presentations?

One thing surprised me while experimenting with these tools. Changing the prompt often had more impact than changing the AI-powered presentation generating software.

Asking Google Gemini for a:

“presentation slide deck about structured content aimed at tech writers”

produced a perfectly ordinary deck (below).

Mastering Structured Content — Gemini Basic Prompt Experiment

1.99MB ∙ PDF file

Download

Download

Asking the system to:

“help tech writers understand why AI produces better answers when information is well structured”

changed the character of the presentation because the prompt described the audience and the communication objective instead of just the topic.

The Ai Structure Synergy

1.84MB ∙ PDF file

Download

Download

I altered the prompt to provide additional instruction and context:

“Design a presentation that introduces technical writers as “context designers” for an audience of technical communicators and documentation leaders.

Apply communication principles derived from the work of Edward Tufte and Carmen Simon rather than simply reproducing common presentation styles.

For each slide:

👉🏾 Define a single communication objective before selecting any visuals.

👉🏾 Use images only when they help the audience understand, remember, or compare an idea more effectively than text alone.

👉🏾 Prefer visual comparisons, juxtaposition, scale, process, or cause-and-effect relationships over decorative illustrations or generic stock photography.

👉🏾 When appropriate, deliberately sacrifice visual symmetry or aesthetic balance if doing so makes the intended relationship easier to perceive.

👉🏾 Keep text concise and allow the visual to carry as much of the explanation as possible.

The presentation should compare the traditional technical writer role with the emerging role of the context designer. Show how responsibilities shift from producing documentation to designing the information environment that enables AI systems and humans to retrieve, interpret, and apply knowledge correctly.

For each slide, provide:

👉🏾 the communication objective
👉🏾 the key message
👉🏾 the recommended visual
👉🏾 why that visual supports comprehension according to the communication principles being applied
👉🏾 the accompanying slide text

Do not optimize for attractive slides. Optimize for rapid comprehension and long-term recall.”

That makes me wonder whether prompt engineering will gradually become less about describing deliverables and more about describing communication objectives.

Hmmm…

How Should We Evaluate AI-Generated Presentations?

Most reviews of AI presentation tools focus on how quickly they generate slides or how polished those slides look. Those don’t seem to be the questions that matter most. I’d rather know whether the presentation makes important relationships obvious, directs attention where it belongs, and leaves the audience understanding something they didn’t understand before they walked into the room.

I’m putting together a simple evaluation framework based on Tufte’s work on information design and Simon’s research into attention and decision-making. The plan is straightforward: generate the same presentation with several AI presentation tools, score each deck against the same criteria, and see what happens.

I honestly don’t know which system will perform best. That’s exactly what makes the experiment worth running.

We’ve spent years thinking about clarity, comparison, emphasis, and understanding. AI hasn’t made those questions less important. If anything, it has given us another reason to ask them. 🤠

These jobs are also becoming some of the most important work documentation teams do today. As AI assistants increasingly answer customer questions using our technical documentation, knowledge bases, and support content, they don’t distinguish between information that’s carefully maintained and managed and information everyone forgot (or never knew) had been published online. They retrieve whatever is available — accurate or not.

That means governance is no longer just an internal publishing concern. It’s become one of the factors that determines whether AI gives customers accurate answers.

What Is Content Governance?

Content governance defines how information is managed throughout its lifecycle. It establishes ownership, review schedules, approval workflows, publishing standards, metadata practices, and archiving and retirement policies so our docs remain accurate as our products evolve.

Governance work often sits behind the visible parts of documentation, which makes it easy to overlook until conflicting or outdated information reaches a customer. The value isn’t in the process itself. It’s that our customers never have to wonder which of our installation guides is current or whether two procedures describing the same task are equally valid.

AI depends on those same signals.

Why AI Raises The Stakes

Traditionally, our prospects and customers searched documentation one topic at a time. If they found conflicting information, they often recognized the inconsistency and continued searching until they found a better answer.

Retrieval systems approach the problem differently. Before generating a response, they may retrieve info from product documentation, release notes, support articles, troubleshooting guides, FAQs, and knowledge base content. The model then generates a response from the retrieved context, even when that context includes sources that disagree.

When documentation is well managed, that process usually works well. But, when a variety of sources describe the same feature differently, the answer generator may confidently blend information that should never have appeared together.

That’s often described as an AI problem. In reality, it’s frequently a content governance problem that AI has exposed.

AI Doesn’t Know Which Docs Everyone Trusts

Documentation teams usually know where the source of truth lives. They’ve learned through lived prior experience. Software doesn’t have any such awareness.

Imagine the engineering team updates the installation guide, the customer support staff publishes a temporary workaround, product marketing simplifies the feature description on our web page, and an older version of the docs remains publicly accessible because removing it might break existing links. Uh-oh.

An experienced tech writer can quickly identify which docs reflects the current product. A retrieval system, however, sees several differing sources of information discussing the same topic. Unless ownership, metadata, publishing controls, and lifecycle management clearly identify the authoritative version, it has little basis for deciding which information deserves the most confidence.

Publishing: One Step In The Content Lifecycle

Publishing used to mean our docs were ready to be read by our prospects and customers. Now it also means it’s ready to be retrieved by machines.

Once our content is published, AI assistants, enterprise search platforms, support chatbots, and answer engines can begin indexing and retrieving it. They may continue using that information long after our product has changed unless someone — us — keeps our content current.

That’s where governance comes in. Review schedules, content audits, ownership, metadata, and retirement policies don’t just help our documentation team stay organized. They reduce the chances that outdated or conflicting information remains available for retrieval. They won’t make an AI model smarter, but they can make the information it retrieves substantially more reliable.

Governance Improves AI Without Changing The AI

Most organizations won’t build their own large language models. They’ll use commercial AI systems that retrieve information from existing documentation.

That shifts the conversation in an interesting direction.

If answer quality depends heavily on the information being retrieved, then improving AI doesn’t always begin with changing the AI. It often begins with improving the content ecosystem feeding it.

Clear ownership reduces abandoned documentation. Consistent terminology reduces ambiguity. Regular reviews reduce stale content. Controlled publishing reduces conflicting versions of the same information.

None of those improvements requires a larger model or a better prompt.

They require better documentation operations.

Regulated Industries Have Been Preparing For This For Years

Organizations in healthcare, financial services, aerospace, defense, manufacturing, and life sciences (and other industries with concern for avoiding liability and ensuring regulatory compliance) don’t invest in governance because they enjoy documentation reviews. They do it because inaccurate information creates preventable financial, regulatory, and safety risks.

AI expands that business case.

An outdated dosage recommendation, compliance requirement, installation procedure, or configuration step no longer has to be discovered by someone digging through archived documentation. If the content remains available, AI may retrieve it.

Even organizations outside heavily regulated industries face a similar challenge. Customers generally don’t distinguish between an incorrect AI response and incorrect company information. From their perspective, the company gave the answer — and it was wrong!

Governance Is Part Of The Customer Experience

For years, governance existed behind-the-scenes. Documentation shops relied on it to manage change, assign ownership, retire obsolete content, and keep growing collections of information accurate over time.

Those same practices now affect every answer AI generates from our content. Long before our customer asks a question, governance has already determined whether the AI finds accurate, current information or outdated and conflicting documentation.

Customers don’t know — or for that matter, nor do they care — whether an answer came from our documentation portal, support chatbot, or an eager-to-please AI assistant. They assume it came from us. When the answer is wrong, they’re unlikely to blame the content governance process (or lack thereof). They’ll blame our brand.

That’s why governance has become more than an internal publishing discipline. It’s one of the ways organizations improve the quality of the answers AI delivers without changing the AI itself. 🤠

Why Does API Documentation Drift?

API Docs drift because software changes faster than every source describing it can be updated. Each update to a release introduces changes. An endpoint is added. Maybe a parameter changes or an software development kit (SDK) gains a convenience method. Our release notes might announce a new capability, while our tutorials and examples, are (maybe) updated later — or not at all.

These are typical situations and they rarely reflect poor documentation practices.

The information describing an API is often maintained in different repositories, formats, and is managed by different teams sometimes using differing approaches and tools. Small differences accumulate until the implementation, OpenAPI specification, SDKs, release notes, and published documentation no longer describe exactly the same product.

Many organizations don’t discover those inconsistencies until customers encounter and report them.

Read more

AI is building an understanding of your product. The quality of that understanding depends more on your documentation than many tech writers realize.

Information architecture isn't becoming more important because AI arrived. AI just wandered into a conversation we technical writers have been having for decades.

We choose terminology, define content relati…

Read more

Claude described the company as helping European SMEs make their content AI-ready. That detail wasn’t something I remembered seeing on the product website, so I asked Claude where it came from.

The answer Claude provided was revealing. According to popular AI platform, The Content Forge website is apparently built as a JavaScript application, and, as a result, it couldn’t easily retrieve the rendered page. Instead, it relied heavily on the HTML it could see — including the metadata — the page title, meta description, and Open Graph tags. It treated those fields as evidence and folded the metadata it could see into its explanation of the company.

Metadata Isn’t Just For SEO Anymore

HTML metadata serves many purposes. Some metadata tell web browsers how and where to display content a web page. Other types help search engines index content, control how pages appear when shared on social media, verify site ownership, or identify the preferred version of a page. Other metadata describes what the aboutness of the content on the page.

Read more

SMEs know the product, process, customer edge cases, risks, and technical truth. But they’re often busy, hard to schedule, not trained as writers, and not rewarded for documentation work. So tech writers wait for answers, reviews stall, drafts rely on assumptions, and content becomes late, incomplete, or wrong.

Wikis were supposed to let experts write directly. Agile development, Continuous Integration / Continuous Development [or Deployment] (CI/CD), and Docs-as-Code promised to bring writers and developers closer together. AI systems now promise to summarize meetings, draft procedures, and answer questions.

Yet tech doc projects continue to be delayed for reasons that would’ve sounded familiar 20 years ago:

👉🏾 The engineer is working on a production issue
👉🏾 The product manager is on maternity leave
👉🏾 The support lead is handling an escalation
👉🏾 The meeting was postponed
👉🏾 The review sits untouched because the release date moved — again

Most tech writers know this phrase by heart: “We’re waiting for the SME.”

SMEs Already Have A Full-Time Job

The majority of SMEs were hired to build products, support customers, manage systems, or solve technical problems. Helping to create documentation becomes something they do in the remaining spaces between meetings, deadlines, incidents, and projects. Documentation reviews often survive on goodwill, leftover calendar time, and whatever caffeinated beverage (probably this one) remains in the refrigerator.

Documentation competes with work that affects release dates, customer commitments, operational issues, and performance evaluations. The review of a draft procedure rarely wins that competition.

Many writers find that while arranging an interview is a quick task, the real bottleneck happens when waiting weeks for follow-up answers.

We’ve Been Trying To Solve This For Years

The approaches that promised to improve documentation also promised to reduce the distance between writers and SMEs. Agile teams placed writers closer to developers. CI/CD encouraged documentation updates to move alongside software releases. Docs-as-Code put documentation into the same repositories, workflows, and tools used by engineering teams.

Developers could submit pull requests, review content, and contribute changes without leaving the comfort of their familiar digital ecosystem. The underlying assumption made sense. If writers and experts worked more closely together, documentation delays would become less common.

Co-location worked for some, but not all. Many organizations still struggled with overloaded engineers, late reviews, and stalled documentation. Proximity improved collaboration, but it didn't solve the problem of competing priorities.

Knowing Something And Explaining Something Are Different Activities

When you know a subject inside out, you tend to skip the basics. The missing steps seem obvious, the jargon feels natural, and the foundational assumptions fade into the background.

Experts struggle to predict what non-experts don’t know. Camerer, Loewenstein, and Weber’s classic study found that better-informed people (think SMEs) are unable to ignore what they know when judging what less-informed people will understand.

Tech writers witness the fallout of this gap every day. We see product demos stall, support teams use unwritten workarounds, and three different experts give completely different explanations of the exact same process. An engineer explains the architecture, a support rep explains the user reality, and a product manager explains the vision. The actual procedure is buried somewhere in the middle. Translating that chaos into clarity is exactly why we exist.

Organizations Create Their Own Bottlenecks

Company knowledge is almost never spread out evenly. Usually, it’s trapped in the brains of a handful of people: the engineer who actually built the integration, the admin who knows the permissions inside out, the support rep who remembers why things changed years ago, and the project manager who tracks all the weird exceptions.

When every department constantly interrupts them for answers, calendars fill up with endless meetings. But calling these experts “bottlenecks” is unfair. They are forced to act as the company’s historical archive, tech support, and approval authority all at once. The real problem? The organization didn’t build a scalable system; it built a workflow that entirely depends on a handful of overloaded people.

Tech Writers Already Know This Problem

Experienced technical writers rarely depend on isolated interviews. They validate information by cross-referencing release notes, analyzing support trends, observing demonstrations, and executing procedures themselves.

They look for discrepancies in terminology across departments and leverage hands-on demonstrations to uncover gaps.

Ultimately, information gathering is just as critical as content creation. This investigative approach helps writers build an "organizational radar," allowing them to identify unverified data, obsolete procedures, and conflicting expert perspectives.

We Keep Asking The Wrong Question

Companies love to ask how they can free up more time for their SMEs. But here’s the reality: those experts don’t have any more time to give.

Instead, we should ask why we keep making them repeat themselves. If support asks for the same breakdown every release, the docs are missing something. If onboarding requires a hand-holding session for a basic process, the documentation isn’t clear. If customers keep calling about the same glitch, the fix is too hard to find.

The expert isn’t being used for their technical skill; they’re being used as a human search engine. Tech writers fix this by turning individual expertise into public record. When info is accessible and reliable, fewer questions have to travel back to the same overloaded people.

AI Has Exposed Our Content Debt

Many leaders are learning the hard way that their shiny new AI chatbot only knows as much as their documentation does.

For instance, if an installation step was never written down, the AI can’t divine it. If our customer support and product teams use different jargon, the chatbot’s answers will be a messy contradiction. And if an article has been abandoned for years, the AI may confidently serve up that expired data as today’s gospel.

AI didn’t create these flaws; it just stumbles into them at lightning speed. Now, instead of writing, experts are stuck babysitting AI drafts, validating chatbot outputs, and fixing errors caused by poor source material.

The Real Goal

SMEs are vital to organizational success. As products advance and regulatory environments evolve, their deep expertise becomes even more critical. The objective is to optimize their time by eliminating repetitive inquiries.

When documentation is current, standardized, and properly governed, organizations naturally reduce the burden on their SMEs. Internal teams resolve issues faster, onboarding timelines shrink, and customer self-service rates improve.

Tech writers have driven these operational efficiencies for decades. Ultimately, the rise of AI has simply provided organizations with a compelling new reason to recognize the value of structured knowledge management. 🤠

Like many people, I assumed I knew its history. And like so many other things I have assumed I was right about before, I was oh-so-terribly wrong.

A few weeks ago, I watched a video from Rabbit Hole that set out to answer: Where did Lorem ipsum come from?

I expected a quick explanation about Latin and early printing. Instead, I spent the next half hour following one of the most enjoyable research rabbit holes I’ve encountered in quite a while.

The First Clue

The story starts with Richard McClintock, a retired Latin professor at Hampden-Sydney College. While working on university publications years ago, he noticed that one of the words in Lorem ipsum looked too obscure to be random. That curiosity led him to De Finibus Bonorum et Malorum, a philosophical work Marcus Tullius Cicero wrote in 45 BCE.

For most people, that would have been the end of the story. For me, it wasn’t.

Finding Cicero explained where the words originated. It didn’t explain how that passage evolved into the placeholder text found in publishing software, website templates, presentation tools, and design mockups.

Not Quite Latin

The version of Lorem ipsum we recognize today isn’t simply copied from Cicero. Someone edited it with remarkable care.

Words disappeared. Others changed. Letter combinations appeared that wouldn’t exist in classical Latin. Even the opening word, “lorem,” isn’t Latin. It’s what remained after part of the original sentence was removed.

Creating convincing placeholder text turns out to be harder than creating nonsense. The text has to resemble natural language closely enough that a page looks realistic, while remaining just unfamiliar enough that readers don’t become distracted by what it says.

Just for fun: Try Jeffsum — a little text placeholder generator of Jeff Goldblum awesomeness.

The Story Everyone Knew

If you look up "Lorem ipsum" you always get the same story: some unknown printer in the 1500s chopped up Cicero's writing to make a sample book. It's everywhere. But when the creator of this video actually tried to verify that claim? They couldn't find a single source to back it up.

That’s when the real research began.

Following The Evidence

Old dictionaries, typography books, vintage Letraset catalogs and library archives were searched. Following a trail of decades-old advertisements, dictionaries, typography books, library archives and vintage Letraset catalogs, the creator finally struck gold: a surviving Letraset sheet from the 1960s that blew the case wide open. Side-by-side comparison with Cicero’s original work revealed the truth.

Another discovery explained why almost every designer eventually encountered those familiar words. Laura Perry, who worked on Aldus PageMaker, remembered typing the Letraset version into the software because designers already used it. That small decision introduced Lorem ipsum to millions of desktop publishing users. No committee established a standard. Nobody issued a specification. One practical decision quietly became an industry convention.

I love stories like this. We often assume familiar conventions emerged from careful planning. Ha! Sometimes they survive simply because the next person reused what the previous person had already done.

The Missing Pieces

One important question still remained. Who created the Letraset version?

Near the end of the investigation, an email arrived from one of Letraset’s earliest designers. He described how the company had worked with James Moseley, a typography historian and librarian. According to his account, Moseley selected a less familiar passage from Cicero and reshaped it into the placeholder text that eventually appeared on Letraset sheets.

Unfortunately, Moseley died before he could be interviewed, leaving a few details beyond anyone’s reach. Even so, the evidence tells a much more interesting story than the familiar “printer in the 1500s” explanation that still dominates much of the web.

Case Closed?

Not completely. Historical research rarely ends with every question answered, and this one doesn’t either. It does, however, replace a surprisingly persistent origin myth with evidence collected from books, interviews, archives, surviving artifacts, and a great deal of patient detective work.

The video comes from the Rabbit Hole YouTube channel, whose tagline is “extraordinary answers to everyday questions.” In this case, that promise fits perfectly. 🐇

When that responsibility isn’t clear, updates start slipping.

👉 The engineering team assumes the technical writers will make the changes.

👉 The technical writers assume the product managers will request them.

👉 The product managers assume the engineering team will mention what changed before the release ships.

Everyone assumes it’s somebody else’s job. Meanwhile, customers keep reading instructions that don’t match the product.

I’ve watched plenty of organizations throw money at new authoring tools, AI initiatives, content strategies, and style guides while leaving this basic governance problem untouched.

There’s an easier place to start.

Who’s Responsible For This Topic?

If you ask three people and get three answers, you’ve found the problem.

The same responsibility issues happen with knowledge bases, support articles, training materials, websites, and internal process documentation. People usually aren’t ignoring the content issues; instead, they’re probably just waiting for someone else to own the update process.

Before you rewrite a single page, figure out who’s on the hook for every topic. Then make sure everyone who creates, reviews, or relies on that content knows who that person is.

You can buy new software, adopt AI, rewrite your style guide, and reorganize your information architecture. None of those things fixes unclear ownership. 🤠

What surprised me was how little of this information appeared anywhere else. The content audit didn’t mention it. The analytics reports didn’t mention it. The quarterly review didn’t mention it.

The search logs did.

What Do Search Logs Tell Tech Writers?

Page views tell us what people open. Support cases tell us which problems are expensive. Customer surveys tell us how people feel about the experience we provide.

Search logs show what people went looking for. They tell us what people were trying to accomplish when they stopped looking through menus, scanning headings, or clicking links and — finally — decided to ask for help.

One of the surprises in search data is how often people search for information that already exists. The customer searches for "login problems." The documentation discusses identity federation. Someone searches for "files aren't updating." The product team calls the feature workspace synchronization.

Read more

We’ve lived with the consequences of outdated content for years. What’s changed today is that those consequences are now much easier to see. Support analytics, customer feedback, self-service metrics, and AI systems now expose information problems that in the past may have remained hidden.

Tech writers have discussed these issues for decades. The costs are simply harder to ignore now.

What Is Documentation Debt?

The symptoms are familiar: outdated procedures, obsolete screenshots, broken links, duplicate content, conflicting instructions, and knowledge base articles that no longer match the product.

Documentation debt rarely arrives all at once. A feature ships before the technical documentation is updated. A subject matter expert leaves the company. Ownership becomes unclear. Teams focus on creating new content while older information slowly falls out of date.

The work doesn’t disappear; it accumulates.

Many Tech Writers Already Understand Technical Debt

Many of us have spent years working alongside software teams that discuss technical debt.

Developers use the term to describe shortcuts, deferred maintenance, aging code, or design decisions that eventually make software harder to maintain. Teams understand that the cost does not disappear simply because the work was delayed.

Documentation works much the same way.

When updates are postponed, maintenance is deferred, or ownership becomes unclear, organizations accumulate documentation debt.

Both forms of debt represent deferred maintenance.

Technical debt affects the software itself. Documentation debt affects the information people rely on to use, support, maintain, purchase, and troubleshoot that software.

Engineers encounter technical debt in the codebase. Tech writers run into documentation debt through support tickets, failed searches, outdated procedures, and frustrated users.

Technical debt is widely recognized because it affects schedules, budgets, and engineering productivity. Documentation debt affects support costs, customer experience, operational risk, and the reliability of information systems.

Read more

I recently looked through a Stanford Online program about AI leadership expecting to see material about prompts, large language models, and the latest tools.

Instead, much of the curriculum focuses on organizations. The instructors spend considerable time discussing data quality, workflow design, adoption challenges, governance, evaluation, and management. Those subjects may sound familiar to people who work with technical documentation.

One section discusses the need to create what the program calls a culture of data excellence. Organizations are encouraged to examine their information quality, terminology consistency, data condition, and maintenance processes.

Documentation teams have spent years dealing with duplicate information, conflicting terminology, outdated procedures, missing context, and unclear ownership. In doc shops these issues are usually discussed as content quality problems. In AI initiatives they often appear under labels such as data readiness, knowledge management, or governance.

Workflow And Information Design

The curriculum also spends considerable time on workflow design. Organizations adopting AI need to understand where information originates, who maintains it, how quality is evaluated, and where human review belongs.

Those responsibilities overlap with work that already exists in many documentation groups.

People who understand structured content, metadata, taxonomy, terminology, governance, and information architecture already spend much of their time organizing information so that other people can find it, reuse it, and trust it. AI systems depend on many of the same conditions.

How The Work May Change

The Stanford material also examines how management changes when AI becomes part of everyday work. Documentation teams may find it useful to ask a similar question about their own responsibilities.

Drafting assistance will continue to improve. Summaries, first drafts, content audits, and some forms of analysis are becoming easier to automate. At the same time, organizations still need people who understand content models, terminology, ownership, information quality, and evaluation.

For many writers, the work may shift more than it disappears.

Choosing Useful Applications

One practical theme running through the program is the importance of identifying useful applications instead of adopting AI simply because the technology is available.

Documentation teams can ask fairly ordinary questions. Where are customers struggling to find answers? Which information generates support calls? Where does terminology create confusion? Which content no longer matches the product? What information exists inside the company but never reaches customers?

Most of those problems existed long before generative AI appeared.

Skills Worth Developing

One thing that stood out in the Stanford curriculum was how little attention it gives to prompts and individual AI tools. Governance, evaluation, workflow design, organizational adoption, and information quality receive far more attention than prompt engineering.

For tech writers, that shift may be worth us paying attention to. Much of the discussion centers on work that tech pubs teams already know well: maintaining information quality, reducing ambiguity, and helping people find trustworthy answers.

We’ve been doing this work for years, even if the labels attached to our work keep changing. 🤠

The criticism is fair. Large language models are known to invent facts, confuse details, and produce answers that sound convincing even when they are wrong. What interested me more was the assumption underneath the slogan. The comparison only works if people are reliable.

Tech writers spend enough time interviewing subject matter experts to know that isn’t always true. Ask several people how a product feature works and you may hear several explanations. One engineer describes the original design. Another explains how the system behaves today. Support remembers the workaround customers use. Product management recalls a decision that was never documented.

Nobody intends to mislead anyone, yet the facts often arrive tangled together. Much of the work of technical writers involves sorting through those competing accounts.

Human Hallucinations Are More Common Than We Admit

Chris’s post assembled several examples that are uncomfortable precisely because they involve ordinary people rather than obvious bad actors.

A YouGov survey found that 2 percent of Americans said they firmly believe the Earth is flat. Another 7 percent said they were unsure about the Earth’s shape. Among younger adults, the uncertainty was even higher.

A separate Economist/YouGov poll found that 12 percent of Americans agreed that the Moon landing was staged.

Related reading: Conspiracy vs. Science: A Survey of U.S. Public Beliefs

The so-called Mandela Effect offers another example. In a 2022 YouGov survey, 40 percent of Americans said they had shared a memory with others that many people remembered differently or believed to be false. When asked about specific examples, 61 percent remembered the children’s books as the “Berenstein Bears,” even though the books have always been published as the “Berenstain Bears.”

The same survey found that 28 percent of respondents considered parallel universes or alternate dimensions a plausible explanation for these shared memories.

These examples are easy to dismiss because they seem unusual, but memory errors appear in situations with much higher stakes. Eyewitness testimony remains one of the most persuasive forms of evidence presented in court. Yet the Innocence Project reports that eyewitness misidentification played a role in roughly 69 percent of convictions later overturned through DNA evidence.

One of the best-known cases involved Jennifer Thompson, who deliberately studied her attacker’s face so she could identify him later. She selected Ronald Cotton from a lineup, testified against him in court, and remained convinced she had identified the correct person. Cotton spent more than a decade in prison before DNA evidence established that another man had committed the crime.

Why Organizations Write Things Down

Organizations create documentation for many reasons. New products need instructions, APIs need references, and customers need help completing tasks. Over time, documentation also becomes a record of decisions, product behavior, terminology, and procedures that people may remember differently or forget altogether.

Most documentation teams eventually discover procedures that nobody follows, product behavior that differs from the manual, and explanations that change depending on who is asked. Generative AI did not create these problems.

When an AI system produces an incorrect answer, the mistake appears immediately. Human errors often move more slowly. They become outdated procedures, undocumented assumptions, conflicting explanations, and organizational folklore that survives long after the product changes.

Every tech writer has heard someone begin a sentence with, “We’ve always done it this way,” only to discover that nobody can explain why.

People And AI Make Different Types Of Mistakes

People are forgetful. We combine separate events into a single memory, and rely on assumptions, repeat information we heard years ago, and sometimes remember what we expected to happen instead of what actually happened.

Language models fail differently. They predict likely responses from patterns in training data and retrieved information. They may combine facts incorrectly, invent missing details, or generate plausible explanations that lack evidence.

Neither Humans Nor AI Systems Deserve Automatic Trust

It turns out that people and language models need many of the same things: good information, enough context, and a way to check whether an answer is supported by evidence.

Most of us have been in the meeting where three people remember the same decision three different ways. Eventually someone finds the ticket, the email, or the requirements document, and the argument ends.

Tech Writers Already Understand The Problem

Must we choose between reliable humans and unreliable AI? I hope not.

Anyone who has worked in documentation for very long has encountered the software engineer or product creator who explains a feature with complete confidence, only for testing to reveal that the product behaves — ahem — differently.

Every doc team eventually finds a procedure that nobody actually follows. Support teams have their own version of this problem, repeating explanations they conjure up that might have matched the product several releases ago but no longer do.

AI gives employees another place to get answers, but somebody still has to check whether those answers match the product, the policy, and the documentation.

What This Means For Tech Writers

Technical writers regularly walk into situations where different people remember the same event differently. One person recalls the decision, another remembers the exception, and somebody else insists the whole thing changed two releases ago. Eventually we have to sort through the emails, tickets, release notes, and meeting minutes to figure out what actually happened.

That work becomes even more important as AI systems begin answering questions alongside documentation, support teams, and subject matter experts.

Organizations have always operated with incomplete information. People remember meetings differently, repeat outdated explanations, and hold onto decisions that quietly changed years ago. Documentation helps reduce some of that confusion, even if it never eliminates it completely.

AI now participates in many of the same conversations that once belonged entirely to coworkers, support staff, and subject matter experts. That puts more pressure on the underlying information. Procedures, release notes, requirements, and product documentation increasingly serve both people and machines.

For tech writers, the work is familiar. Somebody still has to determine what is true, what changed, and which version belongs in the documentation. 🤠

If you’ve been following The Content Wrangler for any length of time, you know I’ve been thinking about what happens to professional communities when the old models stop working. The collapse of Society for Technical Communication (STC) in 2025 put that question front and center for a lot of us.

A researcher at University of North Carolina Wilmington is studying exactly this — how technical communication professionals are finding knowledge and community now, what creator-driven platforms like this one actually provide, and where they fall short. The study takes a hard look at the creator economy as a model for professional development and asks what we’ve lost with Society for Technical Communication gone and what might replace it.

They’re looking for responses from practitioners at all career stages — whether you were a longtime STC member, a longtime subscriber of The Content Wrangler, or someone who never joined a formal association at all.

The survey takes about 10 minutes and is completely anonymous.

If you’ve ever had thoughts about where this field is headed and who’s responsible for keeping it together, this is a good place to put them on record.

Take the Survey

The argument usually goes something like this: Markdown is clean, lightweight, and easy to parse, therefore it must be better for AI.

Converting technical documentation to Markdown is often presented as a step in the right direction. Nic Gould, a linked data specialist Information and Data Architect for Delinian, recently challenged that assumption, and his argument is worth a closer look because it exposes a larger misunderstanding about how AI systems consume information.

The problem isn’t that Markdown is bad; it’s that too many people are treating markup syntax as though it were responsible for comprehension.

Some Tech Writers Already Know This Lesson

A markup language can represent meaning, but what it can’t do is create meaning where none exists. You can wrap a paragraph in tags, identify headings, define a table, a note, a warning, or a code sample. Structure helps both people and machines navigate information.

If a procedure says:

Approve the request after validation completes.

the markup language isn’t the problem.

👉🏼 Who approves it?
👉🏼 What validation?
👉🏼 What event signals completion?
👉🏼 Where is the request located?

Those questions need answers whether the content is written in Markdown, HTML, or DITA XML.

The Confusion Comes From Mixing Layers

People often blur the distinction between representation and understanding. Markdown lives in the representation layer. It’s one way to express structure.

Understanding happens elsewhere.

Before information reaches a language model, it may pass through extractors, chunking systems, search indexes, retrieval pipelines, ranking algorithms, vector databases, APIs, and application logic. By the time the model receives information, it is working with tokens derived from content that has already been processed several times.

What matters is whether the information that reaches the model retains enough meaning and context to answer a question accurately.

Why This Matters For Documentation Teams

The appeal of the “AI prefers Markdown” argument is obvious. It offers a relatively simple solution.

Content migrations are tangible. Converting repositories creates visible progress. Teams can point to a completed project and say they have done something to prepare for AI.

Improving information quality is much harder.

It requires identifying ambiguity, defining terminology consistently, documenting assumptions (that experienced employees carry around in their heads). And, it often requires untangling a content hairball that was built from the content debt accumulated over years.

There’s no conversion utility for that work.

Yet those activities frequently have more influence on answer quality than the choice of markup language. A retrieval system can find content quickly, yes it can. That’s a super power. But, it can’t reliably infer details that were never documented.

This is one reason technical writers have become increasingly important in AI projects.

The challenge isn’t simply making content available to AI systems. The challenge is making meaning available.

What Tech Writers Bring To The AI Party

When tech writers clarify terminology, expose relationships between concepts, document conditions, identify roles, and explain why something happens, they reduce the amount of interpretation required downstream. That benefits readers; and, it also benefits retrieval systems, search engines, virtual assistants, AI agents, and language models.

Much of the current discussion around AI focuses on models, prompts, tools, and platforms. Those topics matter, but they often draw attention away from the information itself.

Tech writers sit closer to the source of the problem. We know that confusion usually begins long before an answer is generated.

Let’s Get Serious About Creating Understanding

Gould’s article is less about Markdown than it is about a categorization mistake. Markup languages describe structure. They don’t create understanding.

Teams evaluating their AI readiness may get more value from examining ambiguity, terminology, context, relationships, and information architecture than from debating which markup language should store the content. That’s not an argument against Markdown. It’s a reminder that syntax and meaning are different things.

Tech writers have been dealing with that distinction for years. AI hasn’t changed it. 🤠

If you know women engineers in your professional network, please encourage them to participate.

Too much of the history of technology is written through the lens of products, companies, patents, and executives. The people who solved the problems, built the systems, wrote the code, designed the products, tested the hardware, and kept projects moving often disappear from the historical record.

As techcomm pros, we understand the value of preserving knowledge. We spend our careers documenting products, processes, and decisions so they aren’t lost. The same principle applies to the history of our professions.

We need to capture the history of technology from the people who did the actual work. Our stories matter because we lived them.

A recommendation, introduction, or simple email to someone in your network may help ensure that these experiences are preserved and available for future generations to read, study, and understand.

Technical communicators often serve as the custodians of organizational memory. This is an opportunity to help preserve the human history of technology itself.

If you know an engineer whose story deserves to be told, now is the time to encourage them to share it. 🤠

Does the format of documentation influence the quality of AI-generated code?

In Tokens Not Jokin’: How API Documentation Format Affects AI Code Generation, Grzetich reports findings from more than 21,000 integration tests examining how AI systems perform when working with APIs documented in different formats. The book compares approaches including OpenAPI, YAML, Markdown, and others, while also exploring token usage, testing methodologies, and AI evaluation techniques.

One finding immediately stands out. Documentation format appears to have a substantial impact on code generation outcomes, potentially greater than the choice of AI model itself.

Does API Documentation Format Affect AI Code Generation?

Yes, according to Grzetich’s research. The book presents evidence that documentation structure can significantly influence how effectively AI systems interpret APIs and generate working code. The findings suggest the way information is organized may matter as much as, or more than, the model consuming it.

Why Should Documentation Teams Care?

For years, documentation professionals have focused on helping human readers understand products and services. AI coding assistants have introduced a second audience.

Today, docs are often consumed by both software developers and AI systems. The same API reference that helps a developer build an integration may also be used by an AI assistant to generate code, explain implementation steps, or answer technical questions.

When documentation contains ambiguity, inconsistent terminology, or incomplete examples, AI systems consume those weaknesses along with everything else.

What Topics Does Tokens Not Jokin’ Cover?

The book examines:

• API documentation formats

• AI code generation performance

• Token consumption and efficiency

• Documentation designed for machine consumption

• Evaluation and testing methodologies

• AI acceptance testing

Rather than relying on opinion or isolated examples, the book focuses on measurement and repeatable testing. That approach makes it useful even for readers who remain skeptical of some of the conclusions.

What Does This Mean For The Future Of API Documentation?

The rise of AI-assisted development is changing how docs are used. Our technical documentation is no longer only a resource people consult when they need help. It’s increasingly becoming source material used by AI systems to generate answers, recommendations, explanations, and code.

As a result, familiar documentation concerns take on new importance. Information architecture, content structure, metadata, terminology management, examples, and consistency all become factors that may influence machine-generated outcomes.

Many documentation teams have been advocating for these practices for years. AI may provide new evidence supporting their value.

Should You Read This Book?

If your work involves API documentation, developer experience, structured content, content engineering, or AI-assisted software development, the answer is probably yes.

The book raises important questions that many organizations haven’t yet begun to think about asking. It also provides data that can help move our conversations beyond speculation about prompts and models and toward the information those systems consume and rely upon.

Whether the research ultimately reshapes industry practices remains to be seen. What seems harder to dispute is the underlying premise: documentation is becoming part of the AI development stack.

Understanding how AI systems interact with our docs is no longer a niche concern. It’s becoming part of the job. Our job.

Buy the book!

Not all of them. I’m not unreasonable. Just… most of them.

Our Users Will Always Have Questions

It’s a nice idea. Clean. Optimistic. And…completely detached from reality.

Because our users don’t stop having questions. They don’t wake up one morning, stretch, and think, “You know what? Today I’ll rely entirely on the doc team’s careful prose and never bother another human again.”

No. They click around for a bit, get mildly annoyed, and then — frustrated — they go looking for an answer the fastest way possible. This usually involves asking someone. Anyone.

And that’s the moment where most of our documentation strategies (assuming we had them) quietly fall apart.

What eCommerce Already Figured Out

Somewhere else on the internet, far from our lovingly maintained knowledge bases and documentation portals, eCommerce companies solved this problem without holding a single panel discussion about it.

They didn’t try to eliminate questions. They assumed questions were inevitable (like software updates that arrive at the worst possible time) and built systems to deal with them.

Most customer questions? Handled automatically. Instantly, if possible. Order status, return policies, “where is my stuff?,” “why is my stuff late?,” “can I return this thing I bought at 2 a.m. after a glass of wine or three?” — all of it gets answered without a human lifting a finger.

The rest? The strange, the emotional, the oddly specific? Those get routed to a person mostly likely to be able to handle the query.

That’s it. No drama. No philosophical crisis about whether the FAQ is “complete.”

We Built Libraries, Not Answer Systems

Meanwhile, over in technical documentation-land, we built… a library. A very respectable library, indeed. Shelves neatly arranged. Topics carefully labeled. Maybe even a search bar that works (most times). And then we sat back and thought, “There. That should do it.”

What we didn’t build was a system that handles questions and delivers reliable answers.

Read more