OpenAI創設メンバーKarpathy氏のClaudeコーディング雑感から生まれた4原則 — CLAUDE.md 1枚でdiffの暴走を止める試み Drawing on Karpathy's casual critique of Claude coding behavior, the author distills four …

A recent Japanese-language blog post on Qiita translates a set of informal observations from Andrej Karpathy, a founding member of OpenAI, into a practical configuration recipe for developers using Claude as a coding assistant. The piece is worth attention because it tackles a familiar frustration with agentic coding tools: their tendency to produce sprawling, hard-to-review changes, often called "diff bloat."

Karpathy, who later led AI at Tesla and is widely credited with popularizing the term "vibe coding," has periodically shared candid impressions of how large language models behave when asked to write or edit code. A recurring theme in that commentary is that models often do more than they are asked. They refactor untouched sections, introduce speculative abstractions, wrap code in excessive error handling, and add defensive checks or comments that nobody requested. The result is a diff that is technically functional but disproportionate to the task, making code review slower and increasing the risk that subtle regressions slip through.

The author of the post takes these scattered remarks and distills them into four guiding principles aimed at keeping changes small and intentional. As presented, the principles emphasize doing only what was asked, avoiding unrelated refactoring, resisting the urge to over-engineer or add premature abstraction, and keeping edits surgical so the resulting diff stays minimal and reviewable. The framing appears to be the author's own interpretation rather than a verbatim list from Karpathy, but it captures the spirit of his critiques.

The novel part of the post is less the principles themselves than the delivery mechanism. Rather than repeating instructions in every prompt, the author encodes the four rules in a single CLAUDE.md file. CLAUDE.md is a project-level instruction file that Anthropic's Claude Code reads automatically, functioning as persistent context that shapes the assistant's behavior across a session. By placing the constraints there, a developer effectively gives the model a standing brief to favor minimal diffs without having to restate it each time.

This pattern mirrors conventions in adjacent tools. Cursor, the AI-centric code editor referenced in the post's category, has long supported rules files, historically .cursorrules and more recently a structured rules directory, that serve a comparable purpose. GitHub Copilot offers custom instructions, and other agents expose system-prompt or configuration hooks. The underlying idea is consistent across the ecosystem: steer a capable but over-eager model with concise, durable guidance rather than ad hoc prompting.

There are practical reasons this approach has gained traction. As coding agents take on larger tasks, the cost of reviewing their output rises, and a bloated diff can erase the time savings the tool promised. Smaller, well-scoped changes are easier to reason about, easier to revert, and align better with version-control workflows built around incremental commits. Constraining the model also tends to reduce the chance that it rewrites working code in ways that introduce new bugs.

The technique is not a guaranteed fix. Instruction files influence model behavior but do not enforce it deterministically, and a model may still drift from its brief on complex tasks or when instructions conflict with the immediate request. The effectiveness of any given rule set likely depends on the model version, the size of the codebase, and how clearly the task is specified. Readers should treat the four principles as a starting template to be tuned rather than a definitive standard.

Still, the post reflects a broader maturation in how developers work with AI coding tools. Early enthusiasm focused on raw capability, but the practical conversation has shifted toward control, reviewability, and predictable behavior. Lightweight