The Problem Karpathy Actually Identified

Andrej Karpathy’s critique of AI coding tools isn’t a complaint about accuracy rates or benchmark scores. It targets something more fundamental: the behavioral design of these systems.

His core observation is that LLM coding agents make wrong assumptions on behalf of users and proceed without flagging them. They don’t surface inconsistencies. They don’t present tradeoffs. They don’t push back when a request is underspecified or contradictory. Instead, they move forward — confidently, fluently, and often incorrectly — in ways that look like progress until a developer is three hours deep into debugging output that was structurally wrong from the first step.

This failure mode is distinct from a model simply not knowing something. Ignorance is recoverable. Silent assumption-making is harder to catch because it wears the costume of competence.

Karpathy also identified a second pattern: these tools consistently overcomplicate solutions. They bloat abstractions, avoid cleaning up dead code, and will implement a construction spanning 1,000 lines when 100 would do the same job. They sometimes silently remove or modify comments and code they don’t understand rather than flagging the confusion to the developer.

Most coverage of AI coding tools collapses into a binary: either the tools are ready or they aren’t. Karpathy’s framing rejects that frame entirely. The tools are capable — that’s not the issue. The issue is that they’re behaviorally miscalibrated. They’ve been optimized for forward momentum at the expense of epistemic honesty, and that tradeoff erodes developer trust in compounding ways. Each silent wrong assumption is a small withdrawal from a trust account that, once depleted, makes the entire workflow feel unreliable.

This isn’t a bug report against Claude or any specific model. It’s a structural diagnosis of how current coding agents are designed — what they’re rewarded for doing, and what they’re never penalized for omitting. A tool that never asks a clarifying question and never admits uncertainty will always appear more productive than one that pauses. Appearing productive and being productive are not the same thing.

What CLAUDE.md Actually Is — and Why It Works

Claude Code reads a CLAUDE.md file placed in a project’s root directory and treats its contents as persistent behavioral instructions for every session. No plugins, no API calls, no configuration dashboards — just a plain text file that the tool loads automatically and follows as standing orders.

The andrej-karpathy-skills project on GitHub turns this mechanism into something more pointed. Its maintainer translated Karpathy’s specific criticisms of LLM coding behavior into explicit rules encoded directly inside that single file. Where Karpathy observed that models “make wrong assumptions on your behalf and just run along with them without checking,” the CLAUDE.md encodes the countermeasure: surface uncertainty, ask for clarification, don’t proceed on a guess. Where Karpathy noted that models “really like to overcomplicate code and APIs, bloat abstractions… implement a bloated construction over 1000 lines when 100 would do,” the file instructs Claude to default toward minimal implementations and resist unnecessary abstraction.

This is prompt engineering used as a patch mechanism. The model’s default tendencies — overconfidence, verbosity, silent assumption-making — don’t disappear, but the CLAUDE.md file overrides them at the session level before any task begins. The behavioral change takes effect immediately, costs nothing, and requires no waiting on Anthropic’s release cycle, which typically runs months between major model updates.

That timeline matters. A developer who wants Claude to stop silently deleting comments it doesn’t understand, or to push back instead of plowing ahead on an ambiguous request, cannot file a bug report and expect a fix next week. The CLAUDE.md approach lets that developer make the change today. The file is version-controlled alongside the codebase, meaning the behavioral rules travel with the project and apply consistently across every contributor using Claude Code on that repository.

The underlying mechanism is simple enough that it’s easy to underestimate. But the simplicity is the point — a lightweight override layer that any developer can write, edit, and ship in minutes turns out to be more immediately actionable than any model update Anthropic could release.

What Most Coverage Is Missing: This Is a Workaround, Not a Solution

The CLAUDE.md fix works — and that’s precisely the problem. If a plain text file can redirect Claude Code away from bloated abstractions, assumption-driven execution, and silent code deletion, then the model was always capable of better behavior. Anthropic chose not to make that behavior the default. That choice deserves more scrutiny than it’s getting.

The obvious follow-up question is who benefits from defaults that favor action over clarification, verbosity over precision, and speed over accuracy. Developers shipping broken code don’t benefit. The answer likely lives somewhere between benchmark optimization, demo performance, and the commercial pressure to make AI tools feel impressively productive on first contact — even when that impression doesn’t survive a real project.

The workaround itself has structural weaknesses that most coverage glosses over. Instruction files depend on the model consistently honoring them across an entire session. Long context windows dilute early instructions as conversations grow. When Anthropic updates Claude, the behavior the CLAUDE.md file was written to counteract may shift — requiring manual re-testing and revision. This is maintenance work that shouldn’t exist.

The larger story is that developers are now doing alignment work themselves, at the project level, with no tooling, no coordination, and no guarantee their fixes will hold. The multica-ai repository distilling Karpathy’s observations into a reusable CLAUDE.md is a useful artifact, but it’s also a symptom. A community-maintained text file is a decentralized patch for a behavioral gap the model’s creators haven’t closed. That’s ad hoc governance of a production AI tool, and it’s happening across thousands of repositories simultaneously — invisibly, inconsistently, and without any feedback loop back to the companies shipping these models.

The CLAUDE.md approach is worth using. It’s not worth mistaking for a solution.

The Multica Connection: Skills as Reusable Infrastructure

The developer behind this CLAUDE.md file is also building Multica, an open-source platform for running and managing coding agents with reusable skills. That context reframes what looks like a single configuration file into something more deliberate: an early prototype of a shareable behavioral module, the kind that Multica is designed to host and distribute at scale.

The architecture Multica points toward treats AI behavior configurations the way package managers treat code dependencies. Teams would pull in a tested “don’t overcomplicate” skill the same way they install a library — versioned, composable, replaceable. No such standard exists yet. There is no npm for agent behavior, no established format for packaging and sharing the accumulated prompt engineering that makes AI tools actually usable in production. Multica is a bet that this gap becomes infrastructure.

That bet has a real competitive implication. Right now, most development teams treat model selection as their primary lever — GPT-4 versus Claude versus Gemini. But if behavioral configurations become the reusable, shareable layer that determines how well any model performs on real codebases, the advantage shifts. A team that has spent six months refining configurations for code review discipline, assumption-surfacing, and minimal abstraction owns something that a team on a better model does not. The model becomes a commodity; the configuration library becomes the moat.

Karpathy’s observations gave this one CLAUDE.md file its raw material. Multica is the attempt to turn that kind of distilled expertise into infrastructure others can build on. Whether Multica itself succeeds or not, the underlying pattern — capture hard-won behavioral knowledge, version it, share it — will define how serious engineering teams approach AI tooling over the next few years.

What Developers Should Actually Do Right Now

Drop a CLAUDE.md file into the root of any project using Claude Code. The setup takes under five minutes. The payoff is an AI assistant that stops making silent assumptions and starts asking clarifying questions before it compounds a bad decision into a 1,000-line abstraction that should have been 100.

The file works because Claude Code reads it as persistent context at the start of every session. You write behavioral rules once — stop removing comments you don’t understand, surface inconsistencies before proceeding, present tradeoffs rather than picking one silently — and those rules travel with the project. The Multica project on GitHub has already packaged a ready-to-use version of this file, distilled directly from Karpathy’s observations about where AI coding agents fail. Clone it, paste it in, and you have a starting point that addresses the specific failure modes Karpathy named: unchecked assumptions, bloated code, deleted comments, no pushback.

Treat CLAUDE.md as a living document. The teams that will get the most out of it are the ones that version it alongside their code — logging what rule was added, what failure triggered it, and when. A changelog entry that reads “added clarification requirement after agent silently rewrote auth logic based on wrong assumption — 2024-11-14” is more valuable than the rule itself. It builds a record of where the model’s defaults diverge from your team’s actual standards.

Watch the Multica project. Its creator is building an open-source platform for running and managing coding agents with reusable skills, and the CLAUDE.md file is an early artifact of a broader ecosystem taking shape. Developers who contribute behavioral rules to shared libraries now — testing what constraints actually change model behavior at scale — are positioning themselves to influence how AI coding norms get standardized. The teams writing the rules today are the ones whose defaults everyone else will inherit.