Speed Beats Mastery

Mastery is a lagging indicator of reps. The fastest way to get good is to ship more, sooner, and learn in public.

AI makes that idea more powerful and more dangerous at the same time. It lets you take far more reps, but it also makes it surprisingly easy to feel fast while getting slower. The research on this is some of the most interesting in software right now.

The case for AI speed

In 2023, researchers from Microsoft, GitHub, and MIT ran a controlled experiment: developers were asked to build an HTTP server in JavaScript as fast as they could. The group with GitHub Copilot averaged about 71 minutes. The group without it averaged about 161 minutes. That is 55.8% less time for the same task.

Two caveats worth knowing: GitHub staff were among the authors, and the task was small, well defined, and greenfield. That is exactly the kind of work AI is best at.

The case against

In 2025, the research group METR ran a randomized trial with a very different setup: 16 experienced open-source developers working on 246 real tasks in large codebases they already knew well. Each task was randomly assigned to allow or forbid AI tools.

The result: with AI, the developers took 19% longer.

The most striking part is the perception gap. Before the study, the developers expected AI to make them 24% faster. After it, they still believed it had made them 20% faster. They were measurably slower and felt faster the whole time.

The story did not stop there. When METR ran a follow-up, it had to change the experiment's design because a growing share of developers would not agree to do half their work without AI, even when paid $50 an hour to work on tasks of their own choosing. METR now says its late-2025 data likely understates how much AI helps. In other words, the tools improved fast enough that developers increasingly refused to work without them.

What both studies are really saying

These results are not actually in conflict. They are measuring different kinds of work.

• Clear, self-contained tasks: AI is a huge accelerator. The Copilot experiment is this case.
• Deep work in a big codebase you already know: the time spent prompting, waiting, reviewing, and correcting can eat the gains. The METR trial is this case.
• In both cases, your gut is a bad stopwatch. If experienced developers misjudged their own speed by almost 40 percentage points, so can you and I.

What "fast" should mean now

So here is how I think about speed in the AI era:

• Measure cycle time, not typing time. The question is not "how fast did code appear?" It is "how fast did a working change reach a real user?"
• Cut scope until it is almost embarrassing, then ship. Agents make it tempting to build more. Resist. Smaller releases mean faster feedback.
• Use AI where it is strong. Greenfield features, boilerplate, tests, and migrations: let the agent run. Subtle changes to a system you know deeply: often faster to just write it.
• Review like it matters, because it does. The mastery that still counts is judgment: knowing what to build, spotting what the model got wrong, and deciding when good enough is good enough.
• Set a cadence and let it force decisions. A weekly ship date settles more debates than any planning doc.
• Treat every release as a question, not a verdict. Ship, watch what happens, adjust.

Speed is a learning rate

The point of moving fast was never to type faster. It is to learn faster: more experiments, more feedback, more reps. AI can multiply your reps, but only if you are honest about which ones actually moved you forward. Ship more, measure what really happened, and let mastery show up the way it always has: as the result of a lot of reps, done in public.

Sources

• Peng, Kalliamvakou, Cihon & Demirer (2023), "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv:2302.06590
• METR (July 2025), "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
• METR (February 2026), "We are Changing our Developer Productivity Experiment Design"