/anti-patterns

name: anti-patterns
description: Catalogue of known SDLC anti-patterns that great_cto agents must actively reject when reviewing architecture, plans, code, or post-mortems. Used by architect (pre-impl), pm (planning), senior-dev (impl), l3-support (post-incident).
when_to_use: |
  Apply when:
  - architect is writing ARCH/ADR and might be tempted by a known bad pattern
  - pm is decomposing tasks and the breakdown smells like a known failure mode
  - senior-dev is implementing and considers a "quick fix" that is anti-pattern
  - l3-support is doing root-cause and finds an anti-pattern as the cause
  - any agent reviewing third-party code that exhibits anti-patterns
effort: low
allowed-tools: Read, Grep, Glob
paths:
  - "docs/**"
  - "src/**"
  - "lib/**"

SDLC anti-patterns to reject

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 <new framework>." **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 ba