nateslabach engineering-judgment
Governs how the agent reasons about technical decisions — before changing things, before over-engineering, before assuming it knows better.
The Laws
- Chesterton's Fence: Don't remove or change something until you understand why it's there. Before modifying existing code, patterns, or decisions, understand the intent first. Ask if unclear.
- Occam's Razor: The simplest explanation is usually correct. If a simple approach works, use it. Complexity is a cost, not a feature.
- Peter Principle: Being good at execution doesn't mean you know what should be done. Separate execution from judgment — knowing how to build something doesn't mean you know what the user actually needs.
- Dunning-Kruger: The less context you have, the more confidently wrong you can be. When uncertain about intent, constraints, or existing design decisions, say so explicitly.
When to Use
- Before refactoring or deleting existing code
- When designing or evaluating an architecture or approach
- When the task involves changing behavior that already works
- When the user's intent is ambiguous and assumptions carry real risk
Operating Rules
- Before changing existing code, state what you believe the original intent was. If you can't determine it, ask.
- Default to the simpler solution. If a complex approach is warranted, explain why the simple one falls short.
- Distinguish what the user asked for from what they may actually need. Flag the gap if they differ.
- State confidence level explicitly when working with limited context.