I reviewed an ADR recently, and I could tell it was AI generated within the first paragraph.

Random words were bolded for no reason. Em dashes everywhere. The same point showed up three or four times, reworded just enough that you had to read each one to make sure it wasn’t saying something new. And by the end it had wandered well past what the ADR was supposed to decide, into recommendations nobody had asked for.

An ADR has one job. Here’s the context, here’s what we decided, here’s why. It’s supposed to be short so someone two years from now can open it and understand the decision in a few minutes. When it’s padded and repeats itself, the reader has to dig the decision out, and at that point the doc isn’t doing its job.

I left comments, worked through it, and moved on. It’s not worth turning into a fight. But it’s become a pet peeve of mine, because it’s not the first time and it won’t be the last.

If it took you ten seconds to generate it and you didn’t have time to read it, why should I?

That’s the whole issue for me. It’s not that someone used AI. I use AI for docs all the time. The problem is that nobody read it before handing it to someone else to read. The work of understanding the doc didn’t go away. It just got passed to the reviewer.

Turns out I’m not the only one losing patience with this. Harvard Business Review gave it a name last year: workslop. Their definition is AI-generated work “that masquerades as good work, but lacks the substance to meaningfully advance a given task.”

The word that stuck with me there is masquerades. That ADR looked like an ADR. It had the headings, the formatting, the bold text. At a glance it looked more polished than most of the ones people write by hand. That’s the trap. The polish makes it feel finished, so the author sends it, and the reader is the one who finds out it isn’t.

HBR’s survey with BetterUp and Stanford put a rough number on what that costs. About 40% of people said they’d received workslop, and they reported spending close to two hours dealing with each one. I believe it. Most of my time on that ADR wasn’t spent reviewing the decision. It was spent figuring out what the decision was. Reading the same point four times to confirm it was the same point. Working out which sections actually belonged in an ADR and which ones I could skip.

But the time isn’t really what bothers me most. Oxide’s internal policy on using LLMs gets closer to it. They describe writing as a kind of social contract. Normally the writer has done the harder thinking, so if a reader struggles with an idea, “they can reasonably assume that the writer themselves understands it.”

That’s exactly what broke for me. When the ADR started recommending things outside its scope, I couldn’t tell if the author actually wanted those things or if the AI just kept going. Should I push back on them? Ask about them? Ignore them? With a doc someone wrote themselves, I’d assume they meant what they wrote. With this one, I had no idea whether anyone did.

Code works the same way. Nobody would (well, nobody should) merge a PR full of AI-generated code they’ve never read. A design doc deserves the same treatment. Oxide’s policy says it in one line: “Oxide employees bear responsibility for the artifacts we create, whatever automation we might employ to create them.” If your name is on it, you own what it says, whether you typed it or not.

I’m not anti-AI on this, though. Some people are. Colin Breck’s recent post I Don’t Want to Read What You Didn’t Write comes close to a case against AI writing altogether. He says he doesn’t want to live in a world where “you use AI to summarize something important into unreadable text, and then I use AI in an attempt to decipher it.” I get it, but I’m not there. Even Breck makes room for AI as a tool for someone who’s actually doing the writing: checking facts, fixing grammar, editing.

Roland Huß is closer to where I land. His post has a title that could have been mine, AI Wrote It. Nobody Read It. His argument is that drafting with AI is fine, and shipping the draft without a real review is the problem. He also points out why internal docs get hit the hardest: your coworkers don’t get to close the tab. A bad blog post just goes unread. A bad ADR still has to be reviewed, approved, and lived with.

That’s the line for me. AI as the writer’s assistant is fine. AI as the writer, with nobody behind it, isn’t.

So what should change? A few things, and most of them aren’t complicated.

Read it before you send it. This is the whole thing, really. Camille Fournier’s Guidelines for Respectful Use of AI opens with it: don’t ask colleagues to review what you haven’t reviewed yourself. She describes the trap perfectly: “It’s easy to get into a loop where you ask the AI some questions, skim the answers, output a document and send it to others.” If you haven’t read it closely enough to defend every line in a design review, it isn’t ready.

Cut it down. AI loves to be thorough. An ADR doesn’t need thorough, it needs decisive. If the doc covers more than the decision, cut until it doesn’t. Fournier makes the same point: shorter is better. The reader’s time is the expensive part now, not the writer’s.

Be honest about how much you reviewed. Both Fournier and Huß suggest saying so when a doc is AI-drafted and you’ve only given it a light pass. Something like “this is AI drafted, I’ve reviewed the decision section but not the appendix, please flag anything off.” I’d rather get that than a doc pretending to be finished. At least I know where to be careful.

Remember what the doc is actually for. Graham Gilbert wrote a good post called AI Can Write the RFC. It Cannot Build Alignment. His point is that the document was never the hard part. “AI does not know why a system exists in its current form.” It doesn’t know which tradeoffs were deliberate, whose system you’re about to call legacy in writing, or what’s already been tried. An ADR is a record of a decision people actually made. If the AI made it, you don’t have an ADR. You have a guess.

Fix the tool, not just the doc. This is the one I’d push hardest on. I’ve spent real time building out the skills my AI agents use for writing docs, so they’re detailed enough to produce something I’d actually put my name on. I proofread every doc they generate. And when something’s off, I don’t just fix the doc. I go back and fix the skill so it doesn’t happen next time. I’ve also picked up skills other people have published and adopted the ones that were better than mine. One of the first rules I wrote into my own setup was no em dashes. Once you start noticing them, you see them everywhere.

That’s the part I think most people skip. They treat the AI output as the finished product, when really it’s a first draft from a writer who doesn’t know your standards yet. You have to teach it, and you have to check its work until you trust it. Even then, you keep checking.

There’s one more piece, and it’s not on the individual. A lot of companies are telling people to use AI without ever saying what good looks like. If the only message is “use AI,” you get exactly what I got in that ADR. That’s on the org as much as the person.

That’s where my head is for my team. I’ve suggested we build our own skill from the infrastructure architecture side for writing ADRs, RFCs, and the rest: same template, same style, our standard. Then we share it out to other teams. If people are going to use AI to write these docs anyway (and they are), I’d rather they start from something that already knows what a good ADR looks like.

It won’t fix everything. A good skill doesn’t replace reading your own doc. But it raises the floor, and it puts the effort where it belongs: before the doc gets to the reviewer, not after.

I’m curious how other teams are handling this. Are you seeing it too? Has anyone set standards for AI-written docs that actually stuck?