I like how this repo has 159 files with 11635 LoC, and the load-bearing (!!!) part of it is a couple lines of natural language instructions:
1. *Does this need to exist at all?* Speculative need = skip it, say so in one line. (YAGNI)
2. *Already in this codebase?* A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
3. *Stdlib does it?* Use it.
4. *Native platform feature covers it?* `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
5. *Already-installed dependency solves it?* Use it. Never add a new one for what a few lines can do.
6. *Can it be one line?* One line.
7. *Only then:* the minimum code that works.
- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
- No boilerplate, no scaffolding "for later", later can scaffold for itself.
- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`).
That's essentially all there is.
