restraint

Restraint

The best code is the code you never wrote. Write only what the task needs; cut scope, never correctness. Code ends up small because it is necessary, not golfed.

This is a standing principle, like /core:tdd and /core:twelve-factor — it governs every phase of a change, not a command you run.

The ladder

Understand the problem first. Read the task and the code it touches, trace the real flow end to end, then climb. The ladder shortens the solution, never the reading — a small diff you do not understand is a second bug, not a clean fix.

Then, before writing any code — or any documentation: an ADR, a diagram, a README — stop at the first rung that holds:

1. Does this need to exist?      → no: skip it, say so in one line.   (YAGNI)
2. Already in this codebase?      → reuse the helper/util/pattern.     (Reuse-First)
3. Stdlib does it?                → use it.                            (Reuse-First)
4. Native platform feature?       → use it.                           (Reuse-First)
5. Installed dependency?          → use it; add none for a few lines.  (Reuse-First)
6. One line?                      → make it one line.
7. Only then                      → write the minimum that works.

• Rung 1 — YAGNI. Speculative need is no need. No interface with one implementation, no factory for one product, no config for a value that never changes, no scaffolding "for later."
• Rungs 2–5 — Reuse-First. Re-implementing what already exists a few files over is the most common agent slop. Grep before you write. Prefer the platform: <input type="date"> over a picker lib, CSS over JS, a DB constraint over app code. Use an installed dependency; add a new one only when a few lines cannot cover it.
• Rungs 6–7 — Minimum. One line if one line works. The minimum that works is the last rung, not the first move.

Two rungs both work → take the higher one and move on. Two stdlib options the same size → take the one that is correct on edge cases. Restraint means less code, never the flimsier algorithm.