I bought a Frigidaire window AC unit last summer. The manual had twenty-two pages of safety warnings before it told me how to install the thing. Page count has tripled since nineteen ninety on that exact model line, and almost all of the new pages are some variation of "don't eat the refrigerant." Daniel got a version of this rant from his father-in-law and he's turned it into a four-part puzzle for us. One — what's the structural reason manuals are like this? Two — why are car manuals the exception that proves the rule? Three — what does good documentation actually look like, and he points to disaster recovery plans as the model. Four — can AI break the cycle, or does it just amplify the verbosity?
The car exception is the key that unlocks the whole thing. Most people assume car manuals are good because cars are complicated. That's exactly backwards. They're good because Toyota and Honda have an economic incentive to make them good — dealerships spend less on service when owners can diagnose things themselves, and cars have a ten-to-fifteen-year ownership lifecycle with no guarantee of internet access in year eight. The manual is a cost-reduction tool disguised as a booklet.
So the AC unit manual isn't bad because the writers are bad. It's bad because nobody who matters wants it to be good.
That's the mechanism. And it's worth walking through it carefully, because everything else — the AI question, the prompting techniques, whether this gets better or worse — hangs on understanding why the incentives point toward garbage.
To understand why AI might help, we first have to understand the mechanism that made manuals so bad in the first place. Walk me through it.
The core mechanism is asymmetric risk. A manufacturer faces two possible bad outcomes from their manual. Outcome one — a user is frustrated because they can't find the troubleshooting section, they call support, they leave a bad review. That costs the company maybe fifty dollars in support time and some reputational damage spread across tens of thousands of units. Outcome two — a user is injured, sues, and the plaintiff's lawyer argues the manual failed to warn them. That costs millions. So the manual optimizes for outcome two. Every page of safety preface is insurance against a deposition, not help for a user.
And the thing is, most of that insurance isn't even legally necessary.
Right — and this is the part that makes technical writers pull their hair out. Liability protection in product liability law comes from two things. Having a manual at all, and not making false claims in it. You don't need a twelve-page safety preface to be protected. You need to have warned users about non-obvious dangers in a way they can find. But corporate legal teams don't operate on "what's legally sufficient." They operate on "what will prevent a lawsuit from being filed in the first place." So they overcorrect, and the manual balloons.
And the sections users actually need get squeezed.
Seventy-eight percent of manual readers skip straight to troubleshooting. That's the number from user behavior research on technical documentation. People don't open a manual because they're curious about features. They open it because something isn't working, they're already frustrated, and they want the shortest path from confusion to resolution. And yet the troubleshooting section is consistently the thinnest part of the book. The legal preface gets the page budget. Troubleshooting gets whatever's left.
Which is where Daniel's disaster recovery parallel lands. You're reading that document at ten PM on a Sunday while a server is on fire. If it's prosaic or complicated, you're done.
The DR doc principle is the single best heuristic in technical communication. Write for the person who will read this under stress, with limited time, and with something already broken. That means task-oriented structure — one task per section. Plain language at a sixth-to-eighth-grade reading level. Visual hierarchy where warnings are visually distinct from instructions so you can skip them when you need to. And the chunking principle — no section longer than what can be scanned in about thirty seconds.
And car manuals actually do this.
Toyota's RAV4 manual is the exemplar that gets studied in technical communication programs. It opens with a seven-page quick reference guide — just the things you need in the first week of ownership. Then color-coded sections for each system. A dedicated troubleshooting index that accounts for fifteen percent of total page count. And they test these manuals with real users — they bring people in, hand them the manual, and watch where they get stuck. Consumer appliance makers almost never do that.
Because the incentive isn't there. Frigidaire doesn't save money if I install my AC unit faster.
The car industry is the exception because the economics are different. A Toyota owner who can reset their own maintenance light doesn't book a service appointment. Multiply that across millions of vehicles and it's real money. Plus, cars have regulatory requirements for manual content that actually align with user needs — the NHTSA requires certain information to be present and findable. It's not all altruism. But the result is a document that works.
So we know why manuals are bad. Now let's define what good actually looks like — because that standard is what we'll ask AI to meet.
The technical communication research converges on about four principles. First, task-oriented structure. Don't organize by feature — "the timer function," "the sleep mode" — organize by what the user is trying to do. "Setting the timer," "putting the unit into sleep mode." One task per section. If a section covers two tasks, split it.
Second?
Plain language. This one's measurable. You target a sixth-to-eighth-grade reading level, which you can check with any readability formula. Short sentences. Active voice. No nominalizations — don't say "activation of the cooling function is achieved by," say "to start cooling, press." The person reading this is already annoyed. Don't make them parse a sentence twice.
Third — visual hierarchy.
Warnings, cautions, and notes need to be visually distinct from instructions. The reader under stress needs to be able to scan past the safety content and land on the step they need. If warnings and instructions use the same font, same weight, same color, the reader has to process everything linearly, and that's exactly what drives people to throw the manual across the room.
And fourth, chunking.
No section longer than what can be scanned in thirty seconds. That's typically about a hundred and fifty to two hundred words, or five to seven steps. If a procedure has more than seven steps, break it into sub-procedures with their own headings. The cognitive load of a twenty-step list is too high for someone who's already stressed.
The thing that strikes me about all four of those is that they're constraints, not content. You don't need a better writer. You need a better set of rules.
And that's exactly why AI is interesting here. Most people know what needs to be documented. They just never format it. The bottleneck is capture, not knowledge. Daniel's dictation workflow — talk through a process, have AI turn it into presentable documentation — solves the capture problem. But it only works if the AI is constrained properly.
Those principles are great in theory. But Daniel's question is really about whether AI can actually produce documentation that follows them — and how to stop it from falling into the same traps.
The failure mode is real and it's measurable. If you open GPT-four-o and type "write a manual for my home server setup," you'll get about three thousand words of legally-cautious, feature-oriented boilerplate. It'll start with a section called "Important Safety Information." It'll warn you about electrical hazards. It'll use passive voice. It'll organize by component — "the power supply," "the cooling system" — rather than by task.
It mimics the worst human manuals because those are overrepresented in the training data.
That's the core problem. The training data contains vastly more bad manuals than good ones, because vastly more bad manuals exist. The AI's default behavior is to reproduce the median — and the median is terrible. So the solution is system prompting that encodes good principles as hard constraints.
Walk me through the specific techniques.
Five of them, and they stack. First, assign a persona. "You are a senior technical writer at Toyota with twenty years of experience writing owner manuals." This sounds like a gimmick but it actually shifts the model's distribution — it pulls toward the subset of training data that contains structured, task-oriented documentation rather than legal boilerplate.
Second.
Specify format. "Output as a numbered checklist with no paragraphs longer than three sentences." This is a hard structural constraint. The model can't produce a wall of text if you've told it each paragraph caps at three sentences.
Third — constrain length.
"Maximum five hundred words." This forces the model to make choices about what matters. It can't include a safety preface and a feature catalogue and troubleshooting. It has to pick. And when forced to pick, it tends to pick the things users actually need.
Fourth is the negative constraint.
"Do not include any safety warnings or legal disclaimers." You have to say this explicitly because the model's default is to include them. If you don't forbid them, they'll show up. The model doesn't know that the legal content is unnecessary — it just knows that most manuals include it.
And fifth — provide a template.
"Fill in this structure: quick start, troubleshooting, maintenance." Now you're not just constraining what the model shouldn't do. You're giving it a positive shape to fill. The model's job becomes slot-filling rather than structure-invention, and slot-filling is something language models are very good at.
I want to test the difference. Same home server setup. Raw prompt versus system-prompted.
Raw prompt gives you something like... "Important Safety Information. Please read all instructions before operating your home server. Ensure proper ventilation. Do not block air vents. Contact a qualified electrician if..." and it goes on for three pages before it mentions a single thing about configuring the server. The system-prompted version starts with "Quick Start: One, connect power and ethernet. Two, access the web interface at the router-assigned IP address. Three, create your admin account." That's it. Three sentences, and you're in.
The difference is the difference between a document you keep and a document you throw away.
And here's the meta-insight. AI documentation is already the norm. The Society for Technical Communication ran a survey in twenty twenty-five — sixty-two percent of technical writers now use AI in their workflow. The question isn't whether to use it. It's whether we encode good principles or bad ones into the prompts.
So the risk is that organizations prompt AI to mimic their existing bad manuals and get more of the same at scale.
That's exactly the knock-on effect. I've seen a real example of this — a consumer electronics company told their AI tool "write a manual like our existing ones." The existing manual was forty pages of legal-heavy, feature-oriented boilerplate. The AI produced a forty-one-page version that was structurally identical, just with slightly different phrasing. They scaled their badness perfectly.
They automated the wrong thing.
The opportunity is to use AI as a forcing function. AI can follow constraints more reliably than humans can. A human technical writer, told "no paragraphs longer than three sentences," will eventually slip. They'll write a four-sentence paragraph and not notice. The AI, if the constraint is in the system prompt, will follow it every time. So if you encode good principles, you get good documentation at scale in a way that wasn't possible before.
Which means the principles have to come first. You can't prompt your way out of not knowing what good looks like.
Right. The prompt engineering techniques — persona, format, length constraint, negative constraint, template — those are just a delivery mechanism for the principles from Part One. Task-oriented structure, plain language, visual hierarchy, chunking. If you don't know those principles, your prompt won't encode them, and you'll get verbose mediocrity with better grammar.
So where does the dictation workflow fit in?
Dictation solves the capture bottleneck. Most people, Daniel included, know their home server setup. They could explain it to a friend in five minutes. But they'll never sit down and write a manual because formatting is tedious and they don't know where to start. Dictation removes that friction. You talk through the process — "first I plugged in the power and ethernet, then I opened a browser and went to the router page to find the IP address" — and the AI structures it. But the AI needs to be pre-loaded with the constraints, or it'll take your five-minute dictation and inflate it into a three-thousand-word document that buries the actual steps.
The AI is the formatting layer, not the knowledge layer.
That's the right way to think about it. The human provides the domain knowledge — what needs to be done and in what order. The AI provides the structure — headings, numbered steps, consistent formatting, appropriate level of detail. The human is the expert. The AI is the technical writer who never gets tired of applying the style guide.
I'm thinking about the disaster recovery parallel again. The person reading that document is under stress. If the AI produced it, and the AI was poorly prompted, the document fails exactly when it's needed most.
That's the nightmare scenario. You're restoring from backup at two in the morning, your production database is down, and the recovery document is twelve pages of AI-generated prose that starts with "In the event of a data loss incident, it is important to remain calm and follow these comprehensive procedures..." No. Give me a numbered list. Step one, step two, step three. If step four has a decision point, give me "if X, go to step five. If Y, go to step eight."
The DR doc is the ultimate test. If your documentation works for someone who's sleep-deprived and panicking, it works for everyone.
And that's the standard we should hold AI-generated documentation to. Not "does it look professional." Not "does it cover every edge case." Does it get a stressed user from confusion to resolution in the minimum number of words.
I want to circle back to something you said earlier about the legal content not being legally necessary. That seems like the kind of thing that should be more widely known.
It should be, but it's not in the interest of corporate legal departments to broadcast it. The dynamic is... imagine you're a lawyer at a mid-size appliance company. Your predecessor put a twelve-page safety preface in every manual. You could cut it to two pages and be legally fine. But if you cut it and then, three years later, someone is injured and the plaintiff's lawyer asks why you removed safety content, you have to explain yourself. Most in-house lawyers would rather keep the twelve pages and never have to have that conversation.
So the bloat is sticky. Nobody gets fired for keeping the safety warnings.
Nobody gets fired for keeping the safety warnings. And nobody gets promoted for making the manual more usable, because the ROI on usability is diffuse and hard to measure. The support cost savings are real but they show up in a different department's budget.
Hilbert: Forty thousand dollars a year.
What?
Hilbert: That's what we spent translating the safety preface. Fourteen languages. The legal section alone cost more to translate than the entire rest of the manual — the parts people actually used. I was a technical writer for a commercial ice machine company in the late nineties. My boss was a former lawyer. He insisted on a twelve-page safety preface in every manual. I looked up the actual case law. The protection comes from having a manual at all and from not making false claims. The twelve-page preface was just the CEO being scared of a lawsuit that had never happened. We could have cut it to two pages and been fine.
Forty thousand a year just on translating text nobody reads.
Hilbert: And it made the product worse. The support calls we got — half of them were questions answered on page fourteen of a manual where the user gave up on page six because the safety preface never ended. So we paid forty thousand dollars a year to increase our support costs.
The economic stupidity of it is almost impressive.
Hilbert: The manuals went out with every unit. About two hundred thousand units a year. Each manual was, I think, sixty-four pages. The safety preface was twelve of those. So we printed roughly two point four million pages of safety warnings annually that nobody read, in fourteen languages, at a translation cost of forty thousand dollars, and then paid support staff to answer the questions those pages were crowding out.
The second-order cost is the part nobody models. The legal department sees the safety preface as free insurance. It's not free. It has a printing cost, a translation cost, and a support cost. And the support cost scales with every unit sold.
Hilbert: I brought this up in a meeting once. Showed them the numbers. The head of legal said, and I remember this exactly, "I appreciate the analysis, but I'm not going to be the one who removed the warnings if something happens." Meeting over.
So the mechanism you described earlier is exactly right. Asymmetric risk. The lawyer faces personal career risk from removing warnings. The company faces diffuse, hard-to-measure costs from keeping them. The lawyer wins every time.
And that's why the solution probably isn't internal reform. It's external pressure, or it's AI that lets individual users generate their own documentation and bypass the official manual entirely.
Hilbert: The ice machines had a quick-reference card. Laminated. About the size of a postcard. It had the five things that actually went wrong and how to fix them. We printed those separately and they cost about twelve cents each. Users loved them. The legal department had nothing to do with them because they weren't officially the "manual." They were a "supplemental guide."
So you hacked your own company's legal process by calling it something else.
Hilbert: Called it a quick-start guide. No safety warnings. Just "if the ice is cloudy, clean the filter." Support calls dropped about twenty percent the quarter after we started including them.
That's the DR principle in action. Give people the minimum they need when something's wrong. Hide it in plain sight if you have to.
Hilbert: The quick-start guide is still in my kitchen drawer. Not the ice machine — that died years ago. Just the guide. It's a good reminder.
Where does this leave us? We have the principles, we have the AI tools — but the outcome depends entirely on how we prompt.
The open question that keeps me up is whether we're heading toward a race to the bottom or a race to the top. AI-generated documentation is going to be the default. That's already happening — sixty-two percent of technical writers are using it. The question is whether the defaults win. If most organizations prompt AI with "write a manual like our existing one," we get an avalanche of verbose, legally-cautious, feature-oriented documentation that's worse than what we have now because there's more of it.
But if the principles get encoded — if the system prompts spread the way good prompts tend to spread in technical communities — you could get a step change in documentation quality. Not because the writers got better, but because the constraints got better.
The car industry proves it's possible at scale. Toyota produces millions of vehicles and millions of manuals, and the manuals are good. They're good because someone decided they should be good and built a process that enforces quality. AI gives the rest of us access to that kind of process without needing Toyota's budget.
The best manual is the one you don't have to read. But when you do need it, it should be the shortest path from confusion to resolution. That's the standard we should hold AI to.
It's the standard the car industry already meets. The RAV4 quick reference guide is seven pages. The Frigidaire safety preface is twenty-two. One of those documents respects your time and intelligence. The other is a legal document that happens to be stapled to a product.
Thanks to our producer Hilbert Flumingtop for keeping this show running and for the laminated quick-start guide that probably still works better than most modern manuals.
This has been My Weird Prompts. You can find us at my weird prompts dot com, and if you've got a manual that made you angry enough to write in, email the show at show at my weird prompts dot com.
We'll be back soon.
