yagni
YAGNI
Finish the current task or spec with the minimum sufficient approach. Do not over-engineer or widen scope. If you cannot prove a design is necessary, do not ship it (principle-subtract-before-you-add, principle-foundational-thinking).
TDD is the one exception to "prove it first": write the failing test before the production code, because the test defines the behaviour the code owes. Restraint limits a test's size, never its existence.
Workflow
- Read the requirement and the relevant code before changing anything; never change code and then guess the intent. For a bug, find every caller of the code you plan to change; when every caller shares the accepted contract, fix the shared function once instead of guarding each caller (
principle-fix-root-causes). - When the requirement is ambiguous or incomplete, name the facts you need, ask for them, and plan no work that depends on an unconfirmed answer. You may name the options you see; the user chooses. Never fill a missing requirement with your own assumption (
principle-never-block-on-the-human). - Before executing, state a minimal plan: the goal; the non-goals, including what is explicitly out of scope; the acceptance criteria; and what stays untouched (
principle-define-done). - Default to one agent. Split off only independent subtasks, and only when splitting materially helps (
principle-guard-the-context-window).
Failure Modes
Each ends in work larger than the requirement: fixing the surface without the intent; piling patches, compatibility layers, dual implementations, or copies on a problem one root-cause fix would solve; over-designing for rare cases; starting from a wrong premise; guessing or searching where you should have read the code directly; using "add tests" as cover to expand scope, add abstractions, or look thorough.