Most LLM-assisted code changes fail for the same reasons: the model silently assumes details, overengineers, touches unrelated code, and lacks verifiable success criteria. These guidelines translate Andrej Karpathy’s observations into four actionable rules that make LLM-driven coding safer and more predictable.
What Sets It Apart
- Think Before Coding: forces explicit assumptions, multiple interpretations, and clarifying questions so the model stops guessing. This reduces bugs caused by hidden, incorrect defaults.
- Simplicity First: mandates the smallest implementation that meets requirements — prevents bloated abstractions and unnecessary flexibility that LLMs commonly introduce.
- Surgical Changes: restricts edits to lines required by the request and preserves surrounding code and style; if unrelated dead code is spotted, the guideline recommends mentioning it rather than deleting it.
- Goal-Driven Execution: reframes tasks as verifiable goals (write tests first, define pass criteria) so the LLM can loop until measurable success, reducing vague “make it work” outcomes.
Who It's For and Tradeoffs
Great fit if you run LLM-assisted code workflows (especially Claude/Claude Code users), maintain code quality in PRs that include LLM changes, or build tooling that automates code edits. It’s lightweight and easy to drop into a repo as CLAUDE.md or expose as a Claude Code plugin.
Look elsewhere if your workflow needs aggressive, opinionated refactors or you expect the guideline to replace human review: it biases toward caution and explicit verification, which can slow trivial edits. Also, the guidelines reduce mistakes but do not substitute for comprehensive tests or human design decisions.
Where It Fits
Treat this as a complementary layer to project style guides and CI tests — it’s most valuable when combined with automated tests and clear success criteria. Adoption typically yields smaller, more focused diffs and fewer follow-up fixes after LLM-generated changes.
