8 min read ·
The slop grenade
It lands in the team channel at twenty to seven on a Thursday evening: a link to a fifty-page document, with one line on top. "I've thought through all the details." Nobody on the team has read it yet. Neither has the person who sent it.
I call this a slop grenade. Pulling the pin costs one prompt. The blast lands on everyone else.
In March I wrote about corporate ADHD, the habit of walking into a working project with vocabulary instead of questions. This is the sequel. The vocabulary now arrives with a table of contents.
You've seen one. It has an executive summary, a phased roadmap, a risk register with a mitigation for every risk, a data model with every entity anyone could think of, and an API section full of endpoints for a system nobody on the team has touched. The headings are crisp. The tone is calm. It reads like the work of someone who spent a month on the problem.
Somebody spent an afternoon on it. Mostly waiting.
And somewhere in the middle, it's wrong. A field the database doesn't have. A migration plan for a table that was deleted last year. The model filled a gap. That's what these models often do when the prompt doesn't contain the answer, and the prompt almost never contains the answer.
Because the hard part of a real problem never fits in a chat box. It lives in a blank column that means three different things depending on who left it blank. A date field that holds two formats because two systems write to it. A status that the sales team reads as "done" and support reads as "waiting on us." I've spent the last year putting models into operations work, and nearly every hard problem I hit was a data problem like that. The people who know why the column is blank are the spec. They weren't in the prompt, so the document guessed, and a guess that sounds sure of itself is the worst kind.
The author didn't catch it, because the author never got to the middle. They skimmed the headings, liked the tone and hit send.
Here's why this hurts more than a bad document ever did.
A long document used to be a receipt. When Jeff Bezos explained why Amazon runs meetings on six-page memos instead of slides, he wrote in his 2017 letter to shareholders that "the great memos are written and re-written" and that "a great memo probably should take a week or more." Six pages, a week. The length was evidence that somebody had wrestled with the thing. At Amazon the room reads the memo in silence at the start of the meeting. When you sat down with one, you were spending your time on someone else's thinking.
Pascal had it figured out centuries earlier. He ended one of his Provincial Letters by apologizing for its length, because he hadn't had the time to make it shorter. Short is the expensive version. Short means you made the decisions.
AI flipped the price tag. Fifty pages now cost nothing. Three good pages cost exactly what they always did, because the cost was never typing. It was knowing which forty-seven pages to throw away.
So a fifty-page document no longer proves that anyone thought. It proves that someone had a subscription.
Now do the arithmetic on the receiving end.
Say the team is eight people. A careful read of fifty dense pages, the kind where you check claims against what you know about the system, is most of a day. That's eight days of engineering against one afternoon of prompting. And reading is the cheap part.
The expensive part is reconciliation. Everyone comes back with questions, and no two lists match. Is the event bus on page 12 the same as the queue on page 30? Did we agree to support the old API, or is that just in here? The questions go to the author, who can't answer them, because the author hasn't read it either. So the author asks the model. The model writes a fresh, confident answer that quietly contradicts page 12, and now there are two documents.
There's a name for this asymmetry. In 2013, the programmer Alberto Brandolini put it in one line: the energy needed to refute bullshit is an order of magnitude bigger than the energy needed to produce it. He meant arguments on the internet. It now describes a Thursday evening in a team channel.
And that's the good outcome, where people actually read. There are two worse ones.
In the first, nobody reads it. Everyone assumes someone else did. The document sits in the drive, unchallenged, and silence turns into approval. Three months later somebody quotes page 31 in a planning meeting as if it were a decision, and the team discovers it has been committed to a requirement that no person ever chose.
In the second, everyone feeds it to their own model and asks for a summary. Now you have a document that nobody wrote, summarized for people who won't read it, and discussed in a meeting where the only participants who saw the whole thing were machines.
This isn't only my grumbling.
In September 2025, researchers at BetterUp Labs and Stanford's Social Media Lab gave it a name in Harvard Business Review: workslop, "AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task." Their sharpest point is about where the work goes: it moves from the person who made the thing to the person who has to receive it. In their survey of US desk workers, 40% said they had received some in the past month, and each instance took close to two hours to deal with. About half said they then saw the sender as less capable and less reliable. Forty-two percent said less trustworthy.
That last number is the one I'd worry about. Teams run on trust. Every slop grenade spends some of it, and you don't get it back by sending a longer document.
Big firms throw them too. In October 2025, Deloitte agreed to refund part of the AU$440,000 the Australian government had paid for a 237-page review of automated penalties in its welfare system. Chris Rudge, a welfare-law researcher at the University of Sydney, had found references to research papers that don't exist and a quote from a federal court judgment that the court never wrote. The revised version disclosed that Azure OpenAI had been used in writing it. Two hundred and thirty-seven pages, and the reader who caught it didn't work at the firm.
Open source pays the reading bill in public. Seth Larson, who triages security reports for Python projects including pip and urllib3, wrote in December 2024 about a new era of slop security reports, and put the whole argument in one sentence: "This reviewing time should be paid first by you, not open source volunteers." A year later, curl, the small open-source tool that fetches URLs inside a huge share of the software you use, stopped paying. Daniel Stenberg ended the project's bug bounty, which paid outsiders for finding real security holes, in January 2026. In earlier years, north of 15% of submissions turned out to be real vulnerabilities. Starting in 2025, that fell below 5%. Stenberg said the slop takes "a serious mental toll to manage and sometimes also a long time to debunk." curl's maintainers were paying, in time and patience, for reports that cost the sender a prompt.
I'm not against the tool. I let models draft plenty I would never type by hand. A model that writes fifty pages in an afternoon is a fine way to think out loud. Generate the document. Argue with it. Steal the two good ideas.
The sin is sending it unread, under your name, as if you knew what was in it.
The hallucination is the model's fault. Pretending you read it is yours.
"I've thought through all the details" is a small lie with a big blast radius. It claims an understanding you don't have and hands the work of earning it to everyone downstream. It's the same trade I wrote about in March: a reset is cheap for whoever calls it. The slop grenade makes the reset bigger and lets it pose as diligence.
So read what you send. All of it. If a page makes a claim about the system, check it against the system, or make the model show its work and then go look at the source yourself. If you can't defend a page, delete it. If that leaves three pages, send the three. Your team will read three pages, and they will believe the next thing you send.
At twenty to seven on a Thursday, your team doesn't need fifty more pages. It needs you to have read the first one.