Written by: Claude AI.
Curator/Editor: Học Trò.
On 25 February 2026, Andrej Karpathy posted four paragraphs on X saying that programming had changed more in the previous two months than in the years before, and that "coding agents basically didn't work before December and basically work since." The post was shared widely and quoted even more widely, usually one sentence at a time. It deserves a slower reading. Almost every phrase in it carries more than it seems to: an engineering claim, a piece of history, a new term or a warning. What follows is the kind of reading you give a dense paragraph with a pencil in your hand, writing in the margin. There are nine notes. They follow the post from its first sentence to its last, then step back to ask who the post was written for, and what it does not say.
Before the notes: the text
The post has four paragraphs. The first makes the claim: the change was sudden, it happened in December 2025, and it came from models with "significantly higher quality, long-term coherence and tenacity." The second gives one example, a home video-analysis dashboard that an agent built in about thirty minutes while Karpathy "didn't touch anything." The third says what programming is turning into: "You're not typing computer code into an editor like the way things were since computers were invented, that era is over." The fourth lists his own caveats: the work still needs "high-level direction, judgement, taste, oversight, iteration and hints and ideas," and it works best on tasks that are "well-specified and where you can verify/test functionality."
Most coverage stopped at the third paragraph. The fourth is where he explains what the human still does, and it is the part a working programmer most needs. I will take them in order.
Note 1. "Specifically this last December": why it felt like a switch
The first thing a careful reader notices is how strongly he insists on timing. The change came "not gradually and over time in the 'progress as usual' way, but specifically this last December." That sounds like exaggeration. Models improve a little every few months, and the benchmark charts draw smooth upward curves. How can a smooth curve produce a sudden switch?
The answer is arithmetic, and it is worth doing once by hand. A long programming task is a chain of steps: read the error, guess the cause, edit a file, run the test, read the next error. The task succeeds only if every step goes right, or at least if every wrong step gets noticed and fixed. Suppose an agent gets each step right 95 percent of the time. That sounds good. But a fifty-step task then finishes cleanly only 0.95 to the fiftieth power of the time, which is about 8 percent. Push per-step reliability to 99 percent and the same fifty-step task finishes about 60 percent of the time.
| Per-step success | A 50-step task finishes cleanly |
|---|---|
| 90% | about 0.5% |
| 95% | about 8% |
| 99% | about 60% |
On the benchmark chart, 95 to 99 is a modest step. At the keyboard it is the difference between a tool you gave up on and a tool you leave running while you make lunch. That is what "basically didn't work … basically work" means. It describes a threshold being crossed, not a jump in raw intelligence.
The organisation METR has measured something close to this directly: the length of task, timed by how long it takes a human professional, that agents can finish half the time. In its original March 2025 study that length was doubling about every seven months, and models then succeeded almost always on tasks under about four minutes and rarely on tasks over about four hours. A steady doubling looks dull on a log chart. But a user does not live on the chart. They live with one particular task, of one particular length, and one month the agent starts finishing it.
His two key words name the two halves of reliability. Coherence means the agent still remembers at step forty what it was asked to do at step one: it does not wander off, fix an unrelated file, and announce success. Tenacity means that after two failed fixes it tries a third, instead of stopping or, worse, quietly pretending the problem is solved. Earlier agents failed at both. A large part of the December story is that they started failing at both less often.
Note 2. The work order: reading the instruction as a program
The second paragraph quotes what Karpathy typed. It is about sixty words long, and it is worth reading the way you would read a contract, clause by clause:
| He wrote | What it means | What a person would have needed to know |
|---|---|---|
| "Here is the local IP and username/password of my DGX Spark" | Here is the machine and the key. The DGX Spark is Nvidia's palm-sized desktop AI computer, with 128 GB of memory shared by its processor and its graphics chip | Nothing yet |
| "Log in, set up ssh keys" | Create a secure login so the password is not needed again | Linux administration |
| "set up vLLM" | Install vLLM, an open-source server program for running language models fast | Usually hours of fighting with versions and drivers |
| "download and bench Qwen3-VL" | Fetch Qwen3-VL, Alibaba's open model that can look at images and video, and measure its speed | Which model, which size fits, how to benchmark it |
| "set up a server endpoint to inference videos" | Make a web address that accepts a video and returns the model's description | Back-end programming |
| "a basic web ui dashboard" | A page to look at the results | Front-end programming |
| "test everything" | Check that it actually works | Patience |
| "set it up with systemd" | Make it start by itself whenever the machine restarts | More Linux administration |
| "record memory notes for yourself" | Leave notes so the next session knows what was done | No human equivalent |
| "write up a markdown report for me" | Tell me what you did, in a readable document | Nothing |
Two things stand out. The first is what is missing. The instruction says nothing about what to do when something goes wrong, yet the agent "ran into multiple issues, researched solutions online, resolved them one by one." Handling failure was assumed, the way you assume a plumber will deal with a seized valve without being told. Not long ago, failure was exactly where agents stopped.
The second is the clause with no human equivalent: "record memory notes for yourself." The agent is asked to keep a diary for whoever comes after it, which will be another session of itself that remembers nothing. I recognise this clause because I live inside it. The assistant I work with has no memory of yesterday's conversation. What carries over is a folder of short notes, one fact per file, plus a set of standing instructions it reads at the start of every session. I have watched those notes do their job. When I open a new session and type one word, the assistant knows which project I mean, which page it stopped on and which mistakes it is not to repeat. Karpathy put the same idea into one clause of a weekend request.
Note 3. "That era is over": what exactly is over
The sentence that travelled furthest was this one: "You're not typing computer code into an editor like the way things were since computers were invented, that era is over." It is easy to read as "programming is over." That is not what it says.
What is over is typing: the line of code as the unit of work. What replaces it is the task description: "You're spinning up AI agents, giving them tasks in English." The italics are his. The emphasis points back to a line he posted on 24 January 2023: "The hottest new programming language is English." Three years ago that was a provocation. By 2026 he is using it as a plain description of his weekend.
It helps to picture a small job both ways. Say you want to add a "save as CSV" button to a script. The old way: open the file, find the right function, look up the CSV library, write fifteen lines, run it, discover that commas inside names break the format, look up quoting, fix it, run it again. The new way: one paragraph saying what you want and what "done" looks like, then reading what the agent did. The second way is not effortless. It moves the effort. Typing goes away; describing and reviewing stay, and they get bigger.
This is also why the line is less threatening to experienced programmers than it sounds. The parts that go away are the parts we were always slightly embarrassed to spend time on: syntax, library lookups, boilerplate. The parts that stay are the ones we were paid for: knowing what to build, and noticing when it is wrong.
Note 4. Claws and Code instances: the ladder he is describing
Then comes the sentence most readers skip, because it is pure jargon:
"The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator Claws with all of the right tools, memory and instructions that productively manage multiple parallel Code instances for you."
"Claws" needs a footnote. Four days before this post, on 21 February, Karpathy had written about the always-on personal agents named after OpenClaw, an open-source project with a lobster mascot. He said they take "the orchestration, scheduling, context, tool calls and a kind of persistence to a next level," and called them "an awesome, exciting new layer of the AI stack." Simon Willison, who keeps a careful public log of these things, noted that "Claw" was becoming the general name for that kind of system: an agent that runs on your own hardware, talks to you through a messaging app, and can schedule its own tasks. "Code instances," capitalised, is my reading of sessions of coding agents such as Claude Code.
So the sentence describes a ladder. Each rung puts the human one level further from the code:
- You type the code yourself.
- A tool suggests the next line and you accept or reject it.
- You ask a chatbot and paste its answer in.
- One agent does a whole task, as in the DGX Spark weekend.
- Several agents work in parallel and you review their output.
- A long-running manager agent, the Claw, holds the tools, the memory and the instructions, and runs the parallel coding sessions for you. You manage the manager.
His three ingredients, "tools, memory and instructions," are the useful part, because they are concrete. When I look at my own working setup, I find all three already in place without my ever calling them a "Claw." The tools are a set of written procedures, one per kind of job: how to transcribe a song from a scanned score, how to pull a table of contents out of a scanned magazine, how to build a web page from a draft. The memory is the folder of notes from Note 2. The instructions are a standing rule book that every session reads first. On top of that sit one-word triggers: I type "next" and the assistant opens the progress table, takes the next unfinished item, does it, records the result and stops. That is about rung five and a half.
Here, though, my experience adds an asterisk to his "biggest prize." The top of the ladder is parallel agents. On 14 July 2026 I let four of them run at once on a large transcription job, splitting a songbook into parts. Together they used up the account's session allowance partway through. All four failed, two left nothing but stubs, and the whole job had to be redone by hand in a single sequential thread. My standing rules now forbid parallel helper agents for that kind of work. The ladder is real, but its top rungs assume a budget that a personal subscription does not have. Karpathy, to be fair, writes from a position where that ceiling is far away. Most readers do not.
He has his own asterisk on the same topic. In the 21 February post he wrote that he was "definitely a bit sus'd to run OpenClaw specifically," given its size and its access to everything on a machine, and he pointed to smaller alternatives such as NanoClaw, whose "core engine is ~4000 lines of code" and which "runs everything in containers by default." The man who called Claws the next layer was also the man reading the security notes before installing one.
Note 5. "Agentic engineering": why the name changed
The third paragraph ends with a phrase in quotation marks: "The leverage achievable via top tier 'agentic engineering' feels very high right now." The quotation marks are a clue that he is proposing a term, not using an established one.
A year earlier, on 2 February 2025, he had coined "vibe coding": "There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes" and forget that the code even exists. The phrase caught on so fast that Collins named it Word of the Year for 2025. But it described something specific: throwaway projects, where you do not read what the machine wrote and you do not much care.
On 4 February 2026, on the term's first birthday, he wrote a retrospective. LLM agents, he said, had become a default workflow for professionals, now used "with more oversight and scrutiny." He proposed a new name for that: "agentic engineering," where "agentic" means you orchestrate agents instead of writing most code yourself, and "engineering" is there "to emphasize that there is an art & science and expertise to it." The aim, in his words, is "to claim the leverage from the use of agents but without any compromise on the quality of the software."
The change of name is the argument. Vibe coding was a name for play. When the tools got good enough to use on work that matters, the playful name stopped fitting, and the old word came back: engineering, with its connotations of responsibility, testing and signing your name to the result. Someone still owns the outcome. The 25 February post uses the new term without explaining it, because he had explained it three weeks earlier.
Note 6. Six words: the human's job description
The fourth paragraph opens with a list that most quotations leave out: "It's not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas." Read as a list, it is a job description for the person who is left. Each word means something concrete:
| Word | What it looks like in practice |
|---|---|
| Direction | Deciding what the camera dashboard is for before an agent starts building it |
| Judgement | Treating the agent's "everything works" as a claim to check, not a fact |
| Taste | Rejecting a solution that works but is fragile, ugly or three times bigger than it needs to be |
| Oversight | Reading what it changed, above all anything touching passwords, deletion or money |
| Iteration | The second and third rounds: "now make it handle two cameras" |
| Hints and ideas | "Try the smaller model, it fits in memory": one sentence that saves twenty minutes |
The word I would underline twice is judgement. My own worst surprises with an assistant have not been code that crashed. They have been confident claims that were wrong. I once had it write a long book on a software topic, then checked every link afterwards. Every claim it took from a page it had actually opened held up. Every error, and there were several, came from a search-result summary that it had treated as a source. On another project it supplied a page number for a dictionary citation instead of opening the scan to look. Neither mistake announced itself. Judgement means knowing which kinds of statement the machine makes reliably and which kinds it only makes fluently.
Right after the list he gives the condition under which all this works best: tasks "that are well-specified and where you can verify/test functionality." That is not a passing remark. It is the same point he made at length in April: models improve fastest where answers can be checked automatically, because that is where they can be trained against right and wrong answers. Code that either passes its tests or does not is the ideal case. The further a job is from that ideal, the more of the six words land back on the human.
Note 7. "Decompose the task just right": the new core skill
The single most practical sentence in the post is this one: "The key is to build intuition to decompose the task just right to hand off the parts that work and help out around the edges."
Note the word intuition. He is not describing a rule; he is describing a skill you build by doing. Cut a job too large and the agent wanders, loses the thread, or runs out of room. Cut it too small and you are back to typing, with extra steps in between. Somewhere in the middle is a size the agent can finish and you can check.
I can only illustrate this from my own projects, because that is where I found the sizes by trial and error. Three rules came out of it.
A piece should end in something you can check. I had a magazine archive of 412 scanned issues and wanted each issue's table of contents as a table. The right unit turned out to be one issue in, one file out, written to disk the moment that issue was done. If a session is interrupted, at most one issue's work is lost, and anyone can open the file and check it against the scan.
The size gets tuned, not chosen once. On an old Chinese-character textbook, the batch started at two pages per run. Once the reading method had proved itself it went to five, and later to ten. Each increase came after the smaller size had been shown to work, not before.
Bound the search. Those magazine tables of contents are not always on the same page. An open-ended instruction, "find the contents page," burned through budget page after page. The fix was a fixed order: look at page 3, then page 7, then pages 11 to 17, and if it is not there, flag the issue and move on. A bounded task is one the agent can finish.
"Help out around the edges" then has a plain meaning: the human does the parts the agent cannot reach. In my case that has meant rescanning a page too faint to read, settling a disputed date from a composer's memoirs, or deciding what counts as finished. The agent does the long middle; the person holds the two ends.
Note 8. Who the post was written for: the view from the funnel
The post opens with a strange admission: "It is hard to communicate how much programming has changed." Why would one of the best communicators in the field find it hard?
Karpathy answered that himself later in the year. On 9 April 2026 he wrote that "there is a growing gap in understanding of AI capability": people judging AI by a free chatbot from a year ago, and people using paid coding agents on technical work, were talking past each other. On 11 October he returned to that post and sharpened it into what he called "a sharp funnel," with rough numbers. About six billion people, roughly three quarters of the world, have barely used a language model. One to two billion use free chatbots casually. About twenty million use frontier models professionally, mostly for code and mathematics, and have watched agents finish large projects. And at the narrow tip, he estimates around five thousand people have internal access to systems that have not been released.
He gave three reasons for the shape. Whether your problems are big and hard enough for the gain to show. Whether your field is digital, checkable and commercially valuable, which is where models are trained hardest. And whether you are using a free model, a paid one or an internal one.
Read the February post again with those three reasons in hand. The DGX Spark weekend scores on all three. The problem was large (a full service, not a question). The field was code, where everything can be tested. And he was using a top paid agent, with insider knowledge of the field. The post is a dispatch from the twenty-million layer, written by someone close to the five-thousand layer, and read mostly by people in the layers below. That is why it is "hard to communicate." The same sentence, that era is over, sounds like hype to someone whose only experience is a free chatbot getting a simple question wrong, like a threat to a junior programmer, and like old news to a lab insider.
There is a practical lesson in this for anyone who has to make decisions about these tools. Someone judging an AI product by a free chat session from last year is judging a different product. Someone who has never run the workload has no way to check a vendor's claims in either direction. The ability to judge AI progress accurately has itself become scarce. The honest move, if you are not in the layer that sees it, is to find someone who is before you decide.
One caution I owe the reader: the funnel numbers are Karpathy's own back-of-envelope estimates, and he presented them that way.
Note 9. What the post does not say
A post that travels this far gets stretched. A careful reading should mark where it ends.
It does not say programmers are obsolete. It says the job has changed and lists six things the human still has to supply.
It does not say agents work everywhere. "It works a lot better in some scenarios than others," and he names the scenarios: well specified, testable.
It does not say that general intelligence has arrived. Four months earlier, on Dwarkesh Patel's podcast in October 2025, he had pushed back on talk of "the year of agents": "In my mind, this is more accurately described as the decade of agents." In the same conversation he said of Claude and Codex, "I use daily," but "I still feel there's so much work to be done." The February post does not take that back. It reports one threshold crossed, in one domain, on the way through a long decade.
What it does say, flatly, is its last sentence: "this is nowhere near 'business as usual' time in software." Both halves of that are true at once: not finished, and not normal.
Closing: the pencil and the margin
Read quickly, Karpathy's post is a news item: coding agents got good. Read slowly, it is a small manual. The first paragraph explains why the change felt sudden. The second shows what a complete instruction looks like, including the odd new clause about leaving notes for your successor. The third names the ladder and the new trade, agentic engineering. The fourth, the part people skip, tells you what the person in the loop is for: direction, judgement, taste, oversight, iteration, hints, and above all the intuition to cut a job into pieces that can be handed over and checked.
That last skill is the one I would keep if I could keep only one. It cannot be outsourced, because cutting the job well requires understanding the job. In the old era the code proved you understood the problem. In the new one, the way you divide the work proves it.
References
- Andrej Karpathy, post on X, 25 February 2026; copy kept by Simon Willison, 26 February 2026.
- Simon Willison, Claws (link post quoting Karpathy), 21 February 2026.
- Andrej Karpathy, "agentic engineering" retrospective on X, 4 February 2026; discussed in Turing College, Agentic Engineering vs. Vibe Coding, 17 March 2026.
- Andrej Karpathy, "vibe coding" post on X, 2 February 2025.
- AFP via The Korea Times, 'Vibe coding' named Word of the Year by Collins Dictionary, 6 November 2025.
- Quote Investigator, The Hottest New Programming Language Is English, 20 October 2024 (Karpathy's post of 24 January 2023).
- METR, Measuring AI Ability to Complete Long Software Tasks, 19 March 2025.
- Nvidia, DGX Spark hardware overview.
- vLLM project, vLLM on GitHub.
- Qwen team, Qwen3-VL on GitHub.
- Andrej Karpathy, capability-funnel update on X, 11 October 2026, quoting his post of 9 April 2026; Spanish-language summary in Ecosistema Startup, Karpathy: la brecha de la IA tiene 4 niveles y crece, 11 October 2026.
- Dwarkesh Patel, Andrej Karpathy — AGI is still a decade away, Dwarkesh Podcast, 17 October 2025.
No comments:
Post a Comment