Ask any developer who's switched to Cursor whether it's made them faster, and you'll almost always get the same answer: yes, obviously, why are you even asking.

That's not a knock on anyone. It genuinely feels faster. You type three words, hit tab, and a chunk of boilerplate you'd have spent ten minutes writing just appears. Of course that feels like a win.

Except when researchers actually sat down and measured it, instead of just asking people how they felt, the results didn't match the feeling. Not even close.

What developers expect vs. what they report

Before a widely cited 2025 study even started, the participating developers were asked to predict how much faster AI tools would make them. Their average guess: about 24% faster. Reasonable expectation, given the hype.

After finishing their tasks, they were asked again, this time about what they thought had actually happened. Their answer: still roughly 20% faster. Close to their prediction. Confidence intact.

Here's the problem. That's not what the clock said.

The study that measured the actual clock

The research, run by METR in mid-2025, took a different approach than most AI productivity claims you see floating around. Instead of surveying people about their impressions, it recruited experienced open-source developers — people with years of history on large, real codebases — and had them complete real issues from their own repositories. Bug fixes, features, refactors. Nothing synthetic.

Each task was randomly assigned to either allow AI tools (mostly Cursor, paired with Claude) or not. Same people, same kind of work, real random assignment — about as close to a controlled experiment as you get in this field.

The result: developers using AI took about 19% longer to finish their tasks. Not faster. Slower. And this was after they'd already spent dozens of hours getting comfortable with the tools, so it wasn't just an unfamiliarity tax.

What makes this genuinely interesting, rather than just a "gotcha" headline, is where the time went. Coding time itself did drop. So did time spent researching and testing. That part matched the intuition — the AI really was doing some of that work. But all of those savings got eaten, and then some, by time spent writing prompts, waiting for responses, and reviewing what the AI had produced. Add in a bit of extra friction navigating the IDE with an assistant running, and the net result flipped from "faster" to "slower."

It's worth being fair to the other side of this too. This isn't a case of "AI coding tools don't work." Cursor's own internal research, looking at teams that adopted their agent as a default part of the workflow, found a 39% increase in the number of pull requests merged. A separate case study out of Salesforce's engineering team described cutting the time needed to bring legacy code up to test coverage standards from 26 engineer-days down to 4, on some fairly large repositories.

So which is it? Faster or slower?

Honestly — both, depending on the team, the task, and how the tool gets used. Which is exactly why "I feel faster" isn't a great way to answer that question for your team.

Why the feeling and the reality drift apart

The gap isn't really a mystery once you look at where the METR study found the extra time going. Prompting, waiting, and reviewing AI output don't register the same way in your head as "doing work." They feel like small interruptions, not real time spent. Actively writing code, on the other hand, registers heavily — every minute of it feels earned and effortful.

So if AI cuts your active coding time in half but adds a pile of smaller waiting-and-reviewing moments scattered throughout your day, your brain tends to remember the relief of less typing far more vividly than it tracks the accumulated minutes lost elsewhere. That's not a character flaw. It's just how time perception works when the work changes shape.

Self-reported productivity, in other words, is measuring how the work felt, not how long it took. Those are different things, and the difference is exactly where all the disagreement in this debate lives.

How to actually find out, instead of guessing

You don't need a research grant to answer this for your own team — you need actual time data, tracked automatically, across the tools you already use.

A few things worth looking at if you want a real answer rather than a vibe:

1. Compare like-for-like tasks. Look at time spent on similar categories of work (bug fixes, feature work, code review) before and after adopting an AI assistant, rather than eyeballing "this sprint felt smoother."
2. Track time per project, not just per day. Aggregate daily numbers hide a lot. If a project's total hours barely moved after adopting Cursor, that's a much more honest signal than anyone's gut feeling.
3. Watch the full picture, not just "coding time." As the METR results show, the interesting time sink usually isn't the coding itself — it's everything wrapped around it.

This is the exact gap JustClock is built to close. It runs quietly in the background across IntelliJ IDEA and the rest of the JetBrains family, VS Code, Cursor, and Devin, logging real project time without you having to remember to start a stopwatch — or trust your own memory of how the week went. If you're trying to figure out whether an AI coding assistant is actually paying for itself on your team, that's the only way to get an answer you can trust over your own impression of it.

Key takeaways

1. Developers consistently predict and later report feeling faster with AI coding tools like Cursor — typically around 20-24%.
2. A controlled 2025 study found the opposite in practice: experienced developers were about 19% slower with AI assistance, even after significant hands-on experience with the tool.
3. The lost time wasn't in coding — it went into prompting, waiting on responses, and reviewing AI-generated output, all of which feel less like "work" than typing does.
4. Other studies show real gains in specific contexts (more PRs merged, faster legacy test coverage), so the honest answer is "it depends on the task and the team."
5. The only reliable way to know which camp you're in is to measure it directly, rather than trust how the week felt.

Sources

1. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
2. arXiv — Study preprint (2507.09089)
3. Cursor — The productivity impact of coding agents
4. Salesforce Engineering — How Cursor AI Cut Legacy Code Coverage Time by 85%