Stop Prompting Claude. Use Karpathy's Method Instead.

When intelligence gets cheap (as AI improves), what still remains worth learning deeply is understanding; you can outsource your thinking, but you can't outsource your understanding.

“What still remains worth learning deeply when intelligence gets cheap as we move into the next eight era of AI? You can outsource your thinking, but you can't outsource your understanding.”

A spec is a detailed document that translates your understanding and contextual information into a format Claude can use; Karpathy advocates moving beyond high-level plan mode to work with AI agents to design much more detailed, compartmentalized specs.

“And a spec is how you deliver your understanding to Claude in a format it can use.”

AI models should be understood as 'ghosts' (or robot librarians), not 'animals' (humans with intrinsic motivation); this mental model fundamentally changes how you interact with, build, deploy, evaluate, and trust AI systems.

“And the idea is that we're not building animals, we are summoning ghosts. Why does that framing matter? And what does it actually change about how you build and deploy and evaluate or even trust them?”

State-of-the-art AI models will tell you to walk to a car wash 50 meters away because the distance is measurable, but they fail to understand the contextual constraint that you need a car to wash your car, revealing that AI is brilliant at what can be measured but lacks signal for context-driven reasoning.

“I want to go to a car wash to wash my car, and it's 50 m away. Should I drive or should I walk? And state-of-the-art models today will tell you to walk because it's so close.”

Because AI is a statistical system without motivation (ghost/librarian), not a motivated agent (animal), the only meaningful lever you have to improve performance is the verification lever; yelling at it, pleading, or saying 'make this better' does not work.

“Which means interacting with it like it's an animal, i.e. a human, doesn't help, right? Yelling at it, pleading, just saying, 'Make this better.' doesn't necessarily work. Really, the only lever you have, which most people don't even think to use, is the verification lever.”

AI models are brilliant at tasks where the answer can be measured (like math) because their training library (the 'books') contains clear answers; they fail or are uncertain when answers are context-driven because the library has gaps and the model doesn't know when it's missing information.

“And that's what's happening when AI nails math and fumbles things with context. It's brilliant because the library has the clear answers. But if it doesn't, then it's confidently wrong or uncertain.”

The fourth step in creating proper AI environment is to create rules for what the AI can and can't work on; depending on the cost of getting something wrong, you establish different AI guardrails at different severity levels.

“Step four is create rules for what the AI can and can't work on. Depending on the cost of getting something wrong, you need to establish different AI guardrails.”

You should treat your Claude.md environment as your world, and the AI should live in it; it should not feel like the other way around (where you're living in the AI's world).

“Make this your environment. It's your world, and AI is living in it. It should not feel like the other way around.”

The second step in creating proper AI environment is to build your LLM knowledge base: a folder system on your machine that ingests your own training data in a way that makes it easy for Claude to understand where information is; your data is your moat, and this begins building intellectual data property.

“The second step is you need to build your LLM knowledge base. Karpathy went viral for this concept on Twitter that he calls his LLM knowledge base. And this is essentially creating a folder system on your machine that you're able to ingest your own training data in a way that makes it really easy for Claude to understand where information is. This is so important because your data is your moat. And this begins the process of building out your own intellectual data property.”

The second verification focus area is to use a second AI model as a critic to grade the output of the first model; think of it as a second robot librarian from a different library with a different set of books, providing insight into why the first librarian is right or wrong.

“The second step is use a second AI model as the critic. Think of this like a second robot librarian from a different library. You use that librarian to grade the output of the first librarian. This other librarian has a whole different set of books, and that may give them insight into why this first librarian is right or wrong.”

Guardrails in Claude.md are guides, not hard rules (e.g., 'Don't make up information' can be ignored by Claude); for critical tasks where errors are costly, you need to implement rule-based guardrails at the tool level, not the prompt level, so Claude literally cannot bypass them.

“So, take the Claude.md file that I mentioned earlier. You could add a line that says, 'Don't make up information,' but that's a guide, not necessarily a hard rule. So, at the end of the day, AI can still ignore it.”

The robot librarian metaphor: AI systems are like librarians who can only suggest resources and answers based on books in their library; if the library doesn't have a book, the librarian can't help, and critically, the librarian doesn't know when it's missing a book, so it confidently makes something up.

“Instead, think of it like a robot librarian. If you ask it that same SEO question, the librarian will only suggest resources and answers based on the books in its library. If it doesn't have a book, it can't help you. And part of the challenge here is that the librarian doesn't know when it's missing a specific book. So, it may just confidently make something up.”

The more precise you are in your spec instructions, the less AI has to assume; every assumption AI makes is a chance for it to drift from the final product you want, so precision directly correlates with output fidelity.

“The more precise you are, the less AI has to assume. And every assumption that AI makes is a chance for it to drift from the final product you actually want.”

By optimizing the verification lever, you play within the actual rules that AI follows, making your AI system function at higher quality levels.

“Because by optimizing this, it makes it so that you're playing within the actual rules that the AI follows.”

The third step in creating proper AI environment is to build your skill set by creating custom skills for any task you plan to do repeatedly; think of each skill as a handbook to complete a specific task, and the more you use them, the better they become through iterative refinement.

“And step three is you have to start building out your skill set. A general rule of thumb that I have is if you plan on doing something repeatedly, create a custom skill for that. Think of this like a handbook to complete a specific task. And the more you use these skills, the better they'll become.”

The third verification focus area is to pull external signal where possible by bringing in additional context (data, historical examples, live system connections) that helps verify an output.

“And step three is pull external signal where possible. The question here is, how can you bring in additional context that will help you verify an output?”

Guardrails should be bucketed into three categories: (1) Always Do (tasks AI should run on autopilot), (2) Ask First (tasks you want to double-check), (3) Never Do (critical lines that cannot be crossed).

“So, with this in mind, bucket things into three groups. The first is always do. This is things that AI should run on autopilot. The second is ask first. So, this is anything that you want to double-check. And then the third is never do. These are lines that can't be crossed that are absolutely critical not to get wrong.”

The way to identify where your skills need improvement is to use them repeatedly: the heuristic is 'the best way to find a leak in a hose is to run water through it'; the more you use skills, the more you'll realize where you need to fix them and where they're strong.

“I have a saying that I tell my team, the best way to find a leak in a hose is to run water through it. And it's the same with skills. The more you use them, the more you'll realize where you need to fix them and where they're really good. Keep running water through it and your system's going to compound over time.”

When AI creates a spec for you, you must use your brain to think critically about what the spec says; instructing Claude to 'Make me verify key decisions explicitly to ensure nothing is missed' helps enforce critical human review of the spec itself.

“And when you have AI create a spec for you, you have to use your brain to think critically about what that spec actually says. So, to help you use your brain, you can say 'Make me verify key decisions explicitly to ensure nothing is missed.'”

The goal of any task is the conclusion you are trying to draw or the decision the task drives, which is fundamentally something AI will never be able to decide on its own; uncovering the actual goal is the first step to creating an effective spec.

“If you just say, 'Create a end-of-month report,' that's a task, but the actual goal is a conclusion you're trying to draw, the decision the report drives. And what the goal actually is is something AI will literally never be able to decide.”

The three layers of the Karpathy method are centered around your understanding of the bigger picture; you need to understand your goals and what's needed to direct AI to start working for you.

“And the thing with everything we covered here is that the three layers are centered around your understanding of the bigger picture. You need to understand your goals and what's needed to direct AI to start working for you.”

The first of three verification focus areas is to set the evaluation criteria upfront and with precision before Claude touches anything; vague criteria like 'make this report look good' should be replaced with precise criteria like 'the report must have three sections, each ending with a recommendation.'

“First, you want to set the evaluation criteria up front. Before Claude touches a single thing, whether that's technical or non-technical tasks, define what good looks like with precision. For example, a vague way to evaluate an output is, 'Make this report look good.' Whereas, a precise way would say, 'The report must have three sections, each ends with a recommendation.'”

Example of pulling external signal: for app deployment, connect your Claude session with your deployed system so Claude can verify deployment success directly against live system state rather than just trusting an output statement.

“Let's say you're deploying an app and you're not sure if it's successfully deployed. What you can do instead is connect your Claude session with your system where it's deployed, so it can verify that it has been deployed successfully. We are making a connection to pull external data to enhance our verification layer. And now, if it says that the deployment was successful, we know for certainty that it actually was.”

The complete Karpathy method is built from three layers: Layer 1 (the spec), Layer 2 (the verifier), and Layer 3 (the environment); these three layers together form an end-to-end system for fast, high-quality AI-assisted building.

“That's the Karpathy method end-to-end, the spec, the verifier, and the environment.”

Layer 1 (spec) and Layer 2 (verifier) require somewhere to live, which is Layer 3 (the environment); the environment is a persistent workspace system (like a workshop with a blueprint pinned to the wall, a quality check station by the door) that allows the system to function at a high level.

“So, layer one and layer two need somewhere to live, and that's layer three, which is the environment that you build in. Think of this layer as a workshop. The spec is a blueprint pinned to the wall, the verifier is the quality check station by the door, and then the environment is the workshop itself.”

The tactical implementation of agile specking is to bias Claude toward smaller and more compartmentalized specs with tight scope, clear checkpoints, and an explicit review-adjust-repeat cycle.

“You want to have a tight scope, a clear checkpoint, you want to review the output, adjust it, and then repeat. To help with this, we'll tell Claude to bias towards smaller and more compartmentalized specs.”

The first step in creating a proper AI environment is to set up a Claude.md file that gets injected automatically every time you prompt Claude; it's the first thing Claude reads to determine how it should operate, forcing key behaviors like verification into every build rather than making them optional reminders.

“First is you need to set up a proper Claude MD file. Every time you prompt Claude, your Claude.md file gets injected automatically. It's essentially the first thing that Claude reads to help determine how it should operate. For example, you can add to your Claude MD before building anything multi-step, include a verification plan. Now, verification is forced into every build, not something that you have to remember to say.”

Most people are prompting Claude wrong; specifically, they are not using the spec-verifier-environment framework that Karpathy advocates, which is why their results are suboptimal.

“I just listened to Andrej Karpathy speak at AISN 2026, and I learned something that I wasn't expecting. Almost everyone is prompting Claude wrong.”

Most people use a fresh workshop every time they use AI (i.e., they start a new chat session), rather than building a persistent environment that improves over time; a single chat with conversation history is not what proper environment building looks like.

“Now, the problem here is that most people use the workshop from scratch every time they use AI. And no, if you have a single chat with your entire conversation history, that is not what I'm talking about.”

When three spec creation pieces are combined (uncovering goal, agile breakdown, precision + critical review), the result is a final prompt in Claude that creates a tightly scoped, well-thought-out spec that aligns with the actual goal; this process is called modern engineering.

“And when you put these three pieces together, we have a final prompt we can use in Claude to help create a tightly scoped, well-thought-out aligns with our actual goal. This is a process that I call modern engineering, which every successful person has to become.”

To uncover a project goal, instruct Claude to interview you to identify the goal before building anything; this is the primary mechanism to extract contextual information from the human and encode it into the spec.

“So, to help you do this, we'll tell Claude to interview me to identify the goal of this project. This is the way to get the information out of you and into the spec.”

Karpathy's method for building 10x faster can be broken down into three simple layers: spec, verifier, and environment; these layers provide a complete operational system for fast, high-quality AI-assisted work.

“And it turns out that Karpathy's method for building 10 times faster can be broken down into three simple layers. So, in today's video, I'll be breaking down each layer so that anybody can apply them.”

Claude.md files should include multiple sections: (1) high-level explanation of how the repo works, (2) custom skills and how they're routed, (3) knowledge architecture describing where information lives, (4) key working rules Claude should follow no matter what.

“I outline how this repo works. So, think of my repo as my workspace. It gives high-level to the details around it. I then tell it the custom skills and how they're routed, how to use them. I then outline the architecture of the training data or knowledge architecture so that the AI knows where to look for certain information. And then I have key working rules that it should follow no matter what.”

Precise evaluation criteria are similar to Layer 1 (specs) in that the more precise you are upfront, the less room Claude will have to make mistakes.

“And if you're making the connection, this is very similar to what we covered in layer one. The more precise you are up front, the less room Claude will have to make mistakes.”

Boris Cherney, creator of Claude code, emphasized that if Claude has a proper feedback loop, it will 2-3x the quality of the final result.

“The creator of Claude code, Boris Cherney, said it best. If Claude has a feedback loop, it will two to three x quality of the final result.”

If Claude has a feedback loop (combining all three verification focus areas: precise evaluation criteria, second-model criticism, external signal), it will 2-3x the quality of the final result.

“The creator of Claude code, Boris Cherney, said it best. If Claude has a feedback loop, it will two to three x quality of the final result.”

Example of hard guardrail: create a folder called 'Important, Don't Edit' and add a pre-tool use hook that checks files before Claude uses write/edit tools; this enforces the rule at the tool level so Claude literally cannot edit critical files, rather than relying on Claude to respect a prompt-level instruction.

“To help you visualize this, imagine you have a folder called 'Important, Don't Edit.' You could have a rule in Claude MD that says, 'Don't touch anything in the /important, don't edit folder.' And that might get you 80% of the way there, but it's essentially a request, not a rule. Claude can still touch those files. So, instead, you add a pre-tool use hook before Claude uses the write or edit tool, and it checks to see the file that it's trying to edit. Now, Claude literally can't make the edit, and it's enforced at the tool level, not the prompt level.”

Example of pulling external signal: for non-technical tasks like monthly reports, bring in historical reports as reference so Claude can use them to ensure the final output matches the correct format and style, grounding the verification in past examples.

“In a non-technical example, let's say you're working on a monthly report. You could bring in your historical reports to use as reference for the exact format that the final output should be in, pulling in data and empowering the verification process.”