Your Engineers Feel Faster With AI. Measure It Before You Plan On It.

Say a senior engineer costs you £90,000 a year all in, and your team tells you AI has made them about 20% faster. On a team of five, that’s the case for not making the next hire, so you’ve got a £90,000 decision resting on how fast people feel.

That’s a decision I’d want measured first. The best evidence we have says the feeling of speed and actual speed can sit a long way apart, and in the best-known trial, the people doing the work couldn’t tell.

The 19% figure is out of date

In early 2025, METR, a research group that tests AI systems, ran a proper trial. They took 16 experienced open-source developers and 246 real tasks from projects they’d worked on for years, and randomly allowed or banned AI on each task. Before starting, the developers expected AI to speed them up by 24%. Afterwards, they believed it had sped them up by 20%. The measurement said they’d taken 19% longer.

That 19% went everywhere, and it’s still going. One AI coding vendor’s guide, last updated in June 2026, still calls it “the measured 19% productivity decline”. But METR’s own page for the study now opens by saying the results are out of date, and their February 2026 follow-up says developers were probably getting more out of early-2026 tools than they did then.

So if someone quotes 19% at you as proof that AI slows engineers down today, it describes early-2025 tools, and METR has said so. What’s still useful is that the same developers felt 20% faster while being 19% slower. METR puts that at a 40-point overestimate, and the developers didn’t notice.

Nobody has a clean number yet

The follow-up doesn’t give you a better figure to plan with, and METR says so. Their late-2025 run covered 57 developers and over 800 tasks. For newly recruited developers, tasks took about 4% less time with AI, but the range ran from 15% less time to 9% more. Returning developers came out at 18% less time, with an even wider range. Neither is narrow enough to plan a hire around.

It’s shaky for a reason that matters to you. Between 30% and 50% of the developers they surveyed said they’d chosen not to put some tasks into the study, because they didn’t want to do them without AI, and more developers than before turned the study down, mostly for the same reason. So the people and tasks likely to show the biggest gains are the ones missing from the study, and METR treats its own result as a lower bound.

Put together, AI probably helps more than it did in early 2025, but nobody can tell you by how much for your team. That includes your team’s own estimate.

Why it feels faster than it is

METR’s May 2026 survey of 349 technical workers, about a quarter of them software engineers, puts numbers on the feeling. The median person said AI made them 3 times faster. Asked about the value of their work rather than its speed, the median answers to three questions came out between 1.4 and 2 times. Both sets of numbers are people’s own estimates, so the gap is between two feelings, and speed is the one that runs ahead.

One explanation METR puts forward is the part I’d take to a hiring decision. When AI makes a kind of task cheap, people do more of it. Speed goes up on the work AI is good at, and that isn’t always the work that mattered. In their words, people may be “substituting into lower-value tasks”.

On an engineering team, that could look like a lot of small things getting closed, like tidy-ups, tests, scripts and docs. That’s real work, and it feels like momentum. Whether the feature your customers are waiting for shipped any sooner is a different question, and it’s the one your plan depends on.

What to measure instead

You can do this without a research trial. You need last quarter’s numbers, which you already have, six weeks of the same numbers going forward, and to stop asking people how much faster they feel. This is what I’d set up:

1. Pick one unit of work your customers notice. That could be a shipped feature, a fixed customer-reported bug or a release. Don’t use tickets closed, because that’s the number most likely to rise on small work.
2. Take the baseline from your tracker. Pull last quarter’s start-to-shipped time for that unit from the status-change history. Jira and Linear both keep it, so nobody has to fill anything in.
3. Watch the same number for six weeks. Keep the definition fixed, and don’t change the team or the process in the same window, or you won’t know what moved it.

This won’t prove what caused a change, because the work shifts from quarter to quarter, but it’s a real number about your team, which is more than the feeling gives you. Then read the result. If time-to-ship has dropped and the mix of work looks similar, that’s a speedup you can start planning on, sized to what you saw. If it’s flat while everyone feels faster, the extra speed probably isn’t reaching customers yet, and that’s a prioritisation conversation rather than a tooling one. If it’s got worse, look at code review first, because that’s often where AI-written code waits for a person.

It’s the same move as choosing a model: test on your own work, not on a number someone else measured on theirs.

Your team’s sense of speed is worth listening to, but it isn’t a number to hire against.

If you’d like a hand setting the measurement up, or reading what it tells you, book a call.