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.A genuinely simple codebase is table stakes for a project like this.
---
That's enough Claude speak for one day
This scales about as well as it sounds like it would.
Multi-model review does a decent job identifying things they’re outright wrong. The resulting code still doesn’t feel elegant writ large.
If you want good output, it seems that iterating on the output is inferior to providing better input inclusive of code examples. And by the time you’ve made all the decisions that go into that, something like ponytail is superfluous.
(All that said, I have ponytail installed in most harnesses.)
Not only the GitHub stars are clearly manipulated with bots and fake accounts, this whole "skills.md" paradigm is close to being a pseudoscientific exercise in attempting to steer LLMs but throwing huge markdown files at it and expecting the desired result to happen won't work in the long run.
I guess it does happen to everyone cause most (not all) seniors I know have had long hair at some point
taurath•59m ago
Optimizing for fewest LOC is probably slightly more bad than more LOC, and both are bad for the same reason - it makes it harder for humans to interpret and understand wtf terrible decisions and tradeoffs the LLM made
bitexploder•53m ago
AdieuToLogic•50m ago
Concision begets perplexity.
;-)