The AI Coding Paradox: Why Developers Are 19% Slower With AI (And Think They're Faster)

Introduction

What if the tool you rely on every day is actually making you slower, and you have no idea? That is exactly what a landmark study by METR, a respected AI research organization, found when they put AI coding tools to a rigorous scientific test.

The headline result: experienced open-source developers completed tasks <strong>19% slower</strong> when using AI tools like Cursor and GitHub Copilot. The kicker? Those same developers <strong>believed they were 20% faster</strong>. That is a 39-point gap between perception and reality, and it has massive implications for how teams adopt AI tooling.

At MG Software, we use AI coding tools daily. We build with Cursor, deploy with AI-assisted workflows, and recommend these tools to clients. So when a study says "AI makes you slower," we take it seriously. Here is what the data actually shows, and what it means for your business.

What METR Actually Tested

METR recruited 16 experienced developers from major open-source repositories, projects averaging 22,000+ GitHub stars and over a million lines of code. These were not beginners. They had an average of 5 years working on their specific projects.

Each developer completed 246 real tasks from their own repositories, randomly assigned to either allow or disallow AI tools. When AI was permitted, developers primarily used Cursor Pro with Claude 3.5 and 3.7 Sonnet, the frontier models at the time of the study (February through June 2025), since retired in favour of Claude Opus 4.6 and Sonnet 4.6. For a deeper look at how these tools compare, see our Cursor vs Claude Code comparison.

This matters because the study tested AI tools in their strongest possible context: experienced developers on familiar codebases using the best available AI models. If AI tools were going to shine anywhere, it would be here.

The 39-Point Perception Gap

"Developers predicted AI would reduce their completion time by 24%. The actual measurement showed they were 19% slower."

— METR AI Coding Study, 2025

The most striking finding is not the slowdown itself: nobody noticed it. Before the study, developers predicted AI would reduce their completion time by 24%. After using the tools, they estimated they had been 20% faster. The actual measurement showed they were 19% slower. The full results are published in METR's open-source developer study.

Why the disconnect? The researchers identified several factors. AI tools provide a sense of progress: you see code appearing on screen faster, which creates an illusion of velocity. But that initial speed comes at a cost: more time spent reviewing, debugging, and correcting AI-generated suggestions. The net effect is negative.

There is also a sunk-cost dynamic. Once you have spent time crafting a prompt and waiting for a response, you are psychologically invested in using the output, even when rewriting from scratch would be faster. We have caught ourselves doing this at MG Software, and recognizing the pattern was the first step to fixing it.

Why Experienced Developers Slow Down Most

Here is the counterintuitive insight: the more you know a codebase, the less AI helps you navigate it. Experienced developers already have a mental model of the architecture, the conventions, and the edge cases. AI suggestions often conflict with that knowledge, requiring extra cognitive effort to evaluate and correct.

For tasks requiring deep architectural understanding, such as refactoring complex modules, fixing subtle race conditions, or designing new APIs, AI-generated code frequently misses the context that a seasoned developer carries implicitly. The developer then spends time fixing AI suggestions instead of just writing the code themselves.

This does <strong>not</strong> mean AI tools are useless. It means their value proposition differs by context. For unfamiliar codebases, boilerplate generation, and exploratory prototyping, AI excels. For deep work on code you already understand intimately, it can be a distraction.

What This Means for Your Engineering Team

If you are a CTO or engineering manager considering AI tool adoption, the METR study does not say "do not use AI." It says "be strategic about when and how you use it." Here is what we recommend based on both the research and our own experience at MG Software.

First, stop measuring AI ROI by "lines of code generated." That metric is worse than useless. It actively misleads. Measure by feature completion time, bug introduction rate, and developer satisfaction instead.

Second, create explicit guidelines for when to use AI and when to go manual. Greenfield development, writing tests, generating boilerplate, and exploring unfamiliar APIs. These are high-value AI use cases. Complex refactors, security-critical code, and performance optimization. These often benefit from unassisted focus. For a full landscape of available AI tools, explore our best AI coding assistants overview. And if you are evaluating editors specifically, our Cursor alternatives guide compares the leading options.

Third, invest in AI tool training. The developers who benefited most from AI tools in various studies were not the ones who accepted every suggestion. They were the ones who knew when to reject suggestions quickly and move on. That skill requires practice.

How We Use AI at MG Software

We are not abandoning AI tools. Far from it. But the METR study validated something we had already noticed: AI works best as an accelerator for specific tasks, not as a general-purpose speed boost.

Our internal workflow uses Cursor extensively for scaffolding new components, writing unit tests, and generating API client code. For these tasks, we consistently see 30-50% time savings. But for architectural decisions, code review, and debugging production issues, we rely on human expertise. If you are evaluating AI-powered editors, see our comparison of the best IDE and code editors in 2026.

The key insight is that AI tools amplify your existing workflow. They do not replace it. If your development process is well-structured, AI makes it faster. If it is chaotic, AI makes it chaotically faster, which is worse. Invest in your engineering practices first, then layer AI on top.

If you are looking to adopt AI tools effectively in your development team, let us talk. We have learned these lessons the hard way so you do not have to.

Conclusion

The METR study is a wake-up call, but not the kind most headlines suggest. It does not prove AI coding tools are bad. It proves we are bad at measuring their impact. The 39-point perception gap should concern every engineering leader who is making investment decisions based on developer self-reports.

The real question is not "should we use AI tools?" The real question is whether we are using them in the right contexts. At MG Software, we believe the answer requires both data and experience. We are committed to sharing what works and what does not as the technology evolves.