Published November 2, 2026

Andrej Karpathy, who co-founded OpenAI, led Tesla's Autopilot work, and coined the term "vibe coding," spoke at Sequoia about how software development has changed. He described a sharp shift in late 2025, the emergence of a new programming paradigm, and the discipline he calls agentic engineering. He also discussed uneven AI capabilities, the design of infrastructure for agents, and the role of human understanding.

A Sharp Shift in December

Karpathy said he had used agentic tools such as Claude Code since their release the previous year. They wrote useful code fragments but made frequent errors that required correction. In December, he said, the models changed noticeably. Newer models produced correct code consistently, and he trusted them more with each task. He stopped correcting their output and began "vibe coding" most of his work.

He said the change was larger than most people realized. Many users knew AI as a chatbot like ChatGPT, but the state of the technology in December differed fundamentally, especially in coherent agentic workflows that now functioned in practice. He spent the following period building numerous side projects.

Three Paradigms of Software

Karpathy framed the change as a succession of programming paradigms:

In Software 2.0, programming consists of curating datasets and choosing objective functions and network architectures. In Software 3.0, a large language model trained on a broad set of tasks becomes a programmable computer. The contents of its context window act as the control lever. The model interprets that context and performs computation in the space of digital information.

Examples of the Paradigm Shift

OpenClaw installation. Installing OpenClaw traditionally required a shell script. Supporting many platforms and machine configurations made such scripts large and complex. In the Software 3.0 approach, installation reduces to a block of text that a user copies and gives to an agent. The agent reads the environment, follows the instructions, adapts to the machine, and corrects errors as it proceeds. Karpathy said this requires a different way of thinking: the question becomes what text to give the agent, not how to write each setup step.

MenuGen. Karpathy built MenuGen to solve a personal problem. He often could not tell what dishes on a restaurant menu looked like, and he estimated that 30 to 50 percent of items were unfamiliar to him. The application accepted a photo of a menu, recognized the dish names, generated images with an image model, and displayed the menu with pictures. He deployed it on Vercel.

He later saw the same function implemented in Software 3.0. A user could give a photo to Gemini and ask it to use Nano Banana to add dish images directly onto the menu. The model returned the original photo with the dishes rendered in its pixels. In this approach, the application is unnecessary. The input is an image, the output is an image, and the neural network performs most of the work.

Karpathy argued that this points to a broader change. Code previously processed structured data. Now models can transform unstructured information, reorganize documents, and generate new representations that were not possible before. In his knowledge-base project, a language model builds a wiki for an organization or an individual. No conventional program existed that could create a knowledge base from a set of facts. He said the most significant opportunity lies in creating capabilities that did not previously exist, not only in accelerating existing work.

Neural Computers and the Future of Computing

Karpathy described a possible future in which neural networks take a central role in computation. A device could pass raw video or audio into a network, which uses diffusion to generate an interface suited to the moment. He compared this to early computing, when the path was not yet clear. Classical computers became the dominant design, and neural networks now run on them in virtualized form. He suggested that neural network computation could eventually become the primary processor, with conventional CPUs serving as coprocessors for deterministic tasks. He said the transition would likely happen gradually, and that the exact path remains unknown.

Verifiability and Uneven Capabilities

Karpathy argued that AI automates tasks that can be verified more readily than others. Conventional computers automate what can be specified in code. Current large language models automate what can be checked.

Frontier laboratories train these models in reinforcement learning environments, where they receive rewards for verifiable outcomes. As a result, capabilities develop unevenly. Models reach high performance in verifiable domains such as mathematics and programming and remain comparatively weak elsewhere. Karpathy said laboratory priorities also shape this pattern. Laboratories build more environments for capabilities that matter economically. Programming is a clear example. Some verifiable domains are absent from training mixtures because the relevant capabilities are less valuable.

He gave three examples of this unevenness:

• Letter counting. For a period, models answered incorrectly when asked how many "r"s appear in "strawberry." This has since been addressed.
• Car wash decision. Advanced models advised walking to a car wash 50 meters away instead of driving. Karpathy said this contrasts with the same models' ability to process a 100,000-line codebase or find zero-day vulnerabilities, and called the inconsistency a sign that something is wrong or that users must remain involved and supervise the tools.
• Chess. The improvement from GPT-3.5 to GPT-4 in chess was larger than general capability gains would predict. Karpathy said this resulted from adding a large volume of chess data to the pretraining mixture. The chess data itself caused the sharp rise in that capability.

Karpathy said users depend on decisions made inside laboratories about what enters the training mixture. A system may perform well in areas covered by reinforcement learning and poorly outside its training distribution. Users must identify where their application falls. For unsupported domains, he recommended serious consideration of fine-tuning and custom work, because the required capabilities will not necessarily appear in a language model out of the box.

On the question of which tasks will be automated next, Karpathy said that most tasks can be made verifiable to some degree, though some are easier than others. He suggested that even writing could be evaluated by a panel of language models. He declined to name specific domains.

Vibe Coding and Agentic Engineering

Karpathy said vibe coding raises the floor of what anyone can build. Anyone can now create software through natural-language instruction. Agentic engineering, in his description, preserves the quality standards of professional software development. Developers remain responsible for their software and must prevent vulnerabilities that vibe coding can introduce. They can work faster, but the practice requires discipline.

He described agents as powerful but unevenly capable. They make errors and show occasional random behavior. Agentic engineering concerns how to coordinate these agents to move faster without lowering quality standards. Karpathy said the ceiling for skilled agentic engineers is much higher than the tenfold productivity gain once associated with strong engineers. He said people who master these methods achieve far more than that.

Developing Skill With Tools

Karpathy compared the difference between mediocre and strong practitioners to earlier tool mastery. Engineers have always gained more from their tools by investing in their environment and using every available capability. He cited editors, IDEs, and current agent tools such as Claude Code and Codex as examples.

Hiring for Agentic Skills

Karpathy said many companies now seek agentic engineering skills but still hire with traditional methods such as puzzles. He proposed a different test: give a candidate a large project and observe how they build it. As an example, he suggested building a secure, well-designed Twitter clone for agents. Several agents would simulate activity on the platform. Then ten Codex 5.4 instances would attempt to break the deployed site, and the site would need to withstand them. Under this approach, evaluators would focus on how candidates work in such an environment, how they build large systems, and how they use tools.

Human Responsibilities

Karpathy described current agents as capable interns. Humans remain responsible for taste, evaluation, judgment, and oversight.

He gave an example of a failure. In MenuGen, users signed in with a Google account and bought credits through Stripe, which used a different email address. The agent tried to match payments to accounts by comparing email addresses. Because no persistent user identifier existed, payments were not linked to the correct accounts whenever the emails differed. Karpathy said such errors show why people must define the specification and plan. He noted that he dislikes plan mode, although it is useful. The broader approach is to write a detailed specification, possibly as documentation, and assign agents to implement it. The human supervises the top-level structure, while agents handle lower-level details.

He also described delegation of technical detail. Libraries such as PyTorch, NumPy, and pandas differ widely in API conventions, including names like keepdims, dim, axis, reshape, permute, and transpose. He said he no longer memorizes these differences because an agent can handle them. Engineers still need to understand concepts such as the distinction between a source tensor and its views, whether views share storage, and the performance cost of unnecessary memory copies. Humans set direction, define requirements such as unique user identifiers, and fill architectural gaps.

Asked whether taste and judgment will matter less over time, Karpathy said he expects improvement but sees little progress now. Reinforcement learning does not currently reward aesthetic quality, or the reward is weak. He said agent-generated code is often bloated, contains copied and pasted fragile abstractions, and works while looking poor. He cited his MicroGPT project, in which he repeatedly asked a model to simplify its code and the model could not reach the simplicity he wanted. He said this suggests the models have moved beyond the territory covered by reinforcement learning. He sees no fundamental barrier and expects laboratories to address the gap.

Ghosts, Not Animals

Karpathy wrote that humans are not creating animals but summoning ghosts. These are uneven forms of intelligence shaped by data and reward functions rather than by evolutionary drives such as motivation, pleasure, curiosity, or self-improvement. He said it is important to accept that current systems are not animal intelligence. Shouting at them does not change their performance. They are statistical simulation systems. Pretraining supplies the statistical foundation, and reinforcement learning adds to it, amplifying the unevenness of capabilities. He said the practical implication is skepticism and gradual investigation. He did not offer five universal rules for improving a system.

Infrastructure Designed for Agents

Karpathy said most software, including documentation for frameworks and libraries, is still written for humans and must change. Much documentation tells users to visit a link or perform manual steps. He wants instructions that an agent can execute directly.

He framed agent-compatible systems in terms of sensors and actuators. The question is how to separate the tasks an agent must perceive from the actions it must take on the world, and how to make both accessible to agents. He noted that his existing automations already use data structures that language models read easily.

He cited deployment as the hardest part of MenuGen. Most effort went into connecting services, configuring settings and DNS, and managing deployment rather than writing the code. He said the ideal would be to give a model a request such as "create a menu," leave everything else untouched, and have a comparable application deployed automatically. He described this as a test of whether infrastructure is becoming suitable for agents.

Karpathy expects a future in which people and organizations are represented by agents. In one example, his agent would negotiate meeting details with another person's agent.

Education and Understanding

Asked what remains worth learning in depth as intelligence becomes cheaper, Karpathy cited a post he had read: one can transfer one's thinking to someone else, but not one's understanding. He said he still acts as part of the system. Information must still enter his mind, and he feels he is a bottleneck in understanding what should be built, why it is worth building, and how to direct agents. Someone must direct the thinking and information processing, and that process remains fundamentally limited by understanding.

He said knowledge bases help him process information. He reads an article, adds it to a personal wiki that grows from those articles, and asks questions. He also generates synthetic data from fixed datasets. He described these tools as amplifiers of understanding that remain insufficient on their own. Language models are not strong at understanding, and a person must remain responsible for it. He said he would be interested to revisit the question in a few years and see whether automation has replaced people in understanding as well.