Karpathy's Latest Interview: Vibe Coding Was Just the Start — Agentic Engineering Is What Actually MattersKarpathy 最新访谈：Vibe Coding 只是开始，真正重要的是 Agentic Engineering

Andrej Karpathy says he can't remember the last time he had to correct AI-generated code.

Karpathy helped found OpenAI, led the Autopilot vision team at Tesla, and last year coined the term "vibe coding" in a tweet — later chosen by Collins Dictionary as its 2025 Word of the Year.

In April 2026, Karpathy was interviewed by partner Stephanie Zhan at Sequoia Capital's AI Ascent event. The 30-minute conversation covered his firsthand experience of the seismic shift in programming paradigms, what Software 3.0 really means, why AI is extremely capable in some areas and absurdly weak in others, and what the more serious next step is after "vibe coding."

Original video: https://www.youtube.com/watch?v=96jN2OCOfLs

Key takeaways

December 2025 was a personal turning point for Karpathy: AI output went from "helpful but often needs patching" to "directly usable," and he entered a state of fully vibe-coding.

The key to Software 3.0 is not "writing code in natural language," but operating a new kind of information-processing interpreter — the LLM — through prompts and context.

The MenuGen case made Karpathy realize that some AI applications won't just get built faster — they'll be swallowed whole by the model's native capabilities.

LLM capability is highly uneven: it can refactor 100,000 lines of code and find zero-day vulnerabilities, yet it can get a common-sense question like "should I walk or drive to a car wash 50 meters away" wrong.

Vibe coding raises the floor for everyone building software; agentic engineering is about preserving the quality, safety, and accountability bar of professional software while using agents to speed things up.

Humans no longer need to memorize every API detail, but they must understand system structure, underlying mechanisms, and quality standards — otherwise they can't supervise agents.

Karpathy describes LLMs as "ghosts": not animal-like intelligence, but jagged entities shaped by human documentation, pretraining statistics, and reinforcement learning rewards.

As intelligence becomes cheap, the focus of education shouldn't be resisting outsourced thinking, but ensuring understanding still reaches the human brain.

December 2025: A Programmer's Surrender

Zhan asked: you said a few months ago that you've never felt more behind as a programmer than you do now. Is that excitement or unease?

Karpathy said it's both.

Over the past year he'd been using agentic coding tools like Cursor. Early on these tools were useful — they could generate some code blocks, but they often had errors that needed fixing. The real turning point came in December 2025. He happened to be on vacation then, with more time to tinker on side projects, and he clearly noticed that the code blocks generated by the latest models had started to just "work out of the box."

At first, he only let the model write a little. The results were good, so he let it write more. After that, he found he hadn't personally corrected the model's output in a long time, and his trust kept growing. Eventually he entered the state he later called vibe coding.

I can't remember the last time I needed to correct it. And then I just kept trusting the system more and more.

"Vibe coding" here shouldn't be forced into a literal translation. More precisely, it's a way of developing where you let AI write code by feel: the human continually expresses intent in natural language, and the model generates, modifies, and debugs the code, while the human no longer writes or reviews diffs line by line as before. When Karpathy coined the term on X in February 2025, he was describing an experience of "giving up direct control over the code itself and letting the model move forward by feel."

But in this interview, Karpathy's focus has moved beyond vibe coding itself. He stressed that many people's impression of AI is still stuck at "something like ChatGPT": you ask, it answers. Since late 2025, what's worth taking a fresh look at is the agentic coherent workflow — a more coherent kind of agentic workflow. The model doesn't just answer questions; it can plan continuously, write code, debug, execute, and keep correcting itself based on feedback from the environment.

A lot of the AI most people experienced last year was still something like ChatGPT. But you really need to take another look — and look at the versions from after December.

In the past, a programmer's speed mainly depended on how much code they could write, how many APIs they could remember, and how they debugged. Now, speed increasingly depends on whether they can correctly direct a group of powerful but fallible agents.

Software 3.0: Copy-Pasting a Piece of Text to an Agent — That's Programming Now

Zhan asked: you say the LLM is a new kind of computer, not just better software. If a team truly believed that, how would they build products differently?

Karpathy started from his own framework of software eras.

Software 1.0 is traditional software: humans write explicit code, and the computer executes it by rules.

Software 2.0 is the neural network era: humans no longer write all the rules directly, but instead design datasets, objective functions, and neural network architectures, obtaining model weights through training. Karpathy wrote about "Software 2.0" back in 2017, treating neural networks as a new way of developing software.

Software 3.0 is the large language model era. After being trained on large-scale tasks, the LLM becomes a programmable computer. You're no longer just writing functions in a code editor — you're organizing a "contextual program" for the model to execute, across prompts, the context window, files, tool calls, and the external environment.

The context window can be understood as all the information the model can see in a single call: instructions, conversation history, files, error logs, code snippets, images, and tool results. In Karpathy's words, this context window has become the "handle" humans use to operate the LLM interpreter.

He gave an example of installing OpenCL. The traditional approach is to write a shell script that adapts to various machines, platforms, and environments. As the number of target environments grows, the script keeps bloating until it becomes too complex to maintain. But in Software 3.0, the installation instructions themselves can just be a piece of text you copy to an agent. The agent reads your machine's environment, executes the steps, and debugs when it hits errors.

The question now becomes: which piece of text should you copy to your agent? That's the new programming paradigm.

The point of this isn't that "programmers will only need to write prompts from now on." What Karpathy means is that the boundary of a "program" has expanded. In the past, a program was a code file. Now, a program might be a set of instructions, a context window, a set of tool permissions, a testing environment, plus the vast statistical structure the model has already learned internally.

MenuGen: This App Shouldn't Exist

Karpathy then talked about his own project, MenuGen.

The idea behind the app is simple: when people get a menu at a restaurant, they usually can't see pictures of the dishes. Many dish names, especially in unfamiliar cuisines, tell you nothing just from the text. Karpathy wanted to build an app: take a photo of a menu, have the app recognize the dish names on it, generate a rough image for each dish, and then re-render the menu so users can see roughly what the dishes look like.

Building this app the old way required several layers of intermediate steps: upload the photo, run OCR to recognize the text, extract the dish names, call an image generator to produce dish images, re-lay out the results, and deploy to Vercel. Karpathy built the app this way using vibe coding.

Then he saw the Software 3.0 version.

The approach became: hand the menu photo directly to Gemini, and say, have Nano Banana overlay these dish images back onto the menu. What Nano Banana returns isn't structured data, nor a set of components, but a new image: the original menu is still there, but images of the corresponding dishes have already been rendered directly into it, in place.

[Note: Nano Banana is the name of Google Gemini's image generation and editing capability, supporting conversational generation and editing via text, images, or a combination of both.]

Karpathy thinks the MenuGen he originally built is redundant, because it was still stuck in the old paradigm.

My whole MenuGen is redundant. It's still stuck in the old paradigm. That app shouldn't exist.

This example is one of the most important business judgments in the entire interview.

Many AI application companies think they're building "faster software." For instance, a task that used to take 10 steps now gets compressed to 3 steps by the app. But in Software 3.0, the model's own input and output may directly cover the entire task, and the intermediate app's structure loses its necessity.

Karpathy went further, saying this shift isn't confined to code. Traditional code is good at handling structured data: tables, arrays, database fields, explicit rules. But LLMs can handle more general reorganization of information. Take his project LLM Knowledge Bases, for example: it recompiles articles, documents, and facts into a personal or organizational wiki. This isn't something traditional programs are naturally good at, because it requires the model to understand relationships between pieces of text, reorder information, and generate new knowledge structures.

What's more exciting isn't making existing things faster, but things that simply couldn't have existed before.

Neural Computers: The CPU Becomes a Co-processor

Zhan asked: extrapolating this progress to 2026, what's something most people haven't built yet today that will look obvious in hindsight?

Karpathy put forward a bolder but more uncertain vision: the future might see a fully "neural computer" emerge.

Today's computers are still centered on the CPU, the operating system, and traditional programs. Neural networks run on top of existing computers, like a virtualized capability module. But Karpathy imagines it could flip: the neural network becomes the host process — the main flow — while the CPU, traditional code, and tool calls become co-processors handling certain deterministic tasks.

The scenario he imagines: a device receives raw video or audio, the neural network understands the current scene, and then a diffusion model generates a unique UI for that moment. The interface users see is no longer assembled from fixed components, but generated in real time by the model based on context.

He quickly added a caveat to this claim: this kind of extrapolation looks strange, the specific path is still TBD, it won't happen overnight, and it will arrive piece by piece.

"The neural network becomes the main process" isn't an established product fact — it's more of a mental model he uses to convey a sense of direction.

The LLM That Can Refactor 100,000 Lines of Code but Makes You Walk to the Car Wash

Zhan asked: if AI makes verifiable domains easier to automate, which jobs will move faster than people expect? Which seemingly safe professions are actually highly verifiable?

Karpathy didn't list professions directly. He turned instead to explaining "verifiability."

His core judgment is this:

Traditional computers make it easy to automate things you can write into code; this generation of LLMs makes it easy to automate things you can verify.

The premise of traditional software automation is that humans can write the rules out precisely — things like tax calculations, sorting, database queries, order status transitions. As long as the rules are clear, you can write code for them.

The LLM's automation boundary is different. It doesn't necessarily require you to spell out all the rules, but it does need some way to judge whether an output is good or bad. Math problems can be verified against an answer. Code can be run against tests. Certain security issues can be judged by reproducing an exploit. Tasks like these can enter a reinforcement learning (RL) environment: the model attempts the task, the system gives reward or penalty, and the model optimizes its behavior across a huge number of samples.

So the model's rapid improvement in math, code, and adjacent domains isn't simply because "the model got smarter overall." Karpathy believes this is tied to how frontier labs train their models. Labs construct large numbers of verifiable tasks, feed them into training and RL pipelines, and the model develops peak capability in exactly those areas.

This also explains the LLM's "jagged intelligence": the capability curve isn't a smooth rise, but has peaks and cliffs. Some tasks are astonishingly strong; others are absurdly weak.

Karpathy said a better example now is the car-wash question: I need to wash my car at a car wash 50 meters away — should I drive or walk? The most advanced model might say walk, because it's close. That answer misses the whole point of the question: it's the car that needs washing, so the car has to get to the car wash.

A state-of-the-art model can refactor 100,000 lines of code and find zero-day vulnerabilities, yet tell me I should walk to wash my car 50 meters away.

[Note: a zero-day vulnerability refers to a security flaw that hasn't yet been publicly disclosed or patched.]

If a task falls within a capability loop covered by the model's training and RL, it may perform like an expert. If it falls outside the data distribution, the model may get it wrong even if humans find it trivially easy.

This places high demands on the user. You can't assume the model is strong at every kind of engineering judgment just because it's strong at code. Nor can you conclude it's useless overall just because it makes a mistake like the car-wash question. The more accurate approach is to explore its capability boundaries, and figure out which tasks sit at a "capability peak" and which sit near a "cliff."

Capability Isn't Natural Evolution — It Tracks Labs' Data Decisions

Karpathy mentioned a detail: chess ability improved enormously from GPT-3.5 to GPT-4. Many people assume this was a natural evolution of capability, but in fact it happened because someone at OpenAI decided to add a large amount of chess data into pretraining. Once the data entered the distribution, the capability followed.

This reinterprets a story that looks like "the model got smarter" into a story about "the lab made a product decision."

To some extent, we're entirely constrained by whatever data the labs fed the model. If your use case happens to fall within the "capability loop" covered by RL training, the model will carry you far; but once you step outside that data distribution, it becomes extremely difficult.

Practical implication: If your application scenario falls within the covered capability loop, it works out of the box; if it's outside that loop, you need to do your own fine-tuning — don't expect the LLM to just know it from the start.

Startup opportunity: find a verifiable domain not yet covered by RL

Zhan asked: if an entrepreneur wants to tackle a verifiable problem today, but the big labs have already accelerated the most obvious areas like math and code, what should the entrepreneur do?

Karpathy's answer didn't name a specific track, but it offered a method for finding opportunities.

Under the current technical paradigm, verifiability makes a problem "solvable." If you can construct a large, diverse set of reinforcement learning environments that let a model try, fail, and receive rewards, then even if the big labs haven't made this domain a priority, you may still gain an edge through your own fine-tuning and training.

At this point he seemed almost about to name a domain he considers valuable, but stopped.

I don't want to just give you the answer... sorry, I don't mean to be vague up here on stage.

The audience laughed.

This pause itself reveals his judgment: the opportunity isn't something vague like "build another AI agent," but finding a specific problem for which a reward environment can be constructed.

He added a more radical remark: almost everything might eventually become verifiable to some degree. Even seemingly subjective tasks like writing and design could be imagined as being evaluated by a group of LLM judges — a panel of models — forming some kind of approximate assessment.

This statement needs to be understood carefully. Karpathy isn't saying every task can be perfectly automatically verified. He's talking about "degree" and "difficulty." Math and code are relatively easy because the answers or tests are fairly clear-cut. Writing, aesthetics, and strategic judgment are much harder.

Vibe Coding raises the floor, Agentic Engineering protects the ceiling

Zhan asked: last year you proposed Vibe Coding. Today we've entered a more serious world, more like agent engineering. What's the difference between the two?

Karpathy's distinction was very clear.

What Vibe Coding raises is the floor. More people can build software with AI using natural language. People who can't code can build small tools, and people who can code can build side projects faster. The entry point for creating software has widened.

What Agentic Engineering protects is the ceiling. It deals with professional software: you can't introduce security vulnerabilities just because you used AI, you can't lower the quality bar just because the model writes fast, and you can't have no one accountable just because the code was generated by an agent.

Vibe Coding raises the floor for everyone's ability to make software; Agentic Engineering has to protect the quality bar that professional software has always had.

Agentic Engineering can be translated as "intelligent agent engineering." It's not a specific tool but an engineering discipline: how to design, coordinate, and supervise a group of AI agents so they can accelerate development without sacrificing quality, safety, or maintainability.

Karpathy said these agents are "spiky entities." They're highly capable, but they make mistakes, are unpredictable, and unstable. An engineer's job isn't to blindly trust them, but to place them into an appropriate process: have them generate proposals, write code, run tests, check each other, and make sure the system has boundaries, verification, and rollback.

Karpathy also raised an even stronger claim: the software industry used to love talking about the "10x engineer" — an engineer far more efficient than the average person. But in Agentic Engineering, the acceleration he's seeing may be far more than 10x.

10x is not the multiplier you're getting.

A truly skilled person, who can organize multiple agents, tools, tests, and context together, will see their output amplified far more dramatically.

AI-native engineers: not about acing coding puzzles, but about making large projects safe

Zhan asked: if you observed two people using AI coding tools, one average and one truly AI-native, what would the difference be?

Karpathy first said that AI-native engineers make full use of the available tools and invest in setting up their own workflows. Just as engineers used to spend time configuring Vim, VS Code, the command line, shortcuts, and their dev environment, now they need to spend time configuring Cursor, Claude Code, or similar tools so they genuinely fit how they work.

But he quickly turned the topic to hiring.

He believes many companies still haven't restructured their interview process. If they're still giving candidates a set of small puzzles and having them solve algorithm problems on the spot, that's still the old paradigm. It doesn't test whether someone can work effectively within Agentic Engineering.

A better test should be a large project. For example, have the candidate build a Twitter clone: it not only has to run, but has to be built well and securely. Then use multiple agents to attack the site, trying to break it, and see whether the system can hold up.

The interview should really work like this: give the candidate a massive project, like building a Twitter clone for agents, and require it to be absolutely secure. Then, I deploy 10 instances of Cursor as a "red team" and let them go all out attacking the website you built.

The core of this kind of evaluation isn't whether the candidate can hand-write a certain algorithm, but whether they can: turn a vague goal into a clear specification; direct agents to complete a large-scale implementation; identify security and architectural risks; set up tests and verification; maintain quality judgment across a large volume of model-generated code; and make the final system withstand external attacks and stress.

Agents can write code, but they'll still bind payments to the wrong email address

Zhan asked: as agents do more and more, which human skills become more valuable?

Karpathy's answer: taste, judgment, aesthetics, oversight, and specification design.

He compared today's agents to interns. This analogy is accurate, but shouldn't be over-anthropomorphized. Agents aren't really employees with human motivations — they're just increasingly capable at execution, while still making mistakes in places that seem obvious to humans.

Karpathy gave a real example from MenuGen. Users log in with their Google account, but purchase credits using a Stripe account. Both Google and Stripe have email addresses. When implementing the purchase logic, the agent tried to match the Stripe email to the Google email in order to attribute purchased credits to the corresponding user.

This sounds reasonable at first, but it's dangerous from an engineering standpoint. A person could easily log into Google with one email and pay with a different one. If the system links funds by email, purchase records could fail to be attributed correctly, funds could get mismatched, or accounts could get mixed up. The correct approach should be to use a stable, internal persistent user ID to bind user identity and payment records together.

Why would you use email addresses to cross-reference funds? They can be arbitrary — you can use different emails. This approach is just too strange.

This kind of problem has no syntax errors, the code might run, the tests might even pass, but the system design is wrong. The agent didn't truly understand the risks around identity, payment, and fund attribution.

So Karpathy says humans must be responsible for the spec, the specification. You have to tell the agent: all funds and user state must be bound to an internal unique user ID, not to an external email address. You have to be responsible for the top-level design, constraints, and judgment criteria. The agent can fill in implementation details, but it can't understand the system's boundaries for you.

He then gave a more technical example. These days he no longer memorizes many of the trivial API differences between PyTorch, NumPy, and pandas — things like whether it's keepdims or keepdim, dim or axis, or how reshape, permute, and transpose are each written. These details can be left to the agent, because the model's memory is excellent.

But he still stressed that humans must understand the underlying concepts. For example, what a tensor is, the relationship between view and storage, when something merely changes the view onto the same block of memory versus when it actually copies data. If you don't understand these underlying mechanisms, you might let the model write inefficient or even incorrect code.

This gives a very concrete answer to "what's worth learning": details can be outsourced, but understanding cannot. API names can be forgotten, but the conceptual structure cannot be lost.

The code the model writes runs, but sometimes it's "ugly"

Zhan followed up: will taste and judgment become less important as models improve?

Karpathy didn't rule it out entirely. He hopes models will improve, and sees no fundamental reason preventing them from getting better at taste, aesthetics, and simplicity. But he pointed out that, at least for now, these abilities haven't been well trained, possibly because they haven't been captured by a good enough RL reward environment.

When he looks at code generated by models, he sometimes feels like he's having a mild heart attack. The code runs, but it isn't necessarily good. It can be bloated, full of copy-paste, have awkward abstractions, be structurally fragile, and be hard to maintain.

Sometimes when I see the code it writes, I get a bit of a heart-attack feeling. It runs, but it's really gross.

He also mentioned the MicroGPT project. He wanted to simplify LLM training to the extreme, making the training process as small, clear, and understandable as possible. He kept asking the model to "simplify it further," but the model couldn't do it. It felt as difficult as "pulling teeth."

I kept telling the LLM to "simplify it more," and it just couldn't do it. You can feel that you're outside the RL loop. It's like pulling teeth.

Karpathy's explanation is that this task may fall outside the capability loop covered by the model's RL training. Models are good at generating common engineering patterns, but not good at extreme, restrained, elegant abstraction and compression.

We're not building animals: Karpathy says we're summoning "ghosts"

Zhan asked: you wrote an article about animals vs. ghosts, whose core idea is that we're not building animals, we're summoning ghosts. Why does this framework matter?

Karpathy said he wrote that article because he himself was trying to understand what these models actually are. If you have a better mental model of what a model is, you'll be better at using it.

The word "ghost" sounds mystical, but Karpathy's meaning isn't esoteric. He's contrasting two sources of intelligence.

Animal intelligence comes from evolution, embodiment, interaction with the environment, intrinsic motivation, curiosity, enjoyment, and continual learning. Animals act in the world, are shaped by consequences, and keep adapting throughout their lives.

LLMs aren't like that. Today's frontier LLMs start from large-scale pretraining: the model learns statistical structure from a massive corpus of human documents. Then reinforcement learning, preference data, tool use, and other post-training processes are layered on top. They're not animal-like intelligences, but simulated entities shaped by human documents, statistical patterns, and reward functions.

In the interview, he distilled this metaphor into a very plain usage principle: don't treat the LLM like an animal. Yelling at it won't make it work harder out of fear. Encouraging it isn't sparking any intrinsic motivation either. The model has no animal-like emotions. Its behavior comes from statistical simulation, context, tools, training data, and reward mechanisms.

If you yell at it, it won't work any better or worse because of that — there's no effect at all.

Karpathy also admits the "ghost" framework has a somewhat philosophical side. He didn't claim it directly yields five concrete optimization tips. It's more like a reminder to prevent misuse: don't ask broadly "is the AI smart or not," ask which training distributions it's strong in, which reward signals shaped it, and on which tasks it might hit jagged cliffs.

Agent-first infrastructure: build and deploy MenuGen with one sentence

Zhan asked: when agents don't just chat, but hold permissions, have local context, and can act on a person's behalf, what will the world look like?

Karpathy said almost everything will need to be rewritten. Today's tools, documentation, services, and setup flows are still mostly designed for humans.

For example, a framework's documentation will tell you: go to some URL, click some setting, copy some key, open some menu, configure some DNS. Karpathy's reaction is: why is it still telling me what to do? I don't want to do these things. What I want to know is which piece of this can be copied straight to my agent so it can go do it itself.

Why is someone still telling me what to do? I don't want to do any of it. "What's the thing I can copy-paste to give to the agent?"

This isn't laziness, it's a paradigm shift. The goal of agent-first infrastructure is to break the world down into inputs an agent can understand and action interfaces an agent can safely call.

In software infrastructure, this means documentation, APIs, permissions, logs, deployment, configuration, billing, and rollback all need to become more agent-friendly. Instead of having the agent simulate a human clicking through web pages, let the agent directly understand state, call actions, and receive feedback.

Karpathy returned to MenuGen. He said the most troublesome part of building MenuGen wasn't actually writing the code, but the deployment: deploying on Vercel, connecting various services, going through different settings pages, configuring DNS, and stringing everything together.

He hopes the future standard test will be: give an LLM the sentence "Build MenuGen," and it can not only write the code, but also complete the deployment, get it live on the internet, configure the necessary dependent services — all without a human having to click through menus one by one.

Further out, he imagines that every individual and every organization might have its own Agent representation. In the future, scheduling meetings, handling details, and coordinating logistics might become "my Agent talking to your Agent."

When intelligence gets cheap, understanding becomes the most expensive thing

Zhan's final question: when intelligence becomes cheap, what is still worth learning deeply?

Karpathy quoted a line:

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

This line is easy to turn into a motivational slogan, but Karpathy's explanation was concrete.

He is still part of the system. Information has to get into his head. He feels he's becoming the bottleneck: he needs to know what's actually being built, why it's worth building, and how to direct his Agent. You can let the model run through many reasoning steps, but if the person doesn't understand, they can't judge which path is right, can't write good specs, and can't catch the Agent's mistakes in identity binding, system structure, or code quality.

I feel like I'm becoming the bottleneck: I need to know what we're actually building, why it's worth building, and how to direct my Agent.

This is also why he's interested in LLM knowledge bases. He likes re-projecting articles, materials, and facts into wikis, because organizing information in different ways can help him gain insight. To him, this isn't about letting AI replace understanding—it's about using AI to augment understanding.

This connects to the engineering examples mentioned earlier:

An Agent can remember API details, but a person needs to understand tensors, views, storage, and memory efficiency;

An Agent can write payment logic, but a person needs to understand user identity and ownership of funds;

An Agent can generate large amounts of code, but a person needs to judge whether the abstraction is bloated or the structure is fragile;

An Agent can help you think through many options, but a person needs to know whether the goal is worth pursuing.

So once intelligence becomes cheap, learning doesn't become unimportant—rather, the center of gravity of learning shifts. Less time goes into rote memorization and low-level execution, and more time goes into system understanding, problem definition, quality judgment, causal reasoning, and domain intuition.

Q&A Quick Look

Q: What happened in December 2025? A: Code generated by the latest models no longer needs modification, and reliability held up even in sustained projects.

Q: How is Software 3.0 different from before? A: Before, code processed structured data; now you can process arbitrary information. Things that couldn't be done before can now be done. This isn't acceleration—it's a new set of possibilities.

Q: Why do state-of-the-art AI models make elementary mistakes on simple tasks? A: The capability distribution depends on which domains RL training covered and the labs' data choices. Capability in verifiable domains has surged, while other domains may remain weak.

Q: What's the difference between Vibe Coding and Agentic Engineering? A: Vibe Coding raises the floor for everyone; Agentic Engineering uses Agents to accelerate while maintaining professional standards.

Q: When will human taste and judgment stop mattering? A: Possibly—but only if labs incorporate aesthetic rewards into RL training objectives. Right now, Agent-written code often "works but looks awful."

[Finally]

In this interview, there are a few tensions in Karpathy's judgments worth noting.

First, he says on one hand that the code Agents produce is ugly enough to give him a heart attack, and on the other hand that he himself has stopped editing it. "Trust hasn't solved the taste problem"—working code and good code aren't the same thing. But this state of "using it even though it's ugly" may be closer to the real state of Vibe Coding than any hype.

Second, he hints there are "underrated RL opportunities" in certain domains but is unwilling to name them publicly. For someone who doesn't shy away from posting blunt tweets, deliberately avoiding the topic is itself a signal: the window hasn't closed yet. Notably, his company Eureka Labs works on AI education—and education happens to be a domain where output can be evaluated and standardized for assessment.

Third, he himself downgrades the "animal vs. ghost" framework, then closes out the whole conversation with "you can outsource thinking but not understanding." Read together, his judgment is: what's truly scarce isn't any particular skill, but the ability to judge "what we should actually build, and why it's worth doing." If the premise holds that "almost every domain can eventually be made verifiable," then the bottleneck ultimately isn't on the execution side, but on the goal-setting side.

But there's an implicit question mark over time here. Karpathy himself admits that taste and judgment are only temporarily irreplaceable because "the labs haven't done it yet." If that's true, then the supposedly irreplaceable human part isn't irreplaceable because humans are unique, but because the training methods aren't there yet. That puts a question mark over how long "you can outsource thinking but not understanding" will remain valid.

Three concrete signals worth watching over the next 6-12 months:

Which domains beyond coding/math the frontier labs inject RL data into—capability will suddenly emerge there

Whether agent-first infrastructure (deployment, auth, payments) sees its first wave of convergence—if the pain of deploying something like MenuGen persists, the road to an "automated society" is much longer

Whether the next generation of model updates includes RL objectives related to aesthetics and code quality

Original video: https://www.youtube.com/watch?v=96jN2OCOfLs