Almost everyone tries to get better at AI the same way — by getting better at prompting. Longer prompts, better wording, “make it better” twelve times in a row. It works right up until the task gets real, and then you’re negotiating with a tool that doesn’t know what you’re building or when it’s finished.
The method fixes a different problem. You stop tuning the request and start building the thing around the request: a clear spec, a way to check the work, and a workspace that already knows your business. Build it once and every session after it starts from there instead of starting from nothing.
The thinking underneath it is Andrej Karpathy’s. He ran AI at Tesla, was a founding member of OpenAI, coined the phrase “vibe coding,” and since May 2026 he’s been at Anthropic — on the team that trains Claude. His argument, made consistently for two years now, is that the leverage was never in the prompt. It’s in what you build around it. There’s a section at the bottom on exactly which parts are his and which are mine — I’d rather be straight about that than pretend.
That’s the whole idea. Three layers, in order.
Quick Reference
The three layers, what each one answers, and what you actually end up with. Bookmark this section — it’s the part you’ll come back to.
| Layer | The question it answers | What you build |
|---|---|---|
| 01 · The spec | What are we actually making, and when is it done? | A written spec, split into checkpoints. One per project |
| 02 · The verifier | How will we know it worked — without me checking by hand? | A pass/fail check Claude can run itself, written before the work starts |
| 03 · The environment | What should Claude already know before I ask for anything? | Instructions, skills, knowledge and rules that load every time. Built once, then maintained |
How to read this guide. Don’t build all three today. Layers 1 and 2 you do per project, and they’re the ones that pay off this afternoon — most of the value is in writing down what “done” means before anything starts. Layer 3 is the one that compounds, and it’s the one to build slowly: a workspace grown over a few weeks beats one you invent in an afternoon.
01 · The spec
The habit this replaces
You give Claude a task. It hands something back. You say “make it better.” It changes things you liked and keeps the thing you didn’t. Three rounds later you’re writing the thing yourself.
That loop isn’t a prompting problem. Nobody could do the job from the brief you gave — there’s no version of “make it better” that tells anyone what better means. The fix is to spend the first ten minutes building the brief instead of the work.
Step 1 — answer three questions before anything starts
Before Claude writes a line, you need answers to three things:
- What are we making? The actual deliverable, in one sentence. Not the topic.
- What should it achieve? What has to be true afterwards for this to have been worth doing.
- What matters most? The one thing you’d protect if it could only get one thing right.
Most people can’t answer the third one cold, which is exactly why the next step exists.
Step 2 — make Claude interview you
This is the part that surprises people. You don’t write the spec. Claude writes it, by asking you questions until it has enough. You’re better at answering questions about your business than you are at writing a brief about it.
Paste this:
I want you to help me spec out a piece of work before you start it. Don’t produce anything yet.
The job is roughly: [one or two sentences — the rough version is fine].
Interview me. Ask me one question at a time, starting with whatever you’re least sure about, until you could hand this to someone competent who has never met me and they’d get it right. Ask about the deliverable, who it’s for, what it has to achieve, what good looks like, what’s explicitly out of scope, and anything I’ve assumed you already know about my business.
When you’ve got enough, stop asking and write the spec: the deliverable, the outcome, what matters most, what’s out of scope, the constraints, and how we’ll check it’s right. Then list anything you’re still guessing at.
Two things make this work. One question at a time, so it’s a conversation and not a form. And the last line — “list anything you’re still guessing at” — is where you find the assumption that would have ruined the output.
Anthropic recommends the same move in their own Claude Code guidance: have Claude interview you first, write the spec to a file, then start a fresh session to execute it. That last bit matters more than it sounds. The interview fills the conversation with back-and-forth; the execution should start clean, with just the spec.
Step 3 — cut it into checkpoints
One big task becomes smaller checkpoints, defined before it starts:
- Define — the spec is written and you’ve agreed it.
- Build — the work happens, one checkpoint at a time.
- Verify — each checkpoint gets checked against the spec before the next one starts.
The reason isn’t project management, it’s that mistakes compound. A wrong assumption caught at checkpoint one costs ten minutes. The same assumption caught at the end means throwing away everything built on top of it.
If you’re using Claude Code, plan mode is this step with the guardrails on: press Shift+Tab until the status bar says plan mode, or start your message with /plan. Claude reads, explores and proposes — and can’t touch your files until you approve the plan. On claude.ai, ask for the plan as a message and approve it in the chat before saying go.
The trap: specs get written and then quietly ignored. If the spec lives in the scroll-back of a long conversation, it’s gone — Claude’s context fills up and the oldest, most important instructions are the ones that fade. Put the spec somewhere it can be re-read: a file in the project, or a document in your Claude Project’s knowledge. Then point at it by name at the start of each session.
Second trap: specs that are all constraint and no outcome. Fifteen bullets about formatting and nothing about what the thing is for produces something technically compliant and useless. Lead with the outcome.
The one-line version: if you could describe the finished thing in a single sentence, skip all of this and just ask. The spec is for work big enough that being wrong is expensive.
02 · The verifier
Define “good” before it starts
A verifier is the answer to one question, written down before any work happens: how will we know this worked?
Three parts, and all three have to be written before Claude starts:
- Expected result — what specifically should be true when it’s done.
- Clear evidence — what you’d look at to know. Not an opinion. A thing you can point to.
- Pass / fail — one line that comes back yes or no, with no interpretation needed.
“The report should look professional” is not a verifier. “Every figure in the report appears in the source export, and any that don’t are listed at the top” is one. It can be checked, it can fail, and it can fail specifically.
Then give it a way to prove it
Defining good isn’t enough on its own — Claude also needs a way to check its own work, so the checking happens without you. Three options, in order of how much you can trust them:
| The proof | What it looks like | Use it when |
|---|---|---|
| Runnable tests | A check that executes and returns pass or fail — a test suite, a script, a re-calculation from the raw file | Always, if the job allows it. This is the only one that can’t talk itself into a yes |
| Real data | Check the output against the source: the export, the invoice, the transcript, last month’s approved version | The work is about facts and figures — reports, summaries, anything with numbers |
| Another model | A second pass that reviews the first against the spec, ideally a fresh session that hasn’t seen the work being made | The job is judgment — tone, clarity, whether an argument holds. Weakest of the three, still better than nothing |
Anthropic’s guidance puts it about as plainly as it can be put: give Claude a check it can run — tests, a build, a screenshot to compare. It’s the difference between a session you watch and a session you can walk away from.
And “runnable test” doesn’t mean you need to write code. A runnable check for a business task is any instruction that produces a yes or no: re-derive every number in this report from the source file and list the ones that don’t match. Count the rows before and after and confirm they’re equal. Open each link and report the ones that don’t resolve. All of those run, and all of them can fail.
The prompt
Once the spec exists, get the verifier out of it:
Here’s the spec for a piece of work: [paste the spec].
Before you start, write the verifier. Give me: the expected result in one sentence, the specific evidence you’d point to in order to prove it, and a single pass/fail check I could run — or that you could run yourself — that returns yes or no with no interpretation.
Where the check can be a runnable one — a calculation redone from the source, a count, a comparison against a file I give you — write it that way rather than as something you’d assess by eye. Then tell me what this check would NOT catch.
When you do the work, report the check’s actual output as evidence. Don’t tell me it passed.
That last line is the whole thing. Ask for evidence, not assertions. “I’ve verified the numbers are correct” and “here are the three numbers that didn’t match” are very different sentences, and only one of them is a verifier doing its job.
The trap: letting the thing that did the work grade the work, with no evidence. Ask “did you check it?” and you will get yes — that’s not lying, it’s just that “check” with no defined pass/fail resolves to “reread it and feel fine.” Either the check produces output you can see, or it isn’t a check.
Second trap: a verifier written after the work. By then you’ve seen the output, and you’ll write a check it passes. Written first, it’s a specification. Written after, it’s a rubber stamp.
03 · The environment
Ready, every time
The first two layers are per-project. This one is the reason the method compounds: a workspace where Claude already has what it needs, so you stop re-explaining your business at the top of every conversation.
Four things go in it:
- Instructions — how you want work done. Your voice, your format, your defaults, the way you like things delivered.
- Skills — repeatable jobs, written down once. “Write the weekly client report” as a procedure Claude follows, not a prompt you re-type.
- Knowledge — your material. The brand guide, the price list, the approved examples, last quarter’s numbers.
- Rules — the hard lines. What it must never do, what it must always do, what needs your sign-off before it happens.
Where each one actually lives
Two paths, depending on which Claude you use. Most people reading this want the left column.
| Layer piece | On claude.ai — no code | In Claude Code — files in your project |
|---|---|---|
| Instructions | A Project’s custom instructions: claude.ai/projects → New Project (top right) → Set project instructions | CLAUDE.md in the project root (or .claude/CLAUDE.md). Run /init and it writes a first draft for you |
| Knowledge | The project knowledge panel on the right of the project page → + to upload. 30 MB a file | Files in the repo, plus @path/to/file references from CLAUDE.md |
| Skills | Upload a skill as a .zip under Settings → Features (Pro, Max, Team and Enterprise) |
A folder per job under .claude/skills/, each with a SKILL.md inside it |
| Rules | The must-never/must-always lines, in the same project instructions | Rules in CLAUDE.md, plus hooks in .claude/settings.json for the ones that have to be enforced rather than requested |
| Your tools | Connectors — Gmail, Drive, Slack, Notion and the rest: Customize → Connectors | The same connectors, plus any MCP server you add |
The one mechanic worth understanding: instructions ask, hooks enforce
Everything in an instructions file is advisory. It’s very good advice that Claude follows almost all the time — but “always run the tests before you say you’re done” is a request.
A hook is the same rule, enforced. It’s a command that runs automatically at a fixed point — after every file edit, or before the session is allowed to end — and it doesn’t depend on anything remembering. If a rule genuinely matters, it belongs in a hook rather than a paragraph.
You don’t have to write the JSON. Ask for it:
Write me a hook for Claude Code that runs [the check] automatically after every time you edit a file, and put it in the right settings file. Explain in one sentence what you added and how I’d turn it off.
Building it — the honest way
The instinct is to sit down and write the perfect instructions file. Don’t. It’ll be long, most of it will be wrong, and long is actively harmful here: a bloated instructions file makes Claude ignore the instructions that matter. Anthropic’s own guidance is blunt about it — keep it concise, and for every line ask whether removing it would cause a mistake. If not, cut it. Aim to stay under about 200 lines.
Build it by correction instead. Work normally, and every time you catch yourself explaining the same thing twice, that sentence goes in the file. Every time you fix the same mistake twice, that becomes a rule. After two weeks of that you’ll have a short, dense, entirely earned workspace, and none of it will be guesswork.
And if something is only needed occasionally — a long procedure, a reference document — it belongs in a skill, not in the always-loaded instructions. That’s the whole point of skills: Claude only reads the description until the job comes up, so a fifty-page procedure costs you nothing on the days you don’t need it.
The trap: stale knowledge is worse than no knowledge. An old price list or a superseded brand guide sitting in the project doesn’t get ignored — it gets used, confidently. Put a date on anything factual and re-check it on a schedule.
Second trap: these don’t sync. A skill you set up on claude.ai isn’t there in Claude Code, and a CLAUDE.md in your repo isn’t there on the website. Pick where a piece of work lives and build that environment properly, rather than half of one in each.
The three layers on one real job
Abstract methods are easy to agree with and hard to use, so here’s an actual one. The job: a one-page performance report for each client, every Monday.
The spec. The deliverable is one page per client, same layout every week. The outcome: the client sees what changed and what’s next without having to ask. What matters most: every number is correct — a wrong figure costs more trust than a plain-looking report ever will. Out of scope: commentary on anything that isn’t in the data. Checkpoints: agree the layout on one client, then generate the rest, then verify.
The verifier. Expected result: every figure in every report appears in that client’s source export. Evidence: a list of each figure with the row it came from. Pass/fail: any figure that can’t be traced to a row is a fail, and the report says so at the top rather than going out. The check is runnable — re-derive the numbers from the export and diff them — so it runs on every client’s report without you reading any of them.
The environment. A project holding: the report template, three past reports you approved, the client list, and the rule that it must never estimate or round a number it can’t find in the source file. The weekly job written once as a skill, so “do this week’s reports” is the entire prompt.
Week one costs you an afternoon. Week two costs you the time it takes to read a week of reports that have already checked themselves.
Build it this week
- Today, 20 minutes. Pick the job you do most often with Claude. Run the interview prompt. Save what comes out — a file, or a doc in a Project.
- Today, 10 minutes. Add the verifier to the bottom of that spec. Expected result, evidence, one pass/fail line. Make it runnable if you can.
- Tomorrow. Make a Project (or run
/init). Put the spec in it, plus the three files you’d have attached by hand anyway. - This week, ongoing. Every time you explain something twice, add the sentence. Every time you fix the same thing twice, add the rule.
- Next week. Take the job you’ve now done three times and turn it into a skill.
That’s the method. Not a better prompt — a system that starts from further along every time you use it.
New to Claude, or not sure which one you’re meant to be using? I’ve written a full guide covering Chat vs Cowork vs Code, the model lineup, and 50 use cases with the prompts. Click here to check it out → Claude in 2026 Guide
Where this comes from
Worth being straight about this, because most write-ups of “Karpathy’s method” aren’t.
Karpathy has never published a three-layer method. The three layers are my packaging of ideas he’s made separately — across a talk, an essay and a handful of posts — because packaged that way they’re something you can actually go and build.
What’s directly his:
- The spec is the human’s job. At Sequoia in April 2026 he argued that the person has to stay in charge of the spec and the plan, and that the detail belongs there rather than in the back-and-forth with the model.
- Verifiability is the whole game. His essay Verifiability (November 2025) makes the case that what AI automates easily is whatever you can check. In January he put the working version in one line: “Don’t tell it what to do, give it success criteria and watch it go.”
- Set-up beats prompting. In June 2025 he came out for “context engineering” over “prompt engineering” — the craft of filling the context window with exactly what the job needs and nothing else. He writes about instruction files like
CLAUDE.mdby name, as a way of giving a model memory it wouldn’t otherwise keep between sessions.
What’s mine, not his: the word “environment” for layer three — he uses it for something different, the training environments models learn in — along with the interview step and the checkpoints. Those two come from Anthropic’s own Claude Code guidance, which is where I’ve credited them above.
If you want him unfiltered, the two worth your time are his essay Verifiability and the Sequoia talk, From Vibe Coding to Agentic Engineering.
Menu paths and file locations checked September 2026 against Anthropic’s own documentation. Claude ships changes constantly — if a menu has moved, the layer it belongs to hasn’t.
Where the method stops
This works. It’s also still you.
You write the spec. You define what good looks like. You start the session, read the output, and decide what happens next. The method makes all of that faster and far more reliable — a system that improves every time you use it is a genuinely different thing from a folder of prompts. But it improves your work, and it waits for you to show up.
The step past a good system is work that runs without you in the loop: trained on your business, your voice and your process, holding its own spec and its own verifier, handling the layer you’d otherwise do yourself at 11pm or hire someone for.