The Bottleneck Moved: AI Slop vs. Human Review Capacity

AI slop is not mainly a writing problem. It is what you get when producing output becomes almost free and checking it does not.

On October 11, 2026, an AI assistant told me that the first segment of a generated short film was a huge leap forward and that the hands looked fine. It had not counted the arms. I did, and a third forearm, enormous, sat in the foreground for 4.5 seconds. The clip was unusable.

The model was not the villain in that story. The problem was the step after generation: somebody has to look, count and say no. That step did not get faster when the generating did.

This article is about that gap. I call it the review bottleneck: the point in a workflow where finished-looking output waits for a person who can judge it. I will define AI slop, show the one set of numbers I trust on the bottleneck, walk through three times my own pipeline fooled me, and give the review budget I use now.

Key Takeaways

• AI slop is defined by the missing review, not by the model. The best-known definition calls it unreviewed content handed to someone who did not ask for it.
• The bottleneck moved from creating to judging. In one large dataset, teams with high AI adoption merged 98% more pull requests and their review time rose 91%.
• The producer’s own report is not a check. In my three failures below, the system that made the work also said the work was fine.
• A machine check comes first. I invented 56 faults in a copy of my own code: 50 were caught at once, 6 survived, and now 56 of 56 are caught.
• Budget review before you add output. If the queue of unreviewed items grows, stop generating.
• Never trust a status message as a verification. List what is running, count what is in the frame.

What Is AI Slop? The Meaning Behind the Word

The word “slop” spread fast enough that Merriam-Webster named it its 2025 word of the year. The dictionary’s definition, as the Associated Press reported on December 15, 2025, is “digital content of low quality that is produced usually in quantity by means of artificial intelligence.” Its president, Greg Barlow, listed examples: absurd videos, weird advertising images, fake news that looks real, junky AI-written digital books.

That is the dictionary meaning. The sharper one came earlier. On May 8, 2024, the developer Simon Willison set out what slop means in a short post and said he was “increasingly of the opinion that sharing unreviewed content that has been artificially generated with other people is rude,” and he called slop “the ideal name for this anti-pattern.” He added a limit that matters: “not all AI-generated content is slop. But if it’s mindlessly generated and thrust upon someone who didn’t ask for it, slop is the perfect term for it.”

Put the two together and AI slop has three parts:

Look at the middle row. Slop is not defined by how the text sounds or how the image looks. It is defined by the missing review. The same paragraph is slop if nobody checked it and fine if somebody did.

That is why I think the useful question is not “how do I stop AI from producing slop?” It is “who checks, how much can they check, and what happens when the output arrives faster than they can?”

The AI Bottleneck Moved from Creating to Judging

Before generative AI, making a document, a report or a piece of code took time. That time was a natural throttle. A team could not hand a reviewer more than the team could write, so review capacity and creation capacity roughly grew together.

Now creation scales with compute. Review scales with human attention, and attention is serial: one person reads one thing at a time. When the first number goes up and the second stays put, the queue does the arithmetic.

I use the phrase “the review bottleneck” for that. You can see it in the picture below: the same team and the same single reviewer, before and after adding AI. The numbers in the picture are an illustration, not data.

One dataset that shows it

The best numbers I know come from software teams, where pull requests make review visible. In a report published on July 23, 2025, Faros AI, which sells software to engineering leaders, drew on telemetry from over 10,000 developers across 1,255 teams. It found that developers on teams with high AI adoption “complete 21% more tasks and merge 98% more pull requests, but PR review time increases 91%.” The same report links AI adoption to a 154% increase in average pull request size and a 9% increase in bugs per developer. Faros itself calls the pattern “a critical bottleneck: human approval.”

Read that carefully. It is observational telemetry, not a controlled experiment, so it shows an association and not a cause. Faros sells to the people who care about this problem, so it has an interest in the topic. And it measures code, not marketing.

Still, the shape is what I see in my own work. Output goes up sharply. Each unit of output also gets bigger. The time a human needs per unit goes up too. Nothing in that chain makes review cheaper.

If you work in marketing, replace “pull request” with “campaign report,” “article,” “ad variation” or “landing page.” The structure is identical. Somebody has to approve it before it ships, and that somebody is you.

Why review does not scale like generation

I have four reasons, and they come from my own work, not from a study:

1. Judgment is serial. I can start ten generations at once. I cannot judge ten at once.
2. Fluent output hides its errors. A wrong number in a polished table is harder to catch than a wrong number in a rough note. The better the surface, the weaker my check becomes unless I make it stronger on purpose.
3. Checking needs context that generation does not. The model can produce a clip or a report without knowing what the project is for. The person who reviews it needs to know exactly that.
4. Nobody feels the cost of a skipped review right away. Output ships, the queue shrinks, and the error shows up later, somewhere else, under a different name.

My own estimate, not a measurement: when I build something exactly the way I want it, one feature at a time, I spend about four times the debugging time that a standard, human-only workflow would need. I still save time overall, but it takes longer and is harder than telling the AI to “just do it.” One of my own projects went from a small scope to an enterprise-scale one within hours, not days. Writing code stopped being the slow part. Checking it did not get faster.

Three Times My Own Pipeline Fooled Me

I work with AI agents every day, and I prefer to show you where they failed over repeating a promise. These three cases are real, and each one has the same shape: the system that made the work also reported that the work was fine.

1. The third forearm (October 11)

I was generating a short film in segments. The first segment came back, and the assistant’s report called it a huge leap and said the hands were fine. I had not counted the arms. When I looked, a giant third forearm hung in the foreground for 4.5 seconds.

The report was not a lie in any intentional sense. It was a summary written by the same process that made the clip, and that process had no step where it had to find a defect.

The rule I wrote down afterward: count arms and fingers on enlarged frames, and make the first report start with the defects, not with the praise. If the first report cannot name a defect, I treat it as unfinished.

2. “Successfully stopped” (October 17)

I stopped a shell task that was running tests. The tool answered “Successfully stopped.” The shell and the Python process were still alive. When I killed one of them, the shell launched the next step.

A status message is a claim. It is not a check. A stop that you did not verify is a stop you hope for.

The rule: after stopping anything, list the running processes and repeat until the list is empty. Then continue.

3. A test that could not fail (September 23 to October 11)

An end-to-end test for the tracking on a lead form, dated September 23, blocked the API calls that the tag listens to. The listener never fired, and the test passed every time.

On October 11, I found two lead events fired 50 milliseconds apart where there should have been one. The test I had trusted for weeks could not have seen it. Had I linked that data to ad conversions without catching it, the conversions would have been counted twice.

The rule: a tracking test must let the API answer with a fake success response, so the listener has something to react to. A test that cannot fail is not a test, it is a decoration.

A Machine Check Comes First

Reading code or text carefully is the last line of defense, not the first. If a machine can check something, let it, and keep the human for what a machine cannot judge.

Here is the experiment that changed how I think about it. I have a tool that I use to run and supervise AI agents, with a test suite I considered good. To find out whether it was, I invented 56 faults, planted them in a copy of the code and ran the tests.

• 50 faults were caught at once.
• 6 faults survived. The test suite stayed green while the code was wrong.
• I wrote new assertions for the 6. The final score was 56 of 56.

Six survivors out of 56 is about 11%. A suite I would have called solid let about one fault in nine walk through. The point is not that the tool was badly built. The point is that I would never have known by reading the tests, and a green check is only worth something if you have seen it fail.

I wrote about the human side of this in my piece on human in the loop AI. The short version: a loop that cannot reject is theater. Add a machine check first, then a person, then a record.

How to Spot AI Slop Before You Publish It

Most people look at slop with their eyes first, and that fails because slop is fluent. These are the signs I check instead, each with a test you can run in a minute:

• It states things it cannot source. Test: every number, name and date traces to a page you opened yourself, not to the draft.
• It is generic. Test: could the paragraph appear unchanged on any other company’s website? If yes, it says nothing about yours.
• It contains details that cannot be true. Test: count the limbs and fingers in images, read the text on signs, recompute the totals, check the units.
• It pads. Test: cut a third of it. If nothing is lost, the third was filler.
• Nobody can say who approved it. Test: a name and a date next to the file.

None of these needs a special tool. They need the time that the saved production hours were supposed to buy.

The Review Budget: How I Work Now

The fix is not “review harder.” Reviewing harder does not scale either. The fix is to treat review as a budget, with the same discipline you apply to money.

1. Name the checker for every kind of output

For each type of output, write down who or what checks it, before you generate any. An output with no named checker is not ready to be produced.

2. Put the cheapest machine check first

3. Make the producer report defects first

Ask the generating process to start its report with what is wrong, what it could not verify and what it assumed. A report that opens with praise is the one I trust least.

4. Cap the queue

If the number of items waiting for review passes a limit you set in advance, stop generating until it falls. This is the same idea as a work-in-progress limit in a Kanban board, applied to AI output. A growing pile of unreviewed output is not productivity. It is a liability that has not been invoiced yet.

5. Put a person’s explicit approval in front of money

These are rules I already run with my agents. An advertising campaign changes, or spends, only with my explicit approval, even for a pause. Reading and reporting are free. For paid generations, I get a preflight first, with the model, the number of items and the cost. Then I judge one result before any batch. If that first result is rejected, every following step stops.

6. Keep a record

One line per run: date, who checked, what was found, what changed. In a month the log tells you which manual check to move into code. I describe the five-part loop in more detail in the human in the loop article.

What This Means for Marketing Teams

When a team buys the output side of AI (more drafts, more variations, more reports) and does not budget the review side, the result is predictable. The reviewer, usually a manager, becomes the bottleneck, and their approval turns into a rubber stamp because the queue never ends.

A simple way to see the queue

Take the number of items your tools can produce in a week and subtract the number a person can properly review in a week. If the result is positive, the queue grows by that number every week.

Here is an example with made-up numbers, not data. Your tools produce 120 items a week and one reviewer can properly review 40. The queue grows by 80 items a week, and after a month 320 items are waiting. Nobody reviews 320 items. They skim, stamp or ignore them, and that is how slop leaves a company that never meant to publish any.

Three measurements

If that sounds familiar, I suggest three measurements before you buy anything else:

• Queue size: how many AI-produced items are waiting for a human decision right now?
• Review time per item: how long does a real review take, not a skim?
• Escape rate: of the items that were approved, how many needed a fix after they shipped?

If the queue grows while the escape rate stays flat, you are not catching problems, you are approving blindly. If the escape rate climbs, the slop is already out.

Review is only one reason AI projects stall. My piece on why AI marketing implementations fail covers the wider set of causes, and using AI for marketing covers what two and a half years of daily use taught me about where AI still gets things wrong.

None of this is an argument against using AI. I use it for most of my work. It is an argument for spending the saved production time on the part that cannot be automated: deciding what is good enough to send, and being willing to send less when the review cannot keep up.

Frequently Asked Questions

What is AI slop?

AI slop is low-quality digital content, made with AI and usually in quantity, that is shared without a real review. Merriam-Webster defines it as “digital content of low quality that is produced usually in quantity by means of artificial intelligence.” The key test is whether anyone checked it before it reached a reader who did not ask for it.

What does AI slop mean?

The meaning has two layers. The dictionary layer is low-quality, mass-produced AI content. The working layer, from Simon Willison’s 2024 definition, is unreviewed AI content pushed onto people who did not request it. Not all AI-generated content is slop.

How do you avoid AI slop?

Review before you publish and limit how much you generate to how much you can review. Name a checker for each type of output, run machine checks first, ask the producing system to report defects before praise, and cap the queue of unreviewed items.

Why is it called AI slop?

“Slop” originally meant soft mud and later something of little value, according to the Associated Press report on Merriam-Webster’s choice. People applied it to AI output because of the quantity: a steady, cheap flow of content that nobody asked for.

Is all AI-generated content slop?

No. Content a person asked for, checked and stands behind is not slop, whatever tool made it. Willison makes the same point in his 2024 post.

What is the review bottleneck?

It is my term for the point in a workflow where finished-looking output waits for a person who can judge it. When AI makes creation cheap, that point becomes the limit on how much good work ships.

Can AI review its own output?

It can catch some errors, but it tends to rate its own work favorably, as my third forearm showed. Use a separate reviewer, a rubric and machine checks that can fail.

My Verdict

AI slop is a symptom. The cause is an imbalance: the cost of making fell close to zero, and the cost of judging did not move. You cannot fix that by writing better prompts. You fix it by giving review a budget, a named owner and a machine check that can say no.

The card:

1. Name the checker before you generate anything.
2. Run the machine check first.
3. Ask for defects before praise.
4. Cap the queue of unreviewed output.
5. Put explicit approval in front of money.
6. Verify every “done” and every “stopped.”
7. Keep a record and move the manual checks into code over time.

The Faros figures are as published on July 23, 2025, and the dictionary definition as reported on December 15, 2025. The cases and counts from my own work are dated in the text.

Want a second pair of eyes on how your team reviews AI output, with a checklist matched to your workflows? Talk to me about your review process.