Kapcha's words at the SA 2026 - "Thinking can be outsourced, but understanding cannot."

124.26.***.***
7
What Andrej Karpathy said at SA 2026 - 'Thoughts can be outsourced, but understanding cannot.'

Photo by Daria Nepriakhina 🇺🇦 / Unsplash

On April 30, 2026, Andrej Karpathy gave a fireside chat at Sequoia Ascent 2026. He wrote a blog post summarizing his talk (https://karpathy.bearblog.dev/sequoia-ascent-2026/). Here's a summary.

First, a little introduction to Karpathy: He's a co-founder of OpenAI, former director of Tesla Autopilot, and currently working on AI education at Eureka Labs. In 2025, he coined the term "vibe coding."

The talk started with Karpathy saying he'd "never felt more behind as a programmer." The core theme was what it means for someone like Karpathy to feel behind.

1. December 2025 Was a Turning Point

Karpathy's quote:

"In 2025, tools like Claude Code and Codex were helpful but often required tweaking. Around December, there was a step change. I had a lot of free time during my vacation, and code blocks just worked. I kept requesting things, and they kept working. I couldn't even remember the last time I'd made a modification."

This marked the shift from "simple autocompletion" to "tools you could actually delegate work to." Karpathy sees this point as when the unit of programming shifted from lines of code to macro actions:

  • "Implement this feature"

  • "Refactor this subsystem"

  • "Research this library"

  • "Write tests, run them, and fix any failures"

Programmers are being redefined as "agent orchestrators" rather than "code writers." If you've been doing agent coding, you probably relate. I stopped looking at code much myself starting in March.

2. Software 3.0 - The Context Window Is the Program

Karpathy's classification:

Stage

Programming Method

Software 1.0

Humans explicitly write code

Software 2.0

Humans design datasets, objective functions, and neural network architectures; programs are learned as weights

Software 3.0

Humans program LLMs with prompts, context, tools, examples, memory, and instructions

In Software 3.0, the "context window is the main lever." The LLM acts as an interpreter of that context.

For example, installing a complex tool used to require shell scripts with lots of OS-specific conditional statements. In Software 3.0, you just need a single text block to paste into the agent. The agent reads the local environment, debugs errors, and adapts to the machine for installation. It's less precise but more adaptable.

3. MenuGen - A Case of Apps Disappearing

MenuGen, a side project by Karpathy, is a good example. This app generates food images from restaurant menu photos. Traditionally, it would involve:

  • Frontend code

  • OCR API

  • Image generation API

  • Deployment / authentication / payment / secrets / infrastructure

But in Software 3.0:

  • Give Gemini the menu photo

  • Instruct Nano Banana to render food images directly on top of the menu image

  • That's it

The entire app disappears. The neural network directly transforms input media into output media. The old software stack was just scaffolding for transformations that models can now do directly.

Karpathy's conclusion:

"AI is not just about making existing apps faster. Some apps need to stop existing as apps."

4. Verifiability - Where AI Moves Fastest

Karpathy's core framework for automation:

  • Traditional software automates what can be explicitly stated

  • LLMs and reinforcement learning automate what can be verified

If a task has automatic rewards or success signals, the model can train on it. That's why we see rapid improvement in math, coding, testing, benchmarking, and games. All of these are areas that are resettable / repeatable / rewardable.

This is also why coding agents seem dramatically better than regular chatbots. Coding gives the model feedback - tests pass or fail, programs run or crash, diffs are inspectable.

5. Jagged Intelligence - Ability Splitting into Two Axes

A key refinement of the talk is that verifiability alone isn't enough. Model capability depends on two things:

  1. Is the task verifiable?

  2. Has the lab poured training attention onto that task?

Rough formula:

capability spike ≈ verifiability × training attention × data coverage × economic value

Chess is a good example. GPT-4 likely became good at chess not because of smooth general intelligence improvements but because chess data was heavily added to the training mix. Someone at OpenAI decided to add that data, and as a result, we saw a capability spike.

To quote Karpasi directly:

"A state-of-the-art model can refactor a 100k line codebase and find zero-day vulnerabilities, but you ask it to walk to a car wash 50m away. That's jaggedness."

The important question for founders is "Is my task on the rails of the model?" If it's verifiable and heavily trained, the model will soar. Otherwise, it might surprisingly fail at basic things.

6. Vibe Coding vs Agentic Engineering

Karpasi distinguishes between vibe coding, a term he coined, and agentic engineering, which he emphasized in this talk:

Area

Goal

Vibe coding

Raises the floor. Enables anyone to describe what they want and have software built.

Agentic engineering

Raises the ceiling. A specialized field focused on orchestrating agents that can maintain accuracy, security, aesthetics, and maintainability.

Vibe coding is great for prototypes and personal tools. Agentic engineering is what serious teams need.

An agentic engineer doesn't blindly accept generated code. They design specs, oversee plans, inspect diffs, write tests, build evaluation loops, manage permissions, separate worktrees, and maintain quality.

7. MenuGen's Payment Bug Story - Why Human Judgment is Necessary

This is the most concrete example from the talk. When building a payment system in MenuGen, the agent tried to match Stripe payments with Google logins using email addresses. The code looked plausible, but the system design was flawed.

Stripe emails and Google login emails can be different. This could lead to users' purchased credits not being applied. The correct solution is to use a persistent user ID. This goes beyond "Does the code work?" and into the realm of "Is the system right?"

Karpasi's own diagnosis:

"Frontier skills aren't about memorizing every API detail. Agents are good at remembering things like dim, cognitive axis, reshape, permute. Humans still need to understand fundamental concepts - storage space, views, memory copies, immutability, identity, security boundaries, the shape of the system."

8. Hiring Needs to Change Too

If agentic engineering is a new skillset, then hiring needs to directly test for it, Karpasi argues. Traditional coding puzzles (like our country's coding tests) are becoming less relevant.

Karpasi suggests this interview process:

"Build a large project with an agent. Deploy it securely, and then have adversarial agents try to break it."

This interview tests the following real skills:

  • Can you decompose a task into agent-friendly subtasks?

  • Can you write useful specs?

  • Can you move quickly while maintaining quality?

  • Can you review generated work?

  • Can you secure and harden a system?

  • Are you leveraging the agent, or creating slop?

This suggests that the old concept of the "10x engineer" could become much more extreme. Someone who masters the agentic workflow could be orders of magnitude better than everyone else.

9. Agent-Native Infrastructure - Designed for Agents, Not Humans

Most software is still designed assuming that humans will click on screens. Documentation says things like "Go to this URL, click this button, and visit this settings panel." Karpasi puts it this way:

"My biggest pet peeve. Why are people still telling me what to do? I don't want to do anything. Just tell me what to copy and paste."

Agent-native infrastructure should have the following:

  • Markdown documentation

  • CLI

  • API

  • MCP server

  • Structured logs

  • Machine-readable schemas

  • Copy-pastable agent instructions

  • Secure permission management

  • Auditable actions

  • Headless setup flows

Karpathy explains this concept as sensors / actuators. Sensors convert the state of the world into digital information, and actuators allow agents to change something. Future stacks will be agents that use sensors and actuators instead of people and organizations.

10. Ghosts, Not Animals

Karpathy's other writing Animals vs. Ghosts also appears in the lecture.

LLMs are not animals. They lack biological drives, embodied survival pressures, curiosity, play, and intrinsic motivation with animalistic meaning. They are a statistical simulation of human output created by pre-training + fine-tuning + RL + product feedback + economic incentives.

This is important because anthropomorphic expectations can lead to misdirection. These systems are brilliant one moment and strangely obtuse the next. They are not smooth human minds but rather jagged alien tools. The appropriate stance is experiential familiarity: understanding where they work, where they fail, what they were trained for, and how they learn to paint guardrails.

11. Most Important - "Thinking Is Outsourced, Understanding Isn't"

Quote from the end of the lecture:

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

(Karpathy says he quoted someone he saw on Twitter)

Even if agents do more, humans still need understanding. Knowing what is worth creating, which questions are important, which results are suspicious, and which trade-offs are acceptable.

Karpathy's vision is that LLMs should be tools for converting information into understanding rather than just answer machines. His projects like microGPT (a single-file GPT implementation) and his work on an LLM knowledge base (which requires a slightly different approach, and many people are working on it as well) all point in this direction.

"Human experts contribute refined output and the taste behind it. Agents can explain that interactively to each learner."

The Bigger Picture - What Is Becoming Scarce

Karpathy's summary:

Less Scarce

More Scarce

Code generation

Understanding

API memorization

Aesthetics

Boilerplate

Evaluation design

First drafts

Security

Iterative setup

System boundaries

Simple transformations

Agent orchestration

Domain-specific feedback loops

Ability to know if a model has gone off the rails

Questions Karpathy poses to founders:

  • What becomes possible when the primary user is an agent that replaces humans?

  • Which workflows can be reconstructed with sensor / actuator / verifiable loops?

  • Which software will disappear due to direct model transformation?

  • Which domains are valuable and verifiable but haven't been extensively trained by frontier labs?

  • Where must human judgment remain within the loop to preserve quality?

Karpathy's conclusion:

"My current worldview is that AI isn't just making everyone faster at old things. The nature of work itself is being reorganized around agents. Software, research, education, infrastructure, knowledge work - all are variations on the same pattern: define context, define tools, define feedback loops, define guardrails, let the agent work, and preserve human understanding."

Summary

This lecture feels like a follow-up to last year's vibe coding talk. Last year was about "anyone can make software now," while this year is about "it's time to move to serious fields." Agentic engineering is emerging as a new field.

The most striking part is the concrete timeline: "December 2025 is the turning point". This isn't marketing hype; it's a statement based on Karpathy's own experience with his side projects filling up with random things.

However, Karpathy himself acknowledges that models are still jagged. He compares it to refactoring 100,000 lines of code while simultaneously being asked to walk to a car wash 50 miles away. This jaggedness clarifies why humans need to remain within the loop.

Original text: https://karpathy.bearblog.dev/sequoia-ascent-2026/ Lecture video: https://www.youtube.com/watch?v=96jN2OCOfLs


Source

  • Karpathy, , karpathy.bearblog.dev, 2026-04-30 (Primary source, authored by himself)

  • All quotes in this article are extracted from the transcript personally edited and summarized by Karpathy on his blog.

  • Lecture video: YouTube https://www.youtube.com/watch?v=96jN2OCOfLs

  • Reference articles: Karpathy , "Verifiability" (both on his personal blog)

로그인한 회원만 댓글 등록이 가능합니다.

개발한당

KR | ID | EN
  • IDR
  • KOR
8.35 -0.01

2026.07.10 KEB 하나은행 고시회차 1022회

다가오는 한인 행사일정

  • 등록 된 일정이 없어요!