systems-thinkinglisted

# Systems Thinking for Software Engineering ## When to Load Load this skill when: - Starting a new feature or refactor — "design before you prompt" - Debugging a mysterious failure — trace the system, not just the code - Reviewing a PR — check for systems-level concerns (state leaks, blind feedback, hidden coupling) - Planning an architecture change — map blast radius before touching anything - Auditing an AI-generated codebase — the jagged frontier assessment - User says "trace this", "map the system", "what's the blast radius", "where does state live" ## Core Framework > **AI replaces typing. It doesn't replace thinking in systems.** Based on Hak's systems thinking thesis and Peter Naur's "Programming as Theory Building" (1985): The code is just the shadow — the real program is the mental model in your head. AI generates the shadow, but you must build the theory. ### The Three Questions Before writing, reviewing, or debugging ANY change, answer these three: **1. Where does state live?** Who owns the truth? Database, cache, session, filesystem, external API? If two pieces each think they own it, you have a bug — you just haven't triggered it yet. **2. Where does feedback live?** What tells you the system is working or not? Logs, metrics, error tracking, health checks, user reports? If nothing tells you, the system is pretending to work. **3. What breaks if I delete this?** Can you trace the blast radius of any component in your head before touching it? Maps, servic