right-size

Right-sizing a coding task

This is the lazy-loaded detail behind the one always-on sentence ("Match the solution to the requirement, no smaller, no larger"). Pull it in when a task is actually a coding task; otherwise it costs tokens for nothing.

Step 1, climb the decision ladder

Stop at the first rung that holds:

1. Delete the requirement. Can this not be built? (YAGNI) Half of "right-sizing" is removing work, not shrinking it.
2. Standard library. Does stdlib already do it? Use it.
3. Platform feature. Native runtime/framework capability? Use it.
4. Installed dependency. Already in the project's deps? Use it. Don't add a new dep to save a few lines; do reach for one to remove real maintenance.
5. One readable line. Can it be one line that needs no comment to decode?
6. Minimum working code. Otherwise, the least code that fully meets the requirement, including the parts below.

Step 2, run the under-engineering checks

Minimalism's blind spot. Before "done", confirm you didn't cut a corner that's actually part of the requirement:

Check	Ask	If it applies and you skipped it
Inputs	Empty / malformed / out-of-range handled at trust boundaries?	Add validation or mark occam:
Scale	Stays correct as input grows? (unbounded loops, pagination, memory)	Bound it or mark occam:
Failure	I/O, network, external calls fail without data loss?	Handle it, never occam: data loss
Concurrency	Shared state two callers can corrupt?	Guard it or mark occam:
Unstated	What did the user obviously mean but not say?	Build that too

Step 3, never shortcut these

These are part of the requirement, not extras. Efficiency is never the excuse: input validation at trust boundaries, error handling that prevents data loss, security (authz / secrets / injection / SSRF), accessibility, and anything the user explicitly asked for.

Step 4, mark intentional simplifications

// occam: <what's simplified>, fine until <ceiling>; <upgrade path> when it isn't

State the ceiling (when it breaks) and the upgrade path. /occam-debt harvests these so a deliberate shortcut stays visible instead of becoming a silent bug.

Two failure modes, equally wrong

• Over-engineering, a framework for a 10-line problem, premature config, abstractions nobody asked for. Climb the ladder; most of this disappears.
• Under-engineering, the clever one-liner no one can maintain, the dropped edge case, the missing retry. The Step 2 checks catch this.

Right-sizing is hitting neither. When two solutions tie on size, pick the more readable and less fragile one.