Coding Discipline

If you can name the failure mode you're about to commit, you usually won't commit it.

Six failure modes most common in LLM-written code, with the counter for each.

The Six Failure Modes

Falsifiable Tests

Silent assumption. Before any non-trivial change, name the load-bearing assumption in one sentence. If you can't, you don't know what you're building. If two readings are reasonable, present both — e.g., "Reading 'cache user lookups' as in-process LRU rather than shared cache — flag if you meant the latter."

Scope creep. A diff answers one question: what did the user ask for? Every other line is contraband. Allowed: orphans your own change created (unused imports, dead branches you rewrote). Not allowed: "while I'm here" reformatting, renaming, dead-code removal, style sweeps — mention them in your reply, don't commit them. Two unrelated chunks → split the diff.

Speculative complexity. Does a second caller exist right now that needs a different value? No → don't add the parameter. The same test kills: "I'll make this configurable", base classes for hypothetical implementations, wrappers for hypothetical callers, and handling structurally impossible errors. If the simplest version is half the size, write that one.

Hallucination. Look it up before writing — prefer serena symbolic tools (find_symbol, get_symbols_overview, find_referencing_symbols) over Read/Grep; context7 for external library docs; grep/Read otherwise. "It should work" ≠ "I ran it and it works". When you couldn't confirm, mark uncertainty: "I think it's obj.foo() but haven't verified."

Drift. Restate the request as one of: a failing test you'll make pass, a specific output you'll produce, a specific observable behavior. For multi-step work: 2–4 steps, each paired with its check. A step is done when its check passes — not before.

Parallel solution. Before writing a new helper, pattern, or solution, ask: does this codebase already solve this problem class?

• Pattern: pagination/validation/auth/error-handling/retries/logging/config — find an existing one and copy its shape.
• Helper: before writing formatDate/chunk/parseId, grep for similar names and inspect existing utils modules.
• Library: before adding a dependency, check package.json / go.mod / pyproject.toml for an existing equivalent.

Parallel solutions double maintenance, split conventions, and confuse future readers about which version is canonical.

Finding the existing solution isn't enough — copy its shape. A tidier variant of a pattern the repo uses everywhere is still a parallel solution: the repo now has two ways to do one job, and yours is the outlier. Match the existing verbosity even when a wrapper would be cleaner. If the tidier version is genuinely better, propose it as its own change — never smuggle it in as a side effect.

Pre-Commit Self-Check

1. Assumption — stated, or "n/a"?
2. Scope — every changed line traces to the request?
3. Simplicity — could a senior cut this in half?
4. Verification — confirmed referenced symbols/APIs exist? Ran the code, not just wrote it?
5. Goal — can you name the check that proves this is done?
6. Reuse — checked the codebase for an existing solution (helpers, patterns, libraries), and matched its shape rather than improving it?

A "no" on any line: stop and revise; don't ship and explain.

Red Flags

For trivial tasks (typo fix, one-line rename), use judgment — this skill biases toward caution.