Sustainable Velocity #1: even Karpathy feels behind

On 26 December 2025 Andrej Karpathy — who trained networks at OpenAI and Tesla, and wrote the course half the field learned transformers from — posted that he has "never felt this much behind" as a programmer. The Hacker News thread collected 549 points and around six hundred comments. People recognised themselves in it.

This is the first issue of a series about working pace. Its claim is simple and testable: feeling behind is a property of the era and of how you measure, not a personal defect.

One note on sourcing before the numbers: Karpathy's post sits behind a login wall on X, so the wording above is taken from the Hacker News thread title rather than the original.

The stopwatch disagrees with the feeling by 39 points

In July 2025, METR ran the measurement instead of the argument. Sixteen experienced developers, 246 tasks in large open repositories — above 22,000 stars, above a million lines.

With access to AI tools, they completed those tasks 19% slower.

Before the experiment they expected a 24% speed-up. Afterwards, having lived through it, they still believed they had been 20% faster.

That is a 39-percentage-point gap between the feeling and the clock, on experienced people working in code they already knew. Deciding you are the exception, without your own measurement, has nothing to stand on.

The acceleration is real — in lanes

The same METR, in August 2026, looked at where discovery actually sped up.

Vulnerabilities. cURL went from 9 CVEs in all of 2025 to 36 by 24 June 2026, fifteen of them flagged as AI-found. OpenSSL went from 6 to 39 by 5 August, with 18 confirmed AI findings and 9 related ones.

Mathematics. Three problems from lists that already existed were closed with AI in 2026: the Jacobian conjecture from Smale's list, problem 44 from Green's list, and the sofic half of his problem 100.

And where it did not speed up: seven algorithmic optimisation benchmarks — CIFAR-10, Hutter Prize compression, Gurobi MIP, MIPLIB, nanoGPT, Stockfish, the matrix multiplication exponent. METR's wording is flat: not one of them shows a clear change in slope comparable to vulnerabilities and mathematics.

There is a control figure inside their own note. Microsoft's CVE count grew from 1243 to 1927, but only 26 of those — 1.3% carry an AI-found label. That is a process growing, not a method jumping.

METR attach a caveat that belongs next to every number above: "Data collection and analysis were performed by agents. We tried to verify the results, but errors likely remain."

One test tells you which lane you are in

Look at what separates the two groups. A vulnerability is verified by reproducing it. A proof is verified formally. Both are cheap and automatic to check, and both show the jump.

Algorithmic optimisation is verified expensively, by eye and by argument. No slope change on any of seven benchmarks.

So the question is not "why am I slower than the timeline". It is: can the result of my work be checked cheaply and automatically? Where the answer is yes, agents give you throughput and it is worth spending on volume. Where it is no, do not expect the jump — and do not read its absence as falling behind.

The bottleneck moved into review

This is the part you feel in your body.

The Pragmatic Engineer, 8 September 2026: by GitHub's data, open pull requests are up fivefold in three years, and since late 2025 PRs and commits have nearly doubled. The question CTOs bring is no longer "how do we write faster" but "what do we do with the review load".

Writing code got cheaper. Reviewing it did not, and a fivefold increase lands on the same number of people.

Four review modes are actually in use: a human reviews the agent's review rather than the code; sorting by blast radius, as OpenAI and Anthropic do; reviewing the plan, the tests and the database schema instead of the implementation; and forcing smaller PRs. Dropping human review altogether is discussed far more often than it is done.

You are comparing yourself to claims, not measurements

Cohere Labs assembled the ATE corpus: 696,291 tools across 123,069 public MCP servers, collected from seven directories in May 2026 and published on 3 September.

The test is strict — can the tool itself carry an occupational task from the US Department of Labor's O*NET handbook through to the end, rather than help a human do it?

2.6% clear the bar. For 419 of 923 occupations there is no agentic activity in public catalogues at all. The authors call 2.6% a lower bound, since corporate MCP servers are not published.

Hold those two numbers side by side: 696,291 tools in the catalogues, 2.6% that finish the job. Then hold the other pair: a felt 20% speed-up against a measured 19% slowdown. As long as you measure yourself against the feed, you are measuring yourself against the upper bound of other people's claims.

What your own measurement looks like

On 3 September 2026 Austin Griffith of BuidlGuidl ran ten coding agents down the same course of twelve Solidity security challenges — the course originally built for humans at Devcon.

Codex on GPT-5.5 took all three podium places. The interesting part is inside them: the medium reasoning level cleared all twelve flags fastest (40:07), while extra-high came last of the three (50:26) and burned nearly a third more tokens.

Fourth place is more interesting than the podium. DeepSeek V4 Pro took 11 flags for $1.45; Claude Opus 4.8 took 10 for $7.61.

The organisers label their own run honestly: "a transparent single-run evaluation, not a universal model ranking". That is exactly why it is worth copying rather than citing — the value is in having run it on your own course.

What to do this week

1. Name your lane with one question: can the result be checked cheaply and automatically? Test, reproduction, formal check — agents will give you speed, and it is worth spending on volume. Expensive and manual — do not wait for a jump, and do not measure yourself by somebody else's pace.
2. Build your own eval set of 10–12 tasks from your domain and run it the day a new model ships. Griffith's course was made of tasks written for humans; yours can be too. A public leaderboard answers "which model is better in general". You need "which is better on my code".
3. Measure two weeks with a stopwatch, not a feeling. Task type, time, agent or no agent. The 39-point gap was measured on experienced developers in familiar repositories.
4. Pick one review mode and write it down as a team norm — one of the four above. A norm, not a habit: without it the review load redistributes itself silently.
5. Check whether you need "more reasoning" at all. On Griffith's course the medium level beat extra-high on both time and tokens, and an open model at $1.45 took one more flag than a closed one at $7.61.

One thing to do today: take the last task you did with an agent and write down three numbers — how long it took, how long it would honestly have taken by hand, and how you verified the result. The third number is your lane.

We hold this measure on ourselves

Our studio's working folder is seven projects run by a Claude Code session, and the lane shows up there by exactly the same test.

Classifying the collector's output is cheap to verify: 470 items from nine days were labelled in a single pass, and the calibration held — the top band came out at 3.0% against a 2.4–3.5% norm, so the scale had not drifted.

Extracting meaning from other people's discussions is expensive to verify. There, 628 threads honestly cost ten or eleven sittings, and no agent compresses that.

We sped up the first and not the second, and the record of it lives in a tracker rather than in a feeling.