The Karpathy Method: How to Actually Build Software With LLMs

A useful way to think about coding with AI

Andrej Karpathy — former director of AI at Tesla and a founding member of OpenAI — has become one of the clearest voices on how software development is changing in the age of LLMs. Two of his ideas in particular have shaped how thoughtful teams now work: the reframing of programming itself, and a concrete discipline for working with AI without losing control.

Taken together, we like to call it the Karpathy method. It’s less a tool and more a way of working — and it happens to be a perfect fit for a private, local AI platform.

Software 1.0, 2.0, and 3.0

Karpathy’s framing is that we’ve moved through three eras of software:

• Software 1.0 — code written by hand in programming languages.
• Software 2.0 — neural network weights, “programmed” by data and optimization rather than explicit instructions.
• Software 3.0 — LLMs programmed in plain English through prompts. The prompt is the program.

The striking implication: natural language is now a programming interface. That dramatically widens who can build software and how fast — but it also introduces a new failure mode. Plain English is ambiguous, and LLMs will confidently produce code that looks right and isn’t.

Which is exactly why the second idea matters.

The generation-verification loop

Karpathy has been candid that the way to get real work done with AI is to keep the model on a tight leash — and to keep yourself, the human, firmly in the verification loop.

The core mechanic is a tight loop:

   ┌──────────────────────────────────────┐
   │                                        │
   ▼                                        │
Generate  ──►  Verify  ──►  Accept / reject │
(the LLM)     (the human)        │          │
                                 └──────────┘

The faster and tighter you can spin this loop, the more productive — and the safer — AI-assisted development becomes. Karpathy’s practical advice tends toward:

• Small, concrete steps. Ask for a focused change you can fully understand, not a sprawling one you can only skim.
• Keep diffs reviewable. If you can’t verify it, you shouldn’t accept it.
• Stay in the loop. The human is the quality gate. Auto-accepting large changes is where things go wrong.
• Concrete context beats vague prompts. The more relevant context the model has, the better — and more verifiable — its output.

He also coined the now-famous term “vibe coding” — leaning fully into the AI and barely looking at the code — but he’s been clear it’s best suited to throwaway projects and experiments, not the serious software a business depends on. For production work, the leash stays tight.

The autonomy slider

A related Karpathy idea is the autonomy slider: AI assistance isn’t all-or-nothing. You dial it up or down based on the task and your confidence. Autocomplete is low autonomy. “Refactor this function” is medium. “Implement this whole feature while I watch” is high. Mature teams move the slider deliberately rather than living at either extreme.

The skill isn’t “trust the AI” or “distrust the AI.” It’s knowing where to set the slider for the task in front of you — and being able to verify the result either way.

Why local AI is the perfect home for this method

Here’s the connection that matters for engineering teams: the Karpathy method works best when the generation-verification loop is fast, contextual, and private. That’s precisely what a local, codebase-aware platform delivers.

• Tighter loops. A model on your own network responds with low latency. The faster generation returns, the faster you verify, the more loops per hour. Speed isn’t a luxury here — it’s the whole game.
• Better generation. A private RAG index over your codebase means the model’s suggestions already fit your conventions and patterns, so they pass verification more often. Less rejecting, more accepting.
• Honest verification. When the model knows your real code, you’re checking a grounded suggestion, not fighting a generic one that doesn’t understand your system.
• Freedom to dial up autonomy safely. Because everything runs in your environment with full audit trails, you can push the autonomy slider further on the right tasks without worrying about where your code went.

Cloud tools can offer speed or privacy. A local platform offers both — which is what makes running a disciplined, high-throughput generation-verification loop genuinely practical at team scale.

Putting it to work

Adopting the Karpathy method across a team comes down to a few habits, supported by the right platform:

1. Default to small, verifiable steps and make that the path of least resistance in your tooling.
2. Feed the model real context through codebase-aware retrieval, so generation quality is high.
3. Keep latency low so the loop stays tight — which means serving models close to your developers.
4. Make autonomy a conscious choice, with the tooling and audit trails to support both low- and high-autonomy work.

Do this and AI stops being a novelty that sometimes helps and becomes a durable multiplier on how fast your team ships — without sacrificing the quality bar or the privacy of your code.

The bottom line

The Karpathy method isn’t about handing the keys to the AI. It’s about pairing the speed of generation with the judgment of a human in a tight, well-fed loop. A private, local, codebase-aware platform is the ideal place to run that loop — fast, grounded, and entirely under your control.

If you want to give your developers a platform built for exactly this way of working, book a discovery call.