Spot the Slop

Spot the Slop

Slop is decoration without decisions. It passes review because nothing in it is wrong. Go looking for the specific tells.

1. Read the diff cold and mark the tells

Code tells

• Comments restating the line: an increment commented "increment the counter"; a getter with a docstring in a file that has none.
• try/catch wrapped around code that cannot throw. A catch that logs and rethrows unchanged. A catch that swallows silently.
• Null checks on a value constructed three lines above.
• An abstraction with exactly one caller — a formatter used once, a constants file holding one string, a types file holding one type.
• A barrel index re-exporting one module; an options object whose parameters no caller ever passes.
• A second implementation of something the repo already has: another date formatter, another class-name joiner, another fetch wrapper.
• Names describing the code instead of the domain: data, result, item, processItems, handleClick2.
• Types that give up: Record<string, any>, an as any, a props type where every field is optional.
• A new dependency for something five lines would do.
• Tests asserting a mock was called, not that behavior happened.

Design tells, in roughly the order people actually name them — the top of this list is worth more attention than the bottom:

• A component kit shipped untouched: the library's default card, its default radius, its default shadow, its default button, arranged the way its documentation arranges them. This is the most-named tell there is, and it is the hardest to see from inside, because nothing in it looks like a mistake.
• Violet and indigo doing the work of a brand colour, on a product with no reason to be violet.
• Gradients on the hero, the buttons, the headings, and the text.
• More things moving than the screen has reasons for — a reveal on every section, a hover on every card. See Motion Budget.
• A pill radius on everything, applied at one value with no distinction between a button and a container.
• Dark background plus a coloured glow behind whatever is important.
• Emoji standing in for icons.
• The default interface sans left in place — Inter, Geist — on a brand that never chose it.
• A three-column feature grid with icon, heading, two lines of text — regardless of whether there are three real features.
• One spacing value everywhere, so related and unrelated things sit the same distance apart and nothing groups.
• Cards carrying a border and a shadow and a radius and a tinted fill, all at once.
• Everything centred, a pill badge above the headline, a glow behind the screenshot.
• Copy that says seamlessly, effortlessly, unlock, elevate, powerful, blazing fast.
• Stats that are all round and all invented: 10k+, 99.9%, 24/7.
• The same animation duration on every element, with no stagger and no reason.

None of these outranks the complaint that sits above all of them: that the thing is recognisable on sight. A screen can carry no tell from this list and still be the arrangement everyone has seen, in which case the finding is structural and the list will not reach it. Structure Before Style is that pass; this one is for what sits on top.

2. Bucket each mark

Delete, replace with the thing the repo already has, or keep with a one-clause justification. Most marks are deletes.

3. Delete first, then re-read

Apply removals before rewriting anything. A surprising amount of the remaining code reads fine once the noise is gone.

4. Report what was removed

Lines removed, abstractions inlined, dependencies dropped, and the counts from the design pass.

Wrongly accused

Some patterns are named constantly in jokes about AI design and almost never by people describing a real page in front of them. Bento grids, frosted glass, and mesh or aurora backgrounds are all in that group.

They are techniques, and a technique used for a reason is not a tell. Deleting one because of its reputation removes a decision and leaves the defaults underneath untouched — which makes the page more generic, not less. Mark them only when the same question answers them as anything else here: what decided this, and what would have changed it.

Rules

• Do not rewrite the whole thing because it smells. Name tells with locations, or the review is just taste asserted loudly.
• Do not add a comment to explain a bad name. Fix the name.
• Do not keep a single-caller abstraction for a future that has not arrived. Inline it; extracting later is cheap.
• Do not mistake plain for slop. A blunt implementation with real spacing decisions is good work; slop is ornament standing in for judgement.