Why does AI make you feel fast and finish slow

In 2025, a research group called METR ran the kind of study this field almost never gets: a proper randomized controlled trial, the sort medicine runs before approving a drug. They took sixteen experienced developers, people with years of history in large, mature codebases they knew well, and gave them real tasks from their own repositories. Some tasks they did with AI tools allowed. Some without. Then they measured the time.

The developers were 19% slower with AI.

Not a little faster. Slower. And the same developers, afterward, were sure the AI had made them about 20% faster. Before they started, they'd predicted 24% faster. They felt a speedup the clock says never happened.

The honest caveats matter, and the real lesson is hiding inside them. This was a narrow setting: experts, on code they already knew by heart, using the tools of early 2025. The range on the result was wide. METR themselves now call the exact figure historical, and today's tools are better. If you want a reason to dismiss the whole thing, you can find one.

But the part worth keeping was never the 19%. It's the gap. Skilled people, reporting honestly, were off by nearly forty points between what they felt and what actually happened. That gap doesn't close when the tools get better, because it was never about the tools. It's about where the work went, and why you can't feel it move.

Writing code was never most of the job

When you build a feature, you're doing five different things, and only one of them is typing.

You work out what the problem actually is. You decide how to solve it, out of the several ways you could. You write the code. You check that it's correct. And you fit it into a system that already exists, with its own rules and history.

Writing the code is the part everyone pictures when they picture programming. On any serious work, it's also the smallest part. The understanding, the deciding, the checking, the fitting: that's the bulk of the job, and it always was. We just never separated it out, because inside one person's head it all blurred together into "coding."

AI is very good at exactly one of those five things. It writes code. It does almost nothing for the other four. And one of them, it makes harder.

Checking that code is correct is harder when you didn't write it. Write something yourself and you build the understanding as you go; by the time it's done, you know why every piece is there, because you put it there. Get it from an agent and you have the finished result with none of that understanding, so you have to rebuild it backwards. What was this meant to do? Does it do that? What did it decide that I never asked for? You're doing the understanding after the fact, from the outside, on code that looks confident and may be quietly wrong. That's slower than checking your own work. It's one of the most common complaints about AI code: that it's almost right, which is the most expensive kind of wrong, because a plausible mistake takes longer to catch than an obvious one.

This is where the time actually goes. You get a feature in twenty minutes that used to take a morning, then spend the afternoon reading it, testing the edge case it probably skipped, and tracing how it touches everything it's wired into. The typing collapsed. The understanding, deciding, checking, and fitting did not. They moved to later in your day.

Why you can't feel the work move

The part that got fast is the part you can see. Code appears on the screen, quickly, in response to a sentence you typed. It's visible and immediate, and your brain files it as progress.

The parts that stayed slow are invisible. Understanding a problem looks like staring. Deciding an approach looks like nothing. Checking correctness looks like reading the same thing three times with a low sense of doubt. None of it gives you the feeling of having done something, so your brain barely counts it. When you look back on the day, you remember the feature appearing, not the two hours of checking that followed.

The study measured this on the screen recordings. The AI-assisted sessions had more idle time, and not just time spent waiting for the model. Real, no-activity time. The thinking didn't go away. It got heavier and quieter and stopped looking like work.

So you finish the day believing you were faster, because the part you can feel was faster. The clock is timing the whole thing. You were only timing the part that felt good.

Whether AI saves you time depends on what your work is made of

This is also why the "AI makes everyone ten times faster" people and the "AI is useless" people are both wrong.

A beginner building a fresh project gets a huge, real win, and the five parts show why. There's no existing system to fit into. The stakes are low, so checking is quick. They couldn't have written the code fast themselves, so the typing AI hands them is enormous. Almost all of their work is the part AI is great at. They're not imagining the speedup.

An experienced developer on a real system gets the opposite mix. The code was already the easy part, so making it faster saves the least. The deciding is high-stakes, the checking is not optional, and fitting the change into an existing system is most of the difficulty. They spend the day in the four areas AI doesn't help with, while it speeds up the one they were already fast at and adds review on top. That's why the study found experienced people slower. The more real your work is, the smaller the slice of it AI actually changes.

It moves at the team level too. A 2026 study from Faros found teams using AI produced far more: more tasks finished, nearly twice the pull requests. Their organizations still weren't shipping any faster. The extra output piled up downstream, in review and integration and the slow work of making fast-written pieces fit together. The time didn't vanish there either. It moved to a different desk.

What to do about it

Once you see that the work moved, the move is to stop optimizing the part that's already free and start managing the parts that got expensive. Four things.

Decide before you generate. The trap is to generate first and think later, which leaves you verifying a solution to a problem you hadn't finished understanding. Do the thinking while it's cheap, in your head, before any code exists. Settle the approach, then have the agent build that specific thing. A decision made up front turns checking from "is this right?" into "did it do what I decided?", which is a much faster question.

Know what "done" looks like before you start. Most of the afternoon goes into open-ended checking with no finish line, where you keep poking because you're not sure what would make you confident. Decide that in advance. What has to be true for this to be correct and safe to ship? Write it down. Now checking is a list you can finish.

Get your context in front of the agent. A lot of the "what was this supposed to do" overhead comes from the agent guessing at things your system already knows. The more it works from your real rules and constraints, the less of your day goes to untangling its guesses.

Treat reviewing the agent's code as the job, not an interruption to it. The work moved here. Waving code through so you can keep feeling fast is how the subtle bugs ship. Get good at the thing that has quietly become the bottleneck.

None of this is about typing faster. The typing is already free. It's about making the newly expensive parts cheaper, on purpose.

Where that leaves you

AI didn't make developers obsolete, and it didn't make them ten times faster. It took the one part of the job that was visible and mechanical and made it nearly free. In doing that, it shifted the weight onto the parts that were always the hard ones: deciding well, understanding deeply, verifying honestly, and fitting things into a system that already exists.

That isn't a worse deal. For a lot of people it's a better one, because those were the interesting parts. But it's a different job than the demos sell, and it rewards a different skill: not how fast you produce code, but how well you direct, judge, and verify code that gets produced for you.

The people who are actually fast are the ones who noticed the work move and rebuilt their approach around the new expensive parts, instead of celebrating the free one. Turning a heap of fast, chaotic AI output into something you can trust and ship is most of what working with agents on real software now is. That's the shift this whole piece has been about, and it's exactly what we built the Agentic Engineering course around: not the typing AI made free, but the parts it didn't touch, deciding what to build, catching the agent when it's confidently wrong, and doing it inside a real codebase instead of a clean demo. Start to finish, the way the job actually works now.

The time you thought you saved didn't disappear. It moved somewhere you weren't looking.