Polish is not proof that the work is finished.
Armin Ronacher describes a recurring failure in Pi’s issue tracker. A user has one useful observation, then asks AI to improve the report. AI adds confident root-cause guesses, fake-minimal reproductions, implementation advice, and long lists of possible errors. Maintainers must recover the original fact from polished fiction. Their coding agents may even treat that fiction as evidence and investigate the wrong path.
Ronacher asks for less: what you ran, what you expected, what happened, and the exact error. Analysis can follow, but the issue itself should contain facts the reporter owns.
I use this working definition, based on the sources below.
AI slop looks finished even though something important is missing: a clear purpose, evidence that it works, or someone who owns the result. The unfinished work is left to the next person.
This is false completion: the output looks done, but the work needed to trust it is not.
The definition is not “AI made it.” Simon Willison calls slop unwanted, unreviewed AI content. In his words, it is “mindlessly generated and thrust upon someone who didn’t ask for it.” Not all AI-generated work is slop.
Generative AI can produce the shape of finished work before anyone has decided what the work is for.
Caleb Gross separates a creative work into intent—what it is for—and material form—the thing produced. Creating by hand normally forces you to shape form toward a goal. AI can instead produce “substantial form with minimally applied intent,” even when the goal remains vague.
Humans can produce the same failure; AI lowers the entry barrier.
That is why slop can look competent. The issue has headings. The proposal has trade-offs. The code compiles. But those signals do not say who the work is for, what constraints matter, or whether it is ready.
A clear purpose does not guarantee good work. Without one, though, the recipient cannot know what the work should do, and without evidence they cannot know whether it succeeded.
Slop saves the sender time by making the recipient do the missing work.
Charity Majors offers a simple rule for communication: do not send people material you have not read. She adds that it is probably slop when the recipient will spend longer reading it than you spent making it. The sender saves attention by spending the recipient’s.
Her rule of thumb is useful, but time alone does not decide it. Expert work can be quick to produce and slow to verify. Ask instead: did the sender provide enough evidence for what they claim, or leave the reading, fact-checking, and cleanup to someone else?
Collaboration always transfers work. A requested draft, disposable prototype, or partial implementation is not slop just because someone else must continue it. A good handoff says what is unfinished and confirms that the next person agrees. Slop hides that work behind a finished surface.
AI can write the words or code; a person still has to own the result.
The evidence needed depends on the medium and the risk. Reading every word is a reasonable baseline for an email or issue report. For software, the same interview asks what evidence would make unread generated code safe to ship. Tests, comparisons, and trusted review can replace some line-by-line reading. They do not remove the need to prove the result.
Salvatore Sanfilippo gives a positive example. In an Italian commentary, he endorses Gross’s account and applies it to generated software. My English description of the video is a paraphrase, not a quotation. In “Control the ideas, not the code”, he describes automating two DwarfStar inference implementations while he supplied domain knowledge, design, performance goals, correctness checks, QA, and tests.
His point is not “ask for a product and walk away.” Expert attention may be better spent on architecture, product direction, and behavior than on every line. AI can author software without owning it.
Owning the result means you can explain how it works and defend the important choices. You can show enough evidence for the risk, fix failures, and accept responsibility for what happens next.
A local fix can look done while the real system problem remains.
Ronacher’s issue report creates an immediate review cost. Code can send the bill later. An agent might see a malformed session file and add a tolerant reader, fallback, migration, and debug path. Each change looks reasonable. But the real fix may be to stop the system from writing bad session files in the first place.
The local patch looks done, but the root problem remains. A large diff may pass its tests while leaving product decisions and maintenance unresolved. It is not slop because it is large or generated. It becomes slop when it is presented as merge-ready while decisions remain unowned and evidence is missing.
Your Repo Is the Memory shows how to preserve purpose and constraints before generation. Make the Agent Prove It shows how to choose evidence.
Ask about purpose, evidence, ownership, and hidden work.
| Question | Ask |
|---|---|
| Purpose | Who is this for, what should it do, and how finished should it be? |
| Evidence | What shows that this works, and is that enough for the risk? |
| Ownership | Who understands it, can fix it, and owns what happens next? |
| Hidden work | What remains, and did the next person agree to take it? |
Do not turn the questions into a score. A rough draft is not slop just because one answer is weak. The warning sign is the combination: it looks ready, no one has supplied enough purpose, evidence, or ownership, and the unfinished work is hidden.
Whether AI made it is the wrong question. Ask what it is for, what evidence supports it, who owns it, and what work is still hidden.
The definition in this article is my synthesis. The sources below support its parts.