A controlled study by [METR](https://secondthoughts.ai/p/ai-coding-slowdown) took experienced open source developers, people who already knew their repositories inside out, and measured how long they took to resolve real GitHub issues with and without an AI assistant. The result was the opposite of what everyone expected: they were about 19% slower when using AI. The most interesting detail isn't even that number, it's that before starting each task the developers themselves predicted they'd be faster with the tool. Expectation and reality collided head on, and that alone says a lot about how we tend to judge these tools day to day. It's worth separating two phases we usually lump together as one thing. Writing code and debugging code are different cognitive tasks, and AI helps far more with the first than with the second. Typing out boilerplate, generating a simple function, scaffolding a component, AI handles that fast and well. The problem shows up later, when something breaks. A [post on DEV Community](https://dev.to/harsh2644/i-spent-10x-longer-debugging-ai-code-than-writing-it-15h4) describes this in a way anyone who's ever pasted AI code into a real project will recognize: three hours tracing a bug that should've taken ten minutes, because the code was generated in thirty seconds but nobody ever built the mental model of why it works the way it does. It's like coming back to code you've never seen, except you're supposedly the one who wrote it. That mental model gap is probably the actual mechanism behind the slowdown, not just a side effect. When you write a function yourself, even slowly, you carry the reasoning behind every decision in your head. When AI writes it, that reasoning never existed on your end, so every bug means rebuilding that understanding before you can even start hunting for the error. There's also a cost that never shows up on a stopwatch: after a few too many "works on my machine" moments that meant nothing, trust in your own code drops, and that's when the extra logging, the redundant tests, the validation nobody asked for start creeping in, all because you can't fully vouch for something you didn't write. A [Programming Insider article](https://programminginsider.com/the-ai-debugging-paradox-why-coding-assistants-can-make-you-slower-and-what-to-do-about-it/) sums this up well, pointing out that when you add up the full workflow, teams ended up roughly 20% slower at debugging with AI enabled. Their conclusion is blunt: AI speeds up typing, not understanding, and debugging is fundamentally about understanding. Not everyone feels this the same way, and that's maybe the most useful part for anyone reading this while thinking about applying it at work. Research cited by [McKinsey](https://www.mexc.com/news/280661) found junior developers taking 7 to 10% longer with the tools than without, which tracks: whoever has less experience to judge whether a generated snippet is actually correct or just looks correct ends up paying more later, when it's time to figure out why it isn't. The [2025 Stack Overflow survey](https://www.mexc.com/news/280661) calls this the "debugging tax," the price paid afterward for the speed gained upfront. A [Microsoft study](https://www.techradar.com/pro/microsoft-study-claims-ai-is-still-struggling-to-debug-software) reinforces this from another angle, showing that the language models themselves still aren't particularly good at diagnosing bugs, even the ones built by the biggest players in the field. None of this means AI for code is worthless. The distinction the data points to is more subtle: on small, well defined tasks with little accumulated context, AI pays off, and pays off well. It's on tasks with complex logic, integration across different parts of a system, state bugs that only show up in production, where the math turns negative. Maybe the right question isn't whether AI speeds things up or slows them down, but at which point in the work it actually helps, and at which point it just pushes the cost further down the line, disguised as productivity.