As we have all been there. You ask an AI coding assistant to fix a small bug or add a simple feature, and it returns a thousand-line monstrosity. It refactors three unrelated files, deletes comments it didn’t understand, and introduces abstractions you never asked for. The result is not just frustrating; it is expensive.
Every unnecessary token costs you money, and every minute spent untangling the AI’s “help” is time stolen from real engineering work. This is the current state of LLM-assisted development: powerful, but dangerously prone to overconfidence and bloat.
Basically, it does what you do not ask it to do, and sometimes does what you ask it to do, but not as you want.
The Problem: When AI Gets Too Comfortable
The core issue isn’t that the models are dumb; it’s that they are too eager to please without thinking. As Andrej Karpathy pointed out, these models make wrong assumptions on your behalf and just run along with them. They don’t manage their confusion.
If they encounter ambiguity, they guess silently rather than asking for clarification. They don’t surface inconsistencies or present tradeoffs. Instead, they pick a path and sprint down it, often choosing the most complex route possible.
They love to overcomplicate code. They bloat abstractions and implement elaborate constructions when a simple function would do. Worse, they treat existing code as a suggestion rather than a constraint. They will change or remove comments and logic they don’t fully understand, even if those parts are orthogonal to the task at hand.
For a developer, this means you spend more time reviewing and fixing the AI’s output than you would have spent writing the code yourself. It breaks the flow state and erodes trust in the tool.
DO NOT COMPLICATE THE SIMPLE THINGS.
The Solution: Four Principles for Surgical Precision
To solve this, we need to constrain the AI’s behavior before it writes a single line of code. The solution lies in a single CLAUDE.md file derived from Karpathy’s observations. It enforces four principles that directly address these pitfalls, turning the AI from a chaotic generator into a disciplined partner.
Think Before Coding.
It is like think before you talk, but instead of talking we say “code”.
The AI must state its assumptions explicitly. If it is uncertain, it must ask rather than guess. It needs to present multiple interpretations of a request and push back if a simpler approach exists. This stops the silent guessing game that leads to major reworks later.
Simplicity First. NO overengineering
This principle combats overengineering. The AI is instructed to write the minimum code required to solve the problem. No features beyond what was asked, no abstractions for single-use code, and no “flexibility” that wasn’t requested.
If a task can be done in fifty lines, it shouldn’t take two hundred. The test is simple: would a senior engineer call this overcomplicated? If yes, it gets simplified.
Surgical Changes.
This is critical for maintaining codebase health. The AI should touch only what it must. It shouldn’t “improve” adjacent code, refactor things that aren’t broken, or delete pre-existing dead code unless explicitly asked.
It must match the existing style, even if it prefers something else. The only cleanup allowed is removing imports or variables that its own changes made unused. This ensures that every changed line traces directly to your request.
Goal-Driven Execution.
Instead of vague instructions like “fix the bug,” the AI transforms tasks into verifiable goals. It writes tests to reproduce the issue first, then makes them pass. For multi-step tasks, it outlines a brief plan with verification checks at each stage. This allows the model to loop independently until it meets strong success criteria, reducing the need for constant human clarification.
How This Saves You Time and Tokens
By enforcing these rules, you stop paying for the AI’s mistakes. You save tokens because the AI doesn’t generate thousands of lines of speculative bloat. You save time because you don’t have to untangle unrelated refactors or hunt down deleted comments.
The AI becomes predictable. It stops trying to be clever and starts being useful. It respects your existing architecture and focuses on the specific problem at hand. This isn’t just about better code; it’s about efficient engineering. You get the speed of AI without the technical debt it usually brings.
Setting Up the Guidelines
Implementing this is straightforward. You have two main options depending on your workflow.
For Claude Code users, the recommended method is via the plugin marketplace. From within Claude Code, add the marketplace and install the andrej-karpathy-skills plugin. This makes the guidelines available across all your projects automatically, ensuring consistent behavior without manual file management.
If you prefer a per-project approach or use other tools, you can use a CLAUDE.md file. For a new project, simply download the file from the repository. For an existing project, append the content to your current CLAUDE.md. If you are using Cursor, the repository includes a committed project rule that applies the same guidelines, ensuring your AI assistant stays disciplined regardless of the IDE you choose.
This setup takes seconds but pays dividends in every session. It transforms your AI from a noisy apprentice into a precise, cost-effective partner.
