Why We're Writing More and Saying Less
Last month I sat down to write a post about my experience building an application using Claude, along with my pitfalls and what I learned.
I was under a time crunch and ended up leaning heavily on AI tools to help me coalesce my thoughts and write the article.
It wasn't until after I pushed the article live that I noticed it said a lot, but somehow said nothing.
This is the cost of over-relying on AI to help us write. You've probably seen it as well in pull request descriptions, internal write-ups, and Slack messages. Long, meandering content that looks solid but doesn't have any substance.
How do you take advantage of AI tools without generating AI slop? Let's talk through the signs of poorly generated AI content, the impact it can have on a team, and how to resist the pull to quickly generate something and push it out to the world.
Length Without a Point
The easiest sign to spot is length that doesn't go anywhere. A pull request description that walks through every file changed but never says why the change was needed. A Slack reply that takes three paragraphs to answer a yes or no question. An internal write-up with ten sections that all circle the same idea.
Poorly generated content tends to share a few traits:
- It meanders. The piece covers a lot of ground but never commits to a point, usually because the author never decided on one before handing the work to AI.
- It over-explains. Unless you tell it who's reading, AI explains everything. Your team ends up reading a definition of a term they use every day.
- It doesn't sound like you. The phrasing gets smoother and more generic, and the specific opinions and judgment calls that made it yours disappear.
My first draft had all three. None of them are obvious while you're writing, because the content looks complete. They show up when someone is reading it.
The Reader Pays for the Shortcut
Last year I wrote about using AI for the work around coding, including drafting a first pass at documentation. What that post didn't cover is who pays for the shortcut.
When AI speeds up the author, the cost often lands on whoever reads the result. DORA's analysis of more than 1,100 survey responses from Google engineers found this with code. Authors could use AI to produce large pull requests quickly, but reviewers were still expected to check every line, so the author's saved time often turned into extra work for the reviewer.
The same thing happens with a write-up or a Slack message. Every step the author skips becomes a tax on the reader, who has to figure out the point and fill in the context that never made it onto the page.
Researchers at Stanford and BetterUp found that 40 percent of workers had received AI-generated work in the last month that looked finished but didn't move the task forward, and that each instance took nearly two hours to deal with.
Say you post an AI-drafted write-up to a channel of eight engineers, and each of them spends twenty minutes working out what it's proposing. You saved an hour writing it. Your team lost almost three hours reading it.
The same research found that close to half of the people who received this kind of work saw the sender as less creative and less reliable. Nearly one in three said they'd be less likely to want to work with that person again. For a lot of your coworkers, your writing is the main way they see your thinking, especially the ones who don't work with you every day.
|
|
Where can AI save you time?
My friends at Big Creek Growth put together a quick survey to spot the repetitive work you can hand off to automation.
|
|
Keep the Thinking, Hand Off the Cleanup
What caught my own draft was a simple reread. I just did it after the article was already live. Step away, then reread before you share anything. Read it as the person on the receiving end. What would they learn? What would they still have to ask you?
For a Slack message, that might be a thirty-second pause before you hit send. For a design doc or write-up, it might mean waiting until the next morning. Fresh eyes show you the gaps that looked fine while you were writing.
Rereading catches the problem. These habits keep you from creating it in the first place:
- Decide your point before you prompt. Write one sentence that says what you want the reader to know or do. If you can't write that sentence yet, AI will fill the gap with length.
- Bring what only you know. The decision you made, the constraints you're working within, and what you tried that didn't work won't show up unless you put them there. Those are the details your reader can't get anywhere else.
- Let AI handle the cleanup. Once the thinking is on the page, it's good at tightening the writing and connecting the dots.
- Cut what your reader already knows. If you're not sure who you're writing for, the audience card from You Are Writing Documentation Wrong is a good place to start.
All of this takes longer than pasting in a prompt, which is how my first draft happened. I was short on time, so I let AI do the writing. When you're in that spot, send less instead of generating more. A three-sentence update with a clear point costs your reader less than a long one you only skimmed.
Not everything needs this much care. A PR description for a dependency bump or a routine changelog entry is a fine place to let AI do most of the work. The more a piece asks of your reader, the more of it should come from you.
Here's how this plays out in a pull request description. This is what you get when AI writes it from the diff:
This PR introduces several improvements to the notification service, including refactoring of the delivery handler, enhanced error handling, and updated tests to ensure reliability and maintainability.
This is what it looks like when the author brings what only they know:
Why: When a webhook delivery times out, we drop the notification and support has to resend it by hand. That happened about 40 times last month.
What changed:
• Failed deliveries now retry up to three times with backoff (1s, 5s, 30s).
• Retry logic moved out of DeliveryHandler into a RetryPolicy class so we can reuse it for email.
• Timeouts and 5xx responses retry. 4xx responses fail immediately, since retrying won't fix a bad payload.
How to test: Point a webhook at the mock endpoint in test/fixtures with FAIL_FIRST=2. The third attempt should succeed and log a single delivery.
Review focus: The backoff values. I capped the total wait around 36 seconds because the partner API rate-limits bursts, but I'm not confident that's the right ceiling.
Rollout: Behind the webhook-retries flag, off by default.
The second version is longer, and every line gives the reviewer something they'd otherwise have to dig for or ask about.
I didn't delete the first version of that article or quietly replace it. I added a note at the top explaining where I leaned on AI too hard and linked to the original so anyone could compare the two.
It was a fitting lesson for an article about building with AI. Leaving the failed draft up turned my mistake into a reminder of what happens when we hand over the reins, and the line I wrote in that note still holds: the tool moves you fast, but the judgment has to stay yours.
If you catch this in something you've already sent, try what I did. Leave it up, say what went wrong, and let your team see the difference.