📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Stop Prompting Claude. Use Karpathy's Method Instead.

Austin Marchese13:19

Transcription

I just listened to Andrea Cararpathy speak at AISN 2026 and I learned something that I wasn't expecting. Almost everyone is prompting Claude wrong.

So I decided to dig deeper and see exactly how Carpathy, the former head of AI at Tesla, uses AI in 2026. 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. And then I'll show you the one thing that Carpathy said to focus on in the age of AI.

So layer one is the spec. AI models are incredibly smart, but they're still missing something. To showcase their current limitation, Carpathy explained a simple question AI will get wrong. "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.

At first, I actually didn't believe this. So, I went to Claude, Gemini, Grock, and Chad GBT, asked them the same question, and they all gave me the same answer, and it reveals the whole foundation of this video. AI is brilliant at what can be measured, but for context driven things like needing a car for a car wash, it has no signal to act on. So, how do you bridge this gap between your understanding and your contextual information and AI's computational power? That's where the spec comes in. And a spec is how you deliver your understanding to Claude in a format it can use. A term you may have heard is Claude's plan mode, which essentially can be used to help you create a plan before building anything. But Carpathy thinks that this is too high level. I actually don't even like the plan mode. I I would I mean obviously it's very useful, but I think there's something more general here where you have to work with your agent to design a spec that is very detailed. Now, Carpathy isn't telling you that plan mode is bad. What he's actually saying is you have to go deeper. Work with these AI tools to design the actual spec.

So, how do you create a spec that Claude can successfully use to build what you're trying to build? The first step is you have to uncover your goal. 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. 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.

Now step two is be agile with how you work. There are two methods of completing any task. The first is waterfall and the other is agile. Waterfall is you take a big task and you complete the entire thing and then you show the final product. Agile on the other hand is you break that same task into small buckets and you show the result throughout the entire process to make sure you're going in the right direction. And people are extremely susceptible to using AI agents in a waterfall manner because they want to give them everything to do at once. The better move is agile specking. 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 Claw to bias towards smaller and more compartmentalized specs.

Step three is you want to be precise and use your brain. 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. 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." And when you put these three pieces together, we have a final prompt we can use in Claude to help create a tightly scoped, wellthoughtout spec that aligns with our actual goal. This is a process that I call modern engineering, which every successful person has to become.

Now, layer two is the verifier. Layer two sits on top of the spec. This is the verification process. One of the most frustrating things about AI is reviewing and verifying the output. And unlike a human, it can't grasp non-measurable things. So, how can we help AI verify its own outputs? Well, first you need to understand the mental model behind this. And Carpathy explains it as animals versus ghosts. Here's him getting asked a question about this in a recent interview. And if it sounds confusing, don't worry. I will simplify it after.

"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?"

"Yeah, I think the reason I wrote about this is because I'm trying to wrap my head around what these things are, right? Because if you have a good model of what they are or are not, then you're going to be more competent at uh using them. I think it's just um coming to terms with the fact that these things are not, you know, animal intelligences, like if you yell at them, they're not going to work better or worse or it doesn't have any impact. Um and uh it's all just kind of like these statistical simulation circuits. It's more just being suspicious of it and um figuring out over time."

Now that's some gigab brain stuff but let me simplify it. People me and you are used to interacting with people which Carpathy is calling animals. These animals are driven by different motivators and emotions which help produce the final product and output within a team setting. And if you say to a person "become an expert at SEO marketing in the next 14 days or you're fired," they're going to figure it out. That's because they have these intrinsic motivations. But AI is not that. Carpathy describes it as a ghost. But in my eyes, that's a little too confusing. So throw it out the window. 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. 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, 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. Because by optimizing this, it makes it so that you're playing within the actual rules that the AI follows.

So, how do you help AI verify the output so it's up to the standard you want? Well, there are three places to focus on. 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." And if you're making the connection, this is very similar to what we covered in layer 1. The more precise you are up front, the less room Claude will have to make mistakes. To help enforce this, we'll add this to our verification Claude prompt: "Outline the evaluation criteria you will use to ensure a highquality final product. Be precise."

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. Now a tactical way to do this if you use claw code you could install the codeex plugin which will allow you to directly ask codec questions within your claude code session. So you could say something like "if this turns into a complex build run the final output by codeex to ensure both systems agree."

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? Here are two concrete examples. 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 clawed 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. 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.

Now bring in this concept with the first two points. Combining this third point with the first two points, here is a prompt that you can run in Claude which will help ensure that you are adding a proper evaluation layer where it makes sense. I can't stress how important this is. The creator of Claude Code, Boris Churnney, said it best. If Claude has a feedback loop, it will two to 3x quality of the final result.

So layer 1 and layer two are about creating specs and evaluating the output. The third layer, however, is where we build a foundation that can't be replicated. But before we get to that, if this is your first video of mine, welcome to the channel. If it's your second or more, here is our anti-slop agreement. The visuals, the testing, the hours of research that went into this video, this is entirely built for humans, not for AI clankers. So all that I ask is that you subscribe as part of this agreement because it helps it reach more people so that I can keep making videos like this. Also, every couple of weeks I give away a Claude Max subscription. So, comment below with whatever you're building to enter.

Layer three, the environment. So, layer 1 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. You need to create the proper tooling and the proper system so that the whole thing can function at a high level. Now, the problem here is that most people use a workshop from scratch every time they use AI and know if you have a single chat with your entire conversation history. That is not what I'm talking about.

So, how do you create a proper workspace that improves over time? First is you need to set up a proper Claude MD file. Every time you prompt Claude, your claw.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. This is just one of the ways that you can improve this Claude MD. And here's actually mine on the screen. And I'm going to call out a couple of sections. The first is 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. 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 is you need to build your LLM knowledge base. Carpathy 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 mode. And this begins the process of building out your own intellectual data property.

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. 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.

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 guard rails. So, here's how to think of this, right? So, take the claw.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. So if you have things that are critical not to get wrong, then you need to introduce rulebased guard rails to ensure that the AI can't bypass them. To help you visualize this, imagine you have a folder called "important don'tedit." You could have a rule in Claude MD that says "don't touch anything in the /important don'tedit 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. And as a result of this, this is now a concrete rule that the agent can't bypass. 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. Here's a prompt that brings all of these four points that I mentioned to help audit your system and create an optimized environment for claw to interact with.

That's the Carpathy method end to end. The spec, the verifier, and the environment. But there's a question that needs to be answered. What's the one thing that Carpathy thinks we should focus on in the age of AI? Here's him getting asked this in an interview.

"What still remains worth learning deeply when intelligence gets cheap as we move into the next era of AI?"

"You can outsource your thinking, but you can't outsource your understanding."

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. Now, if you like this video, you will love this one where I do a deep dive into four clawed projects that you need to build today using these three layers. I'll see you over there.