Reference catalogue. Cite the anti-pattern by name when blocking a proposal — gives the user a clear vocabulary to discuss the issue.
Architecture anti-patterns
A-1. God service
Smell: One service does auth, billing, search, file storage, and email. Why bad: Single deploy unit, single point of failure, every team touches it, change velocity drops over time. Fix: Split by business capability (DDD bounded context).
A-2. Distributed monolith
Smell: 12 microservices but they share a database and deploy together. Why bad: All cost of distributed (latency, eventual consistency, ops overhead) with none of the benefits (independent deploy, isolation). Fix: Either truly separate (own DB, own deploy pipeline) or merge.
A-3. Synchronous chains
Smell: Request → Service A → Service B → Service C → Service D. Why bad: Compound failure probability, p99 latency adds up. Fix: Async with events, or co-locate hot path.
A-4. Premature optimization
Smell: Custom Redis Lua scripts, hand-tuned binary protocols, before the first paying user. Why bad: Complexity cost paid up front, never recouped. Fix: Start simple. Optimize when you have load data.
A-5. Resume-driven development
Smell: "Let's use Kubernetes / GraphQL / event sourcing / DDD" with no current pain it solves. Why bad: Optimizes for engineer's resume, not user's outcome. Fix: Ask "what's the simplest thing that could work?"
Plan / process anti-patterns
P-1. Big-bang rewrite
Smell: "Let's rewrite this in ." Why bad: 80% of rewrites fail. The old system has years of bug fixes baked in. Fix: Strangler-fig. New behaviour in new code, old code coexists, delete when traffic moves.
P-2. Hero culture
Smell: "Senior X always fixes the 3am incidents." Why bad: Bus factor 1. X burns out. Knowledge doesn't transfer. Fix: Runbooks, post-mortems, rotating on-call, pair-debugging.
P-3. No reversibility plan
Smell: Plan ships a one-way door (data migration, public API change, breaking-contract release). Why bad: If wrong, recovery is days or weeks. Fix: Mandate dry-run + rollback path before approval.
P-4. Plan without timeboxes
Smell: Tasks named "implement feature X" with no end criteria. Why bad: Open scope, time inflates to fit. Fix: Each task ≤ 4 hours, with explicit "done = X" criteria.
Code-level anti-patterns
C-1. God class / God function
Smell: A class > 500 lines or function > 100 lines doing 5 unrelated things. Why bad: Tests become integration tests. Diff readability collapses. Fix: Single responsibility. Extract collaborators.
C-2. Stringly typed
Smell: Status passed as strings ("open", "closed", "blocked") with no enum. Why bad: Typos compile. New status forgotten in switch. Fix: Enum / discriminated union / branded type.
C-3. Catch-and-continue
Smell:
try { doThing(); } catch (e) { console.log(e); }
Why bad: Hides bugs. Silent corruption. Fix: Catch only what you can handle; re-throw the rest; log with context.
C-4. Hardcoded secrets
Smell: API keys, passwords, DB URLs in source.
Why bad: Leaks in git history forever; rotation requires force-push (impossible).
Fix: Env vars or secret manager. Pre-commit hook to grep for sk-, ghp_, etc.
UI anti-patterns
Taken from Google AI Studio's guide to polishing generated interfaces (2026-09-16): the fastest way to spot one is decoration that means nothing.
U-1. Chips that mean nothing
Smell: Status pills, badges, counters and tags that no state drives — "New", "Beta", "AI", "3 insights" on a screen where nothing is new, beta, or counted. Why bad: The reader cannot tell signal from ornament, so a real warning in the same visual language is ignored. It is the most reliable tell of a generated UI. Fix: Each chip names its meaning and the state behind it, or it is removed.
U-2. Placeholder imagery
Smell: Grey boxes, lorem photos, broken or hotlinked stock image URLs in a build that is meant to be shown. Why bad: The first impression is of an unfinished product; hotlinked assets break or change without notice and may not be licensed. Fix: Every image has a named source — generated for this product, owned, or licensed — and is served from the product's own assets.
Incident / ops anti-patterns
O-1. No SLO
Smell: "Production seems slow today" but no SLO target. Why bad: Can't tell breach from normal. Fix: Set p99 latency, error rate, availability SLOs. Track burn.
O-2. Alert spam
Smell: Every error pages. Engineers stop reading alerts. Why bad: Real incidents get missed in noise. Fix: Page only on user-visible failure. Other signals to dashboard, not pager.
O-3. Post-mortem blame
Smell: "Engineer X deployed without testing." Why bad: Suppresses future post-mortems. Blame doesn't fix the system. Fix: Blameless post-mortems. Focus on missing guardrails, not the human.
O-4. Snowflake servers
Smell: "Don't reboot SRV-PROD-3, it has special config that's not in IaC." Why bad: Disaster recovery impossible. Fix: Everything in IaC. Servers are cattle, not pets.
How to use this catalogue
When you find one of these in a proposal/review:
- Cite the code (A-3, P-1, etc.) so the user has a vocabulary
- Quote the specific smell from the proposal
- Propose the specific fix
- If the user disagrees, capture as ADR with the alternatives section filled in
When NOT to apply
- Hobby projects, learning exercises — anti-patterns are about scale
- Throwaway code with explicit
// TODO delete in 2 weeks - Time-boxed POCs where the goal is "does the API actually work"