{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreid4axel22uxlc7y6nv3dxrfyepfqesgclwrhmqvkcx3n3h4lgszkm",
    "uri": "at://did:plc:dclakjd7jtu2lkz3mgyhturv/app.bsky.feed.post/3miuajdgxz3i2"
  },
  "path": "/blog/leveraging-ai-in-writing/",
  "publishedAt": "2026-04-06T00:00:00.000Z",
  "site": "https://coyotetracks.org",
  "tags": [
    "my",
    "various",
    "reasons",
    "Creative Commons “Attribution-NonCommercial-ShareAlike” license",
    "Ko-fi.com"
  ],
  "textContent": "I shared a LinkedIn post with that title last week. I’m going to share what I wrote there, but I’m going to ask a _second_ question after that, which I may or may not share with the LinkedIn crowd later. If you’re thinking “but I thought you were an AI skeptic!”, hold on. Okay? Okay, here’s the post:\n\nFirst and foremost, what we’re calling “AI” is not the AI of sci-fi movies. Generative pretrained transformers are statistical prediction engines; when they’re coupled with large language models, what they do is generate a statistically likely continuation of their input text. That’s it. Full stop. Now, it turns out that “that’s it” undersells how amazing that output can be. The statistically likely continuation of an input text that's a search query is a plausible answer to that query; the statistically most likely continuation of feeding a Github repository into an LLM with a command to write documentation for the code is plausible documentation.\n\nBut _plausible_ is not the same as _correct._ The bigger and more complicated the task presented to an LLM is, the likelier it is to go off the rails—maybe just a little, maybe a lot. If you don’t know what the output should look like, you may not catch this. That’s the obvious peril of “vibe coding”; a similar issue arises with “vibe documenting.” The more constrained the task you give it, the better job it’s going to do at it. Claude will probably nail “write a Python script to transform the date formats in this text file” on the first try; “write a clone of Photoshop that runs as a web app,” not so much. Likewise, “write reference descriptions for this API, including input parameters, sample output, and error conditions” will get you a better first draft than “write a complete casual developer’s guide for this database.”\n\nSecond, the statistically most likely continuation of _anything_ is definitionally the median. An LLM will be much faster at generation than a human, but at its absolute tippy-top best, it’ll be better than about fifty percent of humans at the same task…and worse than about fifty percent of them. The more difficult and expansive the problem you’ve given it is, the less likely it is to be at that absolute tippy-top best. It’ll make mistakes a human wouldn’t, because it will have made what appear to be incorrect decisions or assumptions: calling a library that doesn’t actually exist, or including a guide on Git basics in an overview of how to write game plugins. The thing is, it’s not actually making _any_ decisions or assumptions. It’s just determined that _statistically speaking,_ a lot of code in its corpus calls similar libraries in similar functions, and a lot of documentation in its corpus talks about version control after it talks about NPM modules (or whatever).\n\nSo, if you’re going to use AI in documentation:\n\n  * Target constrained, clearly defined use cases that contain sufficient context the LLM will stick to the task at hand.\n  * Expect the output to be first draft quality, not production ready.\n  * Humans _must_ review the output, both to verify the engineering aspects (do the samples work, does the API really have those calls, etc.) and to make sure it’s staying on topic.\n  * Do not expect the LLM to have your corporate voice or stick to your corporate style guide, even if you’ve prompted it to do so. It won’t.\n  * The human reviewer(s) should be using a Markdown linter. (There’s probably some automated way to handle this, but I think it’s a good idea regardless.)\n\n\n\n* * *\n\nOkay. LinkedIn enough for you? Here’s the second question:\n\n“ _Should_ you be leveraging AI in your technical writing?”\n\nA tech writing group I’ve been loosely involved with the past few years, Write the Docs, has been consumed by the question. A writer in that group who lost his job but got a new one less than a month later rhapsodized about LLMing all the things to do it (rewriting his LinkedIn profile and his resume, editing cover letters, creating custom targeted resumes, etc.). People in the WTD Slack talk about rebranding themselves as “context engineers” or “knowledge engineers.” Technical writers, they say, have been writing clear instructional procedures for technical concepts for decades. That’s literally the job description. Ergo, we’re exactly who companies should be hiring to direct AI systems. We should be kings of the new world!\n\nAnd, man, my urge to leave tech and open a tiki bar or coffee shop or take up woodworking has _never been stronger._\n\nI’ve talked about my various reasons to be skeptical/wary of AI before, so I won’t rehash them. LLMs have become good code monkeys, but generated code is less likely to be algorithmic plagiarizing than images or, more broadly, any attempt at creative work. (Also, “less likely” is not the same as “never”.) Training models on copyrighted material almost certainly _is_ a copyright violation if you don’t have a legal right to access it: it’s behind a paywall, it’s a non-freely-licensed ebook, possibly it’s just a blog article that’s only licensed for non-commercial use (like the Creative Commons “Attribution-NonCommercial-ShareAlike” license I use). Literally _all_ the current popular AI systems use corpora that violate copyright in that regard. So, you know, there’s that.\n\nBut even if we set that aside (which we shouldn’t), even if we grant the relatively rose-colored view of the first part of this post, there are two big questions.\n\nFirst, for companies: do you _want_ your documentation to be middle-of-the-road at best? Because that’s what you’re going to get if LLMs do most of the work. Companies that let AI write _all_ of their documentation won’t even hit that mid-level bar. The AI drafts that I worked with were okay, in the way that a first draft written by a freshman intern hopped up on Red Bulls would be okay. Every section needed editing, and most sections needed to be entirely rewritten. Or moved. Or cut completely. The overcaffeinated robot intern doesn’t understand information architecture or ontologies. You may think you are going to get it there with sufficiently clever prompting; you won’t.\n\nDid using an LLM save _any_ time? In theory, it should. Even if the first draft isn’t that good, writing is almost always slower than editing. In practice, though, if I’m doing so much editing it basically _is_ writing, it’s probably a draw. And if I’m not, the documentation isn’t as good as it could be. If the LLM adds any value here, it’s in giving me something to bounce off of, something to look at and say, _That section doesn’t need to be there, it needs to be over here. The voice here is all wrong. This example is redundant and this other example doesn’t quite work, but I can find one that does._\n\nBack in Write the Docs, there seems to be a consensus—a vibe, if you will—that users can’t tell the difference between AI-written and human-written documentation. As “documentarians,” we need to accept that and get with the times if we want to keep a job. To which I say: bullshit. Users can tell the difference between good documentation and bad documentation, just like they can tell the difference between good UX design and bad UX design, or good typography and bad typography. Maybe they can’t _explain_ the difference, why this interface is good and that one is bad, why that poster looks beautiful and that one looks like ass, or Stripe’s API documentation is mostly terrific and Apple’s API documentation is mostly undercooked tripe. But that doesn’t mean they can’t _tell._\n\nSo this leads me to the other question, for other writers: is this actually what you _want?_\n\nLike I said, I can see ways to use LLMs and still be a writer. But _prompt engineering is not writing._ Could I do a job that involves just tweaking prompts to Claude until it emits something with the general appearance of product documentation? Sure, I guess. But I’m not convinced anyone will pay me enough to keep me in the amount of high-quality rum—we are not talking Captain Morgan here—I’ll require to deal with that.\n\nSo, should you be leveraging AI in your technical writing? Here’s a LinkedIn-friendly answer: If you wanna play around with it in the margins—using it for proofreading (not rewriting), or as a jumping-off point for initial drafts, summarizing, research—try it! But don’t take it for granted that it’s going to make you faster or smarter or better. Check its work constantly.\n\nHere’s an honest answer: I am already _so damn tired_ of thinking about this question.\n\nI’m so tired of the fear that I’ll be penalized if I do not sound sufficiently enthusiastic about a tool which is already being used to replace people in my field despite being demonstrably incapable of doing so. (“Now that we have electric screwdrivers, we’ll never need trained carpenters again!”)\n\nI’m so tired of the entire tech industry willfully ignoring the signs that AI is a bubble, that it is being wildly oversold and jammed into places where it is inappropriate or even dangerous.\n\nAnd frankly, I’m not just tired, I’m _angry_ seeing other technical writers buy into the idea that the only way they can stay in their career is by helping people who never took the field seriously to start with relentlessly devalue it. Maybe I’m a weirdo here, but I’m a writer _because I enjoy writing._ I’m a technical writer because I _like_ the work of taking complex topics and figuring out best to present them to a specific audience. I take pride in my craft. I think there’s even some art to it.\n\nI’m not saying it’s impossible to take pride in figuring just the right words to type to get Gemini to spit out the best possible mid-tier documentation it’s capable of, but—actually, scratch that. I think that’s what I’m saying.\n\nNow, if you’ll excuse me, I’m going to go work on a tiki cocktail menu. You know, just in case.\n\n_To support my writing, consider a tip on Ko-fi.com._",
  "title": "\"How are you leveraging AI in your technical writing?\"",
  "updatedAt": "2026-04-06T00:00:00.000Z"
}