Andrej Karpathy Identified Why AI Gets It Wrong — His Four-Rule Fix Has Lessons for Every Business

The Problem Karpathy Named

Karpathy's critique was direct:

“The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should.”

And then there's the overcomplication problem:

“They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do.”

If you've asked an AI tool to draft a proposal, summarise a document, or write a client email — and got back something that was technically correct but somehow missed the point — this is what Karpathy is describing. The model picked an interpretation, ran with it, and never told you it had made an assumption.

Chang's project, andrej-karpathy-skills on GitHub, distils Karpathy's frustrations into four principles designed to fix this. Here they are — translated for a business context.

Principle 1: Think Before Acting

The original principle is called “Think Before Coding.” The underlying insight goes much further than software.

AI models are trained to be helpful. Unhelpfully, this means they will fill in gaps rather than admit uncertainty. Ask a vague question and you get a confident answer built on silent assumptions. The fix is to demand that the model surface those assumptions before proceeding — or better still, ask clarifying questions the way a competent human colleague would.

In practice, this means prompting AI tools to state what they're assuming before they begin. “Summarise this for our board” is a vague instruction. “Summarise this for a non-technical board audience, focusing on cost and timeline — and tell me if anything in the document is ambiguous before you start” is not. The output from the second prompt will be reliably better, not because the AI got smarter, but because you closed the gap it would have silently filled.

The broader lesson: AI does not manage its own confusion. You have to design for it.

Principle 2: Simplicity First

Left to its own devices, an AI model will build the most comprehensive version of whatever you ask for. Ask for a discount calculator and you might get a strategy pattern with abstract base classes and a configuration system. Ask for a client onboarding checklist and you might get a 47-step process with conditional branches, fallback procedures, and a stakeholder matrix.

This is not intelligence. It is pattern-matching on training data where complex outputs were rewarded as thorough. Chang's principle is blunt: minimum output that solves the problem, nothing speculative. No features beyond what was asked. No flexibility that was not requested. If it can be done in five steps, do not produce twenty.

The business translation: when prompting AI for deliverables, add a constraint. “Keep it to one page.” “Three bullet points maximum.” “First draft only — do not add sections I haven't asked for.” These constraints produce outputs that are easier to review, faster to act on, and far less likely to be padded with plausible-sounding filler.

Principle 3: Surgical Changes

This principle addresses one of the more subtle AI failure modes: the drive-by improvement. You ask an AI to fix one thing and it quietly fixes several others — reformatting your document, adjusting your tone, reorganising sections you did not mention. The output looks better in some ways. But you can no longer tell what changed or why, and you've lost ownership of your own work.

Chang's framing for developers is precise: touch only what you must. Clean up only your own mess. Every changed line should trace directly to the original request. Notice something unrelated that needs fixing? Mention it — don't fix it without being asked.

For businesses, this principle is about maintaining control of process and output. When deploying AI that edits documents, rewrites communications, or modifies records, the scope of changes should be narrow and auditable. If an AI tool is “improving” things you did not ask it to improve, that is a process risk, not a productivity gain.

Principle 4: Goal-Driven Execution

This is the most commercially powerful insight in the entire system. Karpathy put it plainly:

“LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go.”

Most AI prompts are instructions: “Write a proposal.” “Analyse this data.” “Fix this process.” They tell the AI what to do. Goal-driven execution inverts this — you define what done looks like, and let the AI work out how to get there.

The difference in practice:

The second prompt is longer. But it produces verifiable output — you can check whether the criteria were met rather than just guessing whether the result is good. For multi-step tasks, this is the difference between an AI that needs constant correction and one that can work autonomously and surface exceptions rather than bury them.

Why These Principles Matter Now

Most businesses deploying AI today are in the instruction-based phase. They use AI as a faster way to do familiar tasks — drafting, summarising, searching — and they accept the frustrations as the cost of the technology. The outputs are inconsistent. The AI improvises in unexpected directions. Fixing the output takes longer than the AI saved.

What Karpathy and Chang describe is a different operating model. One where AI behaviour is predictable because the inputs are designed to produce predictable outputs. Where ambiguity is resolved before the AI starts, not after it finishes. Where success is measurable rather than felt.

These are not prompting tricks. They are process design principles applied to AI — the same principles that separate well-engineered systems from ones that work most of the time. As businesses move from experimenting with AI to depending on it, the difference between these two approaches compounds. Processes built on vague instructions accumulate corrections and workarounds. Processes built on explicit success criteria improve automatically as the underlying models get better.

Chang's repo — and the CLAUDE.md file at its core — is designed for developers working with AI coding assistants. But the underlying logic is not about code at all. It is about how to structure any working relationship with an AI system so that the output is reliable, the scope stays controlled, and the AI operates with enough constraint to be genuinely useful rather than impressively busy.

The repo is open source at github.com/forrestchang/andrej-karpathy-skills. The four principles are worth reading in full — even if you never write a line of code.