There's a counterintuitive finding circulating among software engineers: the tool that makes them feel faster is actually making them slower. Studies done over the past couple of years suggest engineers believe AI coding assistants speed them up by about 20% — while actually slowing them down by roughly 19%.

As one account of the research puts it:

"It's like people think they're faster because AI is writing some or all of the code, but it's actually slower because they're fixing a lot of mistakes and they're dealing with slop."

The mechanism is worth understanding, because it generalizes beyond programming. An AI assistant produces output quickly, and producing output feels like progress. Watching code appear on screen is satisfying in a way that carefully checking it afterward is not. But the work isn't done when the draft arrives — it's done when the draft is correct. If the assistant's output contains mistakes, someone has to find them, understand them, and fix them. That correction work is slower and more tedious than the writing it replaces, and it's easy to not count it because it doesn't feel like "the task" anymore.

This is sometimes called a productivity mirage: the felt sense of speed comes from the visible part (generation) while the cost hides in the invisible part (verification and repair). For coding specifically, the claim is that the net effect is negative — engineers end up behind where they started.

Who this is for. Honestly, the finding itself is about developers. If you don't write code and don't manage people who do, the specific numbers — 20% faster-feeling, 19% slower in reality — aren't about your work. What transfers is the warning: any AI tool that produces drafts faster than you can produce them yourself will feel like a speedup regardless of whether it is one. The only way to know is to measure outcomes, not vibes — total time to a finished, correct result, including the time you spent untangling the assistant's errors.

If you manage developers or work alongside them, this is directly relevant. A team reporting that AI assistants make them faster may be reporting the feeling, not the measurement. The studies suggest the two can point in opposite directions at once. It's also relevant if you're deciding whether to push these tools on a team: the pitch that they make engineers faster is, at minimum, contested by research.

Is this settled science? No. These are studies finding an average effect, and averages conceal a lot — some engineers surely do get faster, particularly those with a disciplined way of working with the tools. The studies don't, at least in the account above, specify which assistants were tested or how experienced the engineers were. And the research describes a problem, not a fix: it suggests the losses come from unstructured use — accepting generated code and then mopping up — rather than showing that no workflow can beat the baseline.

The practical takeaway isn't "don't use AI assistants." It's that the feeling of speed is not evidence of speed. If you find yourself regularly correcting an assistant's output, it's worth timing the whole loop — prompt, generation, review, repair — and comparing it honestly to doing the task yourself. That comparison, not the sensation of watching text appear, is the real measure.