How not to ship slop
AI is useful, but it will happily help you ship average work with a finished-looking surface — here is how to keep it from setting your bar.

AI slop is easy to recognize after the fact. It is the landing page with a purple-blue gradient, Inter, three rounded feature cards, and a headline that could belong to any SaaS company. It is the blog post full of "pivotal", "crucial", "delve", and "underscores". It is the generated image with the wrong hands or the wrong physics. The problem is not always that it looks broken. More often, the problem is that it looks done before anyone has thought hard about it.
This is not a post about refusing AI. I use it a lot. It is a post about not letting it set the bar.
Slop is average with polish
At RevenueCat, we once posted a real job opening for an agentic developer advocate: an AI agent that could produce developer-facing material. The salary was real. Close to a hundred agents applied.
The assignment had three parts:
- build a small demo with one of our APIs
- write a technical article explaining the API and the demo
- make a short YouTube-style video showing how the project worked
Some demos were impressive. Some articles were readable. Some videos were coherent. No agent did all three at a level I would have wanted to publish.
That was the interesting part. The failure mode was not brokenness. It was competence without edge. The work was plausible, polished, and average.
That is the useful definition of slop: average output that looks more finished than it is. In hiring, a weak "yes" is usually not enough. You want the kind of candidate someone would fight to hire. AI output needs the same gate.
If you would not fight for it, do not ship it.
What slop actually is
In "Why Slop Matters", Cody Kommers et al. describe AI slop through three traits:
- superficial competence: it looks good before it holds up
- asymmetric effort: it took much less work to make than the reader expects
- mass producibility: it can be generated and spread at scale
For client work, product work, and developer education, the first two are the dangerous ones. A generated deck does not need to go viral to damage trust. It only needs one confident falsehood.
Once a customer catches it, "the AI hallucinated" is not a defense. It is an admission that no one owned the artifact.
What the model will not give you
A model can help you draft, explore, summarize, refactor, scaffold, and vary. It will not give you the things that decide whether the work deserves to ship.
Context
After training, the strongest lever you have is context. A model cannot know your customer, roadmap, constraints, tradeoffs, brand rules, or the hidden reason a simple answer is wrong for your situation unless you provide it.
Weak prompt:
Write a launch post about our new API.
Better prompt:
Write a launch post for mobile developers who already use RevenueCat but have not tried this API. The point is not "new feature exists". The point is: this removes a manual step in revenue analysis. Use a direct technical tone. Assume the reader is busy. Include one concrete before/after example. Do not include hype language.
The second prompt is not magic. It is just context. But context pulls the output away from the average.
Taste
Context makes output more accurate. Taste makes it worth reading.
The model can give you twenty headlines. It cannot reliably know which one is sharp, which one is bland, and which one sounds like every SaaS launch from the last ten years. It has read everything and prefers nothing.
Taste is pattern recognition. You build it by looking at good work, comparing it to worse work, and getting told when your own work is average. It usually shows up as subtraction. The model adds. It pads. It explains the introduction before making the point. Taste is knowing what to cut.
When AI hands you options, do not treat selection as admin work. Selection is the work.
Ownership
Speed is not quality. A draft that was easy to make still needs someone to stand behind it.
Ownership is reading every line. It is checking every number, API name, quote, and claim. It is running the code and reading the diff. It is making sure every slide in a deck can survive a customer asking, "Where did this come from?"
The test is simple: would you defend it in a room full of people who know the topic?
If the answer is no, the work is not done.
Stop prompting like a client
Consultants hear vague requests all the time:
- "Can you make it more white?"
- "The app is broken."
- "Can you make the design pop more?"
That is also how people talk to AI.
"Make it cleaner" is not direction. "Make it more professional" is not direction. "Make it pop" is a confession that you have not decided what good means.
Your job is to turn vague intent into usable constraints. Do that before the model does the work.
Instead of saying "make this article better", say:
Remove inflated language. Keep the direct tone. Cut repeated points. Preserve the RevenueCat hiring anecdote. Shorten the personal intro. Replace talk-stage notes with prose. Do not add a generic conclusion.
The model is not a mind reader. Treat it like a fast junior with no taste and no context until you provide both.
Show it what good looks like
Adjectives are slop fuel. "Professional", "modern", "clean", and "engaging" all point toward the middle of the distribution.
Use examples instead.
For writing, keep a small swipe file: two or three pieces in your voice, a style guide, and a list of phrases you never want to publish. Ask the model to match the examples, not the adjectives.
For visual work, give references and dimensions:
- typography: what kind of type, and what to avoid
- color: which role each color plays
- layout: what structure fits the content
- imagery: what is real, what is banned
- motion: what should move, when, and why
"Modern landing page" gets you the default. "Dense technical product page inspired by API docs and terminal UIs; one display typeface; no purple gradients; no three-card feature grid; use real product screenshots" gets you something you can evaluate.
Reference, do not adjective.
Cut the AI tells
Wikipedia editors maintain a long "Signs of AI writing" page. It is written for Wikipedia, not personal blogs, and it correctly warns that these signs are clues rather than proof. Still, the patterns are useful when editing AI-assisted work.
The common tells are easy to spot once you know them.
First: inflated significance. Everything becomes "pivotal", "crucial", "a testament to", "a key turning point", or "part of a broader landscape". This makes small facts sound like state ceremonies.
Bad:
The Statistical Institute of Catalonia was officially established in 1989, marking a pivotal moment in the evolution of regional statistics in Spain.
Better:
The Statistical Institute of Catalonia was established in 1989 to collect regional statistics independently from Spain's national office.
Second: vocabulary fingerprints. Words like "delve", "tapestry", "intricate", "underscores", "showcases", and "notably" are not banned. But when they cluster, the text you're reading starts to smell generated.
Third: structure tells. Too much bold text. Title Case Headings Everywhere. Inline headers followed by list blocks. Three-part lists used even when the material does not need three parts. Em dashes every few lines. Curly quotes in otherwise plain Markdown.
Fourth: avoidance patterns. AI often dodges plain verbs. Instead of saying "X is Y", it writes around the sentence. It also loves "not just X, but Y", "X rather than Y", and repeated synonym cycling because it is trying to sound varied instead of precise.
Fifth: hollow endings. "As technology continues to evolve..." is not a conclusion. It is fog. End on the point you actually believe.
Do one pass just for these tells. Search for the vocabulary. Delete half the setup. Replace grand claims with concrete ones. Read it out loud. If you would not say it to a colleague, rewrite it.
But do not stop there. Removing AI tells can leave you with clean, dead prose. After the cut, add the human part back: a real opinion, a concrete example, a sharper verb, a sentence that sounds like someone had to choose.
Do not accept the default look
The same average shows up in AI-generated UI.
Ask for a SaaS landing page and you will usually get Inter, a purple-blue gradient, a vague hero line, three feature cards, rounded rectangles, floating blobs, and decorative motion that does not explain state. Nothing is broken. That is the problem. It looks like the average of the internet.
The fix is not "make it more creative". The fix is to specify the design decisions the model will otherwise default.
Pick typography with a reason. Use color semantically, not as decoration. Use real product screenshots or real people instead of stock photos and 3D blobs. Use motion to guide attention or explain state. Put the system into tokens and components so the next generated page starts from your taste, not from the model's default.
The final UI test is the lineup. Put your screen next to three competitors. If a stranger cannot tell which one is yours, you shipped the default.
Verify before you publish
The last pass is boring. That is why it matters.
Check every number, name, source, quote, API method, package, and screenshot. Run generated code. Read the diff. Click the UI. Make sure the article links point where they claim to point. Make sure the claims you inherited from the model are still claims you are willing to own.
For customer-facing work, double the standard. A private prototype can be messy. A public artifact teaches people what your bar is.
A useful checklist before publishing:
- Can I defend every claim?
- Did I verify the facts that matter?
- Does this sound like me or like the median internet?
- Did I remove the parts that only make the piece look finished?
- Would I fight for this?
If the answer to the last one is no, keep editing.
Do not ship average
The problem with AI output is rarely that it is obviously bad. Obvious bad is easy to catch. The dangerous output is plausible, smooth, and close enough that people stop thinking.
That is slop: average with polish.
The antidote is not to use less AI. It is to do the work the model cannot do. Add the context. Apply taste. Take ownership. Cut the generic parts. Put back the part that sounds like a person with a point of view.
The tools are becoming common. That makes the human work more important, not less.
Before you publish the thing AI helped you make, ask one question:
Would you fight for it?
If not, you already know what it is.
Further reading
- "Why Slop Matters", Cody Kommers et al.
- "Signs of AI writing", Wikipedia
- "Your writing sounds like ChatGPT. Here's what's giving you away", Alex Banks
- "Prompting for frontend aesthetics", Anthropic Claude Cookbook
- "AI Slop Web Design", 925studios