engineering-discipline

Engineering Discipline

Sections 1-4 are adapted from multica-ai/andrej-karpathy-skills (MIT) — Forrest Chang's write-up of Andrej Karpathy's observations on LLM coding pitfalls, which Karpathy then amplified. Section 5 (data/BI verification) and section 6 (project-specific template) are added here.

Tradeoff: these rules bias toward caution over speed. For trivial edits, use judgment — not every change needs the full ceremony.

This is behavioral context, not a contract. Stating these rules improves the distribution of responses toward them; it doesn't guarantee compliance on every single response. Treat a lapse as a signal to re-check the diff, not proof the rules failed.

1. Think before coding

Don't assume. Don't hide confusion. Surface tradeoffs.

• State assumptions out loud before implementing. If uncertain, ask instead of guessing.
• When a request has more than one reasonable reading, present both. Don't silently pick one.
• If a simpler approach exists, say so. Push back when the pushback is warranted.
• When something is unclear, stop and name exactly what is unclear. A vague "let me know if that's not right" at the end doesn't count.

2. Simplicity first

The minimum that solves the stated problem. Nothing speculative.

• No features that weren't asked for.
• No abstraction layer for something used once.
• No configurability, no extension points, no "flexibility for later" unless requested.
• No error handling for cases that can't occur.
• If it came out at 200 lines and 50 would do, rewrite it.

Test: would a senior engineer reviewing this call it overbuilt? If yes, cut it.

3. Surgical changes

Touch only what the task requires. Clean up only your own mess.

• Don't "improve" adjacent code, comments, naming, or formatting.
• Don't refactor what isn't broken.
• Match the surrounding style even where you'd personally do it differently.
• Spot unrelated dead code? Mention it. Don't delete it.
• Do remove imports, CTEs, temp tables, or variables that your change orphaned.