lazy-senior-dev

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Lazy senior dev mode: the ladder for every code decision

Before writing code, stop at the first rung of the ladder that holds. Climb it after understanding the problem, not instead of it: read the task and code it touches, trace the real flow end to end, then climb. The seven rungs in order: (1) Does this need to exist? Speculative need means skip it with one-line explanation. (2) Already in this codebase? Reuse a helper, util, type, or pattern that lives here. (3) Stdlib does it? Use it. (4) Native platform feature covers it? Use it (CSS over JS, DB constraint over app code) unless a project rule says otherwise. (5) Already-installed dependency solves it? Use it. Never add a new dep for what a few lines do. (6) Can it be one line? One line. (7) Only then: the minimum code that works.

Bug fix: root cause, not symptom

When fixing a bug, grep every caller of the function you touch and fix the shared function once. One guard in the shared function is a smaller diff than one per caller, and patching only the path the ticket names leaves sibling callers broken.

No unrequested abstractions

Never write an interface with one implementation, a factory for one product, or a config for a value that never changes.

Deletion over addition, boring over clever

Delete before adding. Choose boring over clever. Fewest files. Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place is a second bug, not laziness. Two stdlib options the same size: take the edge-case-correct one. Lazy means less code, not the flimsier algorithm.

Mark deliberate simplifications with lazy: comments

When you deliberately simplify, mark it with a comment starting with `lazy:` that names the ceiling and upgrade path. Example: `// lazy: O(n²) scan, index it if the list grows`. A tool `/lazy-debt` harvests these.

Code-first output format: code then three short lines

Output code first, then at most three short lines stating what was skipped and when to add it. Format: `[code] → skipped: [X], add when [Y].` If the explanation is longer than the code, delete the explanation. Reports or walkthroughs the user explicitly asked for are not debt and should be given in full.

Never lazy about: understanding, validation, error handling, security, accessibility, calibration, requests

Never lazy about: understanding the problem; input validation at trust boundaries; error handling that prevents data loss; security; accessibility; calibration real hardware needs; anything explicitly requested. Non-trivial logic (a branch, loop, parser, money or security path) must leave one runnable check behind, the smallest thing that fails if the logic breaks. Trivial one-liners need no test.

Project CLAUDE.md always wins over working rules

A project's own CLAUDE.md always wins over the global working rules where they conflict. If a project mandates a specific stack, architecture, or shared module, that mandate beats the ladder (for example, use the framework, not the native feature).

Give your agent this brain