{"slug": "why-ai-isnt-making-developers-10x-faster-and-what-actually-works", "title": "Why AI Isn’t Making Developers 10x Faster (And What Actually Works)", "summary": "A controlled study by a model evaluation organization found that open source developers using AI coding tools were 20% less productive despite believing they were 20% faster. The gains from AI-assisted coding are absorbed by other phases of the software development lifecycle, such as waiting on product teams, QA, and operations, preventing overall productivity improvements.", "body_md": "When I talk to fellow developers, a lot of folks are worried about how AI might take their jobs. Maybe they’ve been pressured to pick up a new AI-assisted coding tool, or they’re being told to become “AI native.”\n\nBut what does this all really mean? And what should you be doing to prepare yourself for the future?\n\nMost people think AI’s value comes from productivity gains and how it makes software development easier. But a model evaluation and threat research organization published a controlled study on open source developers who thought they were 20% faster, thanks to the coding tools they were using. Turns out, they were actually 20% less productive and slower because of these new tools. [(Click Here to read the study.)](https://metr.org/blog/2026-02-24-uplift-update/#wider-adoption-of-ai-has-made-it-more-difficult-to-measure-task-level-productivity)\n\nSo the question isn’t, *can AI write code?* Yes, it definitely can. The real question is: why isn’t AI translating into real improvements across the entire software development lifecycle?\n\nLet me explain.\n\nIn a typical software delivery lifecycle, we begin with determining the requirements for our application, designing what this ideal system would look like, building it (actually coding and testing the features we built), releasing it in a stable and predictable way, and then operating, which means maintaining the application.\n\nThis is how we’ve delivered high-quality software for decades. But let me give you a little secret: a lot of the time, you would think is spent in this entire lifecycle is *not* spent writing code. It’s the waiting.\n\nA developer is waiting on the product team to clarify a story we need to build out. Ops is waiting on a developer for their release. QA is waiting to test out a new build.\n\nEveryone in this entire lifecycle — all these teams, all these engineers — is waiting for each other across a series of fragmented tools and platforms just to deliver software. And these environments might be different, because what the QA and production team sees is going to be different than staging and the product team, who are just trying to build out features and test things out.\n\nWhen AI makes one box in this diagram faster — for example, the coding part — those gains get absorbed by all of the other phases, and you don’t see that big of an impact across the entire software delivery lifecycle. So sure, maybe you’re coding three times faster, but the surrounding processes aren’t changing.\n\nWhen teams try to use AI for the build phase, a lot of them fall into one of two situations. You can think of it like a spectrum.\n\nOn one end, you have over-delegation, where you hand a frontier model a big, ambiguous problem like, *“Hey, I want you to code me an e-commerce platform,”* and you expect that to run autonomously across the entire software delivery lifecycle.\n\nThe problem with this request is that it’s full of unstated decisions. What about the payments, the authentication, the shipping — all of these that typically would be thought through during the requirements and design stage have now been handed over to one model to do everything and generate thousands of lines of code that no one reads through.\n\nThis process seldom works, especially for production, because the review is slow. In the testing stage, you’re typically waiting for a team to review your code, and that requires so much time that you essentially lose all of the gains. You’re constantly going back and forth based on decisions a model made, and you slow down the software development lifecycle.\n\nOn the other end is under-delegation. A senior developer does all of the planning and breaks down the tasks themselves. They insert AI into specific areas like *“Write this function” or* *“Review this code for SQL vulnerabilities.”*\n\nThis part actually produces good code. But the intellectual heavy lifting is still 100% human. You’re putting all of the time and effort into the first two phases, but without using AI. And that slows down productivity, because yes, you might be coding some parts faster, but you’re still spending a lot of time on the design and architectural stages of the software development lifecycle.\n\nAt this point, you may be thinking, *“Well, dang, AI doesn’t work. It’s all hype.”* Or maybe you’re in the other camp, thinking, *“It’s fine, but it’s not the 10x in productivity we thought it would be.”*\n\nWhat happens when you redesign the lifecycle around AI instead of sticking AI onto the existing lifecycle?\n\nInstead of trying to generate more lines of code, let’s look at other high-impact areas, starting with requirements and design. Lots of unstructured data is coming from surveys, user reports, emails, and conversations with stakeholders.\n\nAll of this can be synthesized to understand your user behaviour bottlenecks and usage patterns. This can help us generate user stories, which then build out the next set of features and capabilities for the software we’re trying to deliver.\n\nAs another example, we can use an agent to analyse logs and bug reports to identify root causes of problems. This can even help us at the beginning stage of requirements and design , developing our software by knowing what works and what fails in production.\n\nNow let’s talk about coding, because the “vibe coding” of today simply doesn’t scale. Instead of asking AI to build entire systems, we can focus on small and well-defined tasks.\n\nThis is where spec-driven development becomes really important — not just for breaking work into tasks, but for taking the intent we have for the software we need to build and turning that into a specification that a model can read and follow.\n\nYour agent, or the harness (which includes the entire system around the agent, like tools), allows us to take that original specification and build it out with subagents.\n\nOne to do research on a specific topic and the dependencies you’re using. One to use the MCP servers to pull data from different sources your team needs. And one to do code editing in order to build out the new features and functions.\n\nBeing able to use different capabilities like agents.markdown allows us to share context across different teams in our organization, and use skills to make sure each time we get an output from a model — whether it’s one running locally, a private one, or something in the cloud — we’re getting the same response back as we’re building out our application.\n\nMoving to testing: we know manual testing is a classic bottleneck. Just as AI models can generate code, we can also build unique test data for unit testing specific cases that might come up in our application, and we can do this directly from a user story. This can all help the QA team down the line.\n\nWith the amount of log data generated by our applications, AI can help diagnose problems like a stack trace error , which is helpful when the system goes down at 3 a.m.\n\nFinally, with deployment, where we release and maintain our software, models are well-trained with infrastructure as code. Writing things like Ansible scripts to update virtual machines, or Kubernetes YAML to deploy our containerized applications to the hybrid cloud — all of this is already possible with today’s agents.\n\nA big use case for AI in software development is modernizing legacy software systems that no one really understands and that the original developers aren’t around to maintain.\n\nWhat AI is able to do is explain this code and help us reverse engineer systems to give you a path forward. You can still use a software development lifecycle, but use AI to understand what the purpose of the code was and what functions do — in a language you might not understand.\n\nThe productivity gain from AI isn’t because of a better model or tool. It’s from redesigning the software delivery lifecycle *around* the model. It’s about moving the human role from typing to validating and working with other teams in the organization. We’re removing friction and coordinating work across the software development lifecycle.\n\nInstead of measuring metrics like lines of code generated, it’s all about outcomes. How’s the health of our systems? What’s our code maintainability and complexity? Are we reducing the time for changes and new features in the software?\n\nAll of this is to make the developer’s life easier — and the lives of all the teams that developers work with. If you found this topic interesting, let me know what I should cover next!\n\nIf you found this helpful, consider clapping👏 so others can find it too.\n\n*[1] We are Changing our Developer Productivity Experiment Design (2026) — *[https://metr.org/blog/2026-02-24-uplift-update/#wider-adoption-of-ai-has-made-it-more-difficult-to-measure-task-level-productivity](https://metr.org/blog/2026-02-24-uplift-update/#wider-adoption-of-ai-has-made-it-more-difficult-to-measure-task-level-productivity)\n\n[Why AI Isn’t Making Developers 10x Faster (And What Actually Works)](https://pub.towardsai.net/why-ai-isnt-making-developers-10x-faster-and-what-actually-works-d1759f4838f0) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/why-ai-isnt-making-developers-10x-faster-and-what-actually-works", "canonical_source": "https://pub.towardsai.net/why-ai-isnt-making-developers-10x-faster-and-what-actually-works-d1759f4838f0?source=rss----98111c9905da---4", "published_at": "2026-06-28 15:01:02+00:00", "updated_at": "2026-06-28 15:09:22.346867+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-products"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/why-ai-isnt-making-developers-10x-faster-and-what-actually-works", "markdown": "https://wpnews.pro/news/why-ai-isnt-making-developers-10x-faster-and-what-actually-works.md", "text": "https://wpnews.pro/news/why-ai-isnt-making-developers-10x-faster-and-what-actually-works.txt", "jsonld": "https://wpnews.pro/news/why-ai-isnt-making-developers-10x-faster-and-what-actually-works.jsonld"}}