🎓
Session 5•
4 min read

Killing the AI Slop

Session 5: Killing the AI Slop

Duration: 2 hours
Prerequisites: Sessions 1-4 completed, tokens and patterns documented
You'll need: Leigher project with CLAUDE.md, agent_docs/, design-tokens.md


Part 1: Recognizing Slop (20 min)

What Is Slop?

AI slop is output that's technically correct but generically forgettable. It follows basic rules but lacks character. It could belong to any project.

You know it when you see it:

  • Flat gray backgrounds (#F5F5F5 everywhere)
  • Single-layer drop shadows
  • Default border radius (4px on everything)
  • Safe, boring color choices
  • No personality

Why Slop Happens

Claude defaults to safe, generic patterns because:

  • They work everywhere
  • They don't offend anyone
  • They're statistically common in training data

Your system has opinions. Claude's defaults don't. The gap between them is slop.

Your System's Distinctive Characteristics

You already know what makes your system different. Think about:

  • Color temperature: Warm or cool? Saturated or muted?
  • Shadow style: Flat? Layered? Diffuse? Sharp?
  • Border radius: Tight? Generous? Mixed?
  • Spacing rhythm: Tight and dense? Open and airy?
  • Personality: Playful? Professional? Technical? Friendly?

These aren't in your token file—they're in your head. Session 5 is about getting them out.


Part 2: Where Anti-Slop Rules Live (10 min)

In code-conventions.md

Remember Progressive Disclosure from Session 3? Anti-slop rules go in agent_docs/code-conventions.md—not in CLAUDE.md.

Why? These rules are task-specific (they apply to visual work, not all tasks). CLAUDE.md stays short; detailed rules live in agent_docs/.

Adding an Anti-Slop Section

Open agent_docs/code-conventions.md and add a new section after the DO/DON'T rules:

---

## Anti-Slop Directives

Visual rules that prevent generic output.

Part 3: Writing Anti-Slop Directives (50 min)

The Format

Anti-slop directives are explicit "never/always" rules with explanations.

### Shadows (Critical)
- NEVER: `box-shadow: 0 2px 4px rgba(0,0,0,0.1)` (flat, single-layer)
- ALWAYS: Compound shadows with 2-3 layers
- EXAMPLE: `0 1px 2px rgba(0,0,0,0.04), 0 1px 4px rgba(0,0,0,0.04), 0 2px 8px rgba(0,0,0,0.03)`
- WHY: Single shadows look flat. Compound shadows create natural depth.

Finding Your Rules

Go through recent designs or components you've refined. Ask yourself:

What did I change from the default?

  • "I always add a second shadow layer"
  • "I always warm up the grays"
  • "I always soften the accent colors for backgrounds"

What makes me cringe when I see it?

  • "Flat shadows look cheap"
  • "Cool grays feel clinical"
  • "Sharp corners feel dated"

What do I consistently reject in reviews?

  • "Too much contrast"
  • "Spacing too tight"
  • "Colors too saturated"

Leigher's Anti-Slop Rules

Here's what to add to Leigher's agent_docs/code-conventions.md:

---

## Anti-Slop Directives

Visual rules that prevent generic AI output.

### Shadows (Critical)
- NEVER: Single-layer shadows like `0 2px 4px rgba(0,0,0,0.1)`
- ALWAYS: Compound shadows with multiple layers
- EXAMPLE: `0 1px 2px rgba(0,0,0,0.04), 0 1px 4px rgba(0,0,0,0.04), 0 2px 8px rgba(0,0,0,0.03)`
- WHY: Single shadows look flat. Compound shadows create natural depth.

### Backgrounds (Critical)
- NEVER: Cool grays (#F5F5F5, #FAFAFA, #EEEEEE)
- ALWAYS: Warm off-whites (--bg-primary: #FAF9F7)
- WHY: Cool grays feel clinical. Warm backgrounds feel inviting.

### Text Colors
- NEVER: Pure black (#000000)
- ALWAYS: Softened black (--text-primary: #1A1A1A)
- WHY: Pure black is harsh on warm backgrounds.

### Accent Usage
- NEVER: Full-saturation accents for large areas
- ALWAYS: Soft variants for backgrounds
- WHY: Saturated backgrounds overwhelm content.

### Border Radius
- NEVER: Same radius on everything (4px default)
- ALWAYS: Use the scale (10px, 14px, 20px, 24px)
- WHY: Varied radius creates visual rhythm.

### Spacing
- NEVER: Arbitrary values (13px, 17px, 22px)
- ALWAYS: Values from the 4px grid
- WHY: Consistent spacing creates visual harmony.

### Hover States
- NEVER: No hover feedback on interactive elements
- ALWAYS: Visible but subtle hover change
- WHY: Hover states communicate interactivity.

### Form Inputs
- NEVER: Browser default styling
- ALWAYS: Custom styling with border, focus ring
- WHY: Default inputs break visual consistency.

The "WHY" Is Important

Including "WHY" helps Claude understand your reasoning. When it encounters edge cases, it can extrapolate from your principles rather than guessing.


Part 4: Before/After Comparison (30 min)

The Test

Let's see the difference anti-slop rules make.

Exercise: Generate Without Rules

  1. Temporarily comment out the Anti-Slop section in code-conventions.md
  2. Ask Claude:
Create a settings panel component with:
- A header with title and close button
- Three toggle settings with labels and descriptions
- A save button at the bottom
  1. Screenshot the result.

What to look for:

  • What color is the background?
  • What do the shadows look like?
  • What's the border radius?
  • How does the hover state look (if any)?

Exercise: Generate With Rules

  1. Uncomment the Anti-Slop section
  2. Ask Claude the exact same prompt
  3. Compare to the previous result

Expected differences:

  • Warmer background colors
  • Compound shadows with depth
  • Intentional border radius choices
  • Visible hover states

Document the Gap

What specifically changed? The gap between "without rules" and "with rules" shows you what your anti-slop directives are actually doing.

If there's no visible difference, your rules aren't specific enough.


Part 5: Refining Your Rules (10 min)

What Did Claude Still Get Wrong?

Even with rules, Claude might miss things. Look at your "with rules" output:

  • Any flat shadows that slipped through?
  • Any cool grays hiding in secondary elements?
  • Any default border radius on small elements?

Make Rules More Specific

Too vague: "Use good shadows"

Better: "Always use compound shadows with at least 2 layers"

Best: Provide the exact CSS value as an EXAMPLE

When to Stop

You're done when:

  • Claude's output looks like it belongs in your system
  • You're making visual refinements, not fixing fundamentals
  • A non-designer couldn't tell AI made it

Session 5 Checklist

  • [ ] Identified your system's distinctive characteristics
  • [ ] Added Anti-Slop Directives section to agent_docs/code-conventions.md
  • [ ] Written NEVER/ALWAYS/EXAMPLE/WHY for shadows
  • [ ] Written rules for backgrounds, text colors, accents
  • [ ] Written rules for border radius, spacing, hover states
  • [ ] Generated component WITHOUT rules (baseline)
  • [ ] Generated component WITH rules (improved)
  • [ ] Documented the visible difference
  • [ ] Refined rules based on what Claude still missed

What's Next

Session 6: The Art of Iteration

You've set up Claude to generate good output. But first output is never final. Session 6 teaches you how to iterate—when to refine via prompts (fast) and when to go back to Figma (exploratory).


Session 5 of 10 • The Shipping AI Designer Course
Next: Session 6 — The Art of Iteration

Discussion

Loading comments...