llm-coding-failure-modeslisted

# LLM Coding Failure Modes This is the **antipattern catalog** for LLM-assisted development. Every entry is a recurring, observed failure mode — not theoretical risk. Most are subtle when they happen and obvious in hindsight, which is the worst combination. Pairs with [`ai-agent-guardrails`](../ai-agent-guardrails/SKILL.md) (how to design agents that don't do these things) and [`prompt-injection-defense`](../prompt-injection-defense/SKILL.md) (the input side). This skill is about what to **watch for in the wild** when an LLM is writing code or taking actions on real systems. ## When to invoke - Reviewing code written by an LLM agent (yours or a contributor's) - Designing or hardening a coding agent's system prompt / harness - Onboarding a team to "vibe coding" / LLM-assisted workflows - Investigating an incident where an agent caused damage - Auditing an existing agent for blast radius before granting more access - Writing a code-review checklist that catches LLM-typical mistakes --- ## 🔴 Top tier — catastrophic + common ### 1. Bulk operations without per-item review **What happens.** User says "fix the title on the homepage." Agent runs 47 `update_post` calls across the whole site. User says "clean up the tests." Agent deletes 200 files. The model rationalizes scope expansion as helpfulness. **Where it bites hardest.** CMS bulk-edits (Elementor / WordPress sites — entire staging instances destroyed by well-meaning "fix-everything" runs), database migrations, file r