AI Slop

AI slop is content produced quickly with an AI tool and shipped without anyone thinking hard about it. In code, it is the pull request that looks confident, compiles and even passes a glance, yet nobody reasoned about whether it should exist.

What 'slop' means

The word started with writing and images: posts that all sound the same, with the same structure, the same tone and the same stock phrases. The giveaway is not that a model was involved. It is that nothing else was. There is no point of view, no specific detail and no sign that someone checked it was true or useful.

That is the useful definition to hold on to. Slop is not 'anything an AI touched'. It is output where the human part of the job, deciding what is worth saying and whether it is right, was skipped. Prompts go in, posts come out, and taste never enters the loop.

Slop in code

Code has the same failure mode, and it costs more because code runs. AI coding slop tends to share a few traits:

• Large diffs with no context. Thousands of lines changed, with a pull request description that restates the diff rather than explaining the problem it solves.
• No tests, or tests that only exercise the happy path the model imagined.
• No design. The change solves the prompt, not the project's actual problem, and ignores the patterns the codebase already uses.
• No trade-offs. Nobody weighed the alternatives, so nobody can say why this approach was chosen.
• No ownership. When a reviewer asks 'why does this line exist?', the author does not know.

Why it looks fine at first glance

Language models are very good at producing code that is plausible: well named, neatly formatted and idiomatic. Plausible is not the same as correct. The surface signals a reviewer normally uses to judge quality (clean style, sensible names, confident comments) are exactly what a model produces for free, so they stop telling you anything. The bugs hide in the parts that need real understanding: error handling, edge cases, concurrency and how the change interacts with code the model never saw.

Why maintainers pay the cost

Slop moves work from the author to the reviewer. Generating a thousand-line change now takes seconds. Reviewing it properly still takes hours, because the reviewer has to rebuild the reasoning the author skipped: what problem this solves, what it could break and whether it fits the rest of the system.

In an open-source project that cost lands on maintainers, who are often volunteers with limited time. One careless pull request is an annoyance. Fifty of them bury the good contributions, slow down every release and wear out the people keeping the project alive. It also erodes trust: once a few submissions turn out to be unreviewed output, every new contributor gets more scrutiny, including the careful ones.

A worked example

Say you ask an assistant for a function that fetches a user from an API. A typical first answer looks like this:

def get_user(user_id):
    try:
        resp = requests.get(f"{API}/users/{user_id}")
        return resp.json()
    except Exception:
        return None

It reads well and it works in a quick manual test. Look closer and it has three real problems:

1. No timeout. If the API hangs, so does your program.
2. No status check. A 404 or 500 usually still returns a JSON error body, so the caller gets an error message back as if it were a user.
3. Every failure becomes None. The caller cannot tell 'this user doesn't exist' from 'the network is down', so bugs get silently swallowed.

Pasting that into a pull request is slop. Treating it as a draft is not. After reading it, deciding what the behaviour should be and editing it, you get something you can defend:

def get_user(user_id: int) -> dict | None:
    resp = requests.get(
        f"{API}/users/{user_id}", timeout=5
    )
    if resp.status_code == 404:
        return None
    resp.raise_for_status()
    return resp.json()

Now 'not found' is None, every other failure raises, and the program can't hang forever. Then prove it with a test, here using the requests-mock pytest fixture:

def test_missing_user_returns_none(requests_mock):
    requests_mock.get(f"{API}/users/7", status_code=404)
    assert get_user(7) is None

The AI saved typing in both versions. The difference is that in the second, a person made the decisions.

The problem is lazy use, not AI

AI coding tools are genuinely powerful. They are good at boilerplate, at sketching a first version, at explaining unfamiliar code and at suggesting test cases you hadn't thought of. Refusing to use them is not the answer to slop.

The problem is using them lazily: no review, no refactoring and no human brain involved between the prompt and the merge. The tool can write the code; it cannot take responsibility for it. That part is still yours.

How to use AI without making slop

Good AI-assisted coding still needs a developer at every step:

• Guide it. Give it the context it can't see: the constraints, the existing patterns, what 'done' means. Ask for small, scoped pieces rather than a whole feature at once.
• Edit it. Read every line. Delete anything you can't explain, and rewrite anything that doesn't match how the codebase already does things.
• Test it. Run the code, and write or check tests for the edge cases, not just the example that motivated it.
• Explain why it exists. Write the pull request description yourself: the problem, the approach, the trade-offs and how you tested it. If you can't write that, the change isn't ready.

A simple rule of thumb: you should be able to answer any reviewer question about the change without asking the AI.

Keep pull requests small

Small, focused pull requests are good practice with or without AI, and they matter more now that generating code is cheap. A reviewer can reason about a hundred lines that do one thing. A few thousand lines across unrelated files can only be skimmed, which is how slop gets merged.

If you maintain a project

Maintainers can make slop harder to submit without banning tools outright:

• A contributing guide that asks contributors to open an issue before a large change.
• A pull request template that asks what problem the change solves and how it was tested.
• A clear, polite habit of closing large unsolicited changes that come without that context, and pointing to the guide.

Common mistakes

• Trusting clean style as a sign of quality. Models produce neat code by default, so it says nothing about correctness.
• Accepting a whole generated feature in one go. The bigger the output, the less of it you will actually read.
• Letting the AI write the tests for its own code, unchecked. Its tests tend to confirm what it assumed rather than probe what it missed.
• Submitting code you can't explain. If a reviewer's question sends you back to the chat window, you don't own the change yet.

Key takeaways

• AI slop is output shipped without human thinking, review or taste, not simply anything an AI helped write.
• AI coding slop looks confident but lacks design, trade-offs, tests and ownership.
• It shifts the cost onto reviewers and maintainers, because generating code is cheap and reviewing it is not.
• Use AI to think faster, not to stop thinking: guide it, edit it, test it and explain why the change exists.
• Keep pull requests small enough that a person can genuinely reason about them.