Anti-AI-Slop: My prompt strategy for Claude Code and Cursor

Generic AI code often feels like "slop"—it's overly verbose, uses predictable naming conventions, and adds unnecessary boilerplate that makes a codebase feel bloated. I've been implementing a "Hallmark" design skill (essentially a strict set of stylistic constraints) to force Claude Code and Cursor to write lean, professional-grade code that doesn't look like it came from a LLM.

The goal is to stop the AI from being "too helpful" (which usually means too wordy) and make it adhere to a specific, high-density engineering style.

Here is the prompt logic I've integrated into my .cursorrules and Claude Code system prompts to kill the slop:

# Anti-AI-Slop Design Constraints
- **No fluff:** Eliminate redundant comments that explain *what* the code does (e.g., avoid `// Initialize variable x`). Only comment on *why* a non-obvious decision was made.
- **Dense Logic:** Favor concise, idiomatic patterns over expanded, "beginner-friendly" structures. 
- **Naming:** Use precise, domain-specific terminology. Avoid generic names like `data`, `info`, or `result` unless they are truly generic.
- **No Over-Engineering:** Do not suggest adding "future-proof" abstractions unless specifically asked. Write the simplest code that solves the current requirement.
- **Dryness:** If a pattern repeats twice, abstract it; if it repeats three times, create a utility. Never more, never less.

Applying this to a real-world AI workflow has significantly reduced my refactoring time. Instead of spending 10 minutes stripping out "AI-isms" and redundant try-catch blocks that don't actually handle errors, the output is closer to something a senior dev would actually commit.

If you're doing a deep dive into prompt engineering for your IDE, try adding these constraints to your project-level config. It shifts the LLM from "tutorial mode" to "production mode."