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 ne

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.