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.”
But what does this all really mean? And what should you be doing to prepare yourself for the future?
Most 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.)
So 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?
Let me explain. In 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.
This 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.
A 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.
Everyone 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.
When 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.
When 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.
On 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.
The 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.
This 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.
On 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.”
This 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.
At 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.”
What happens when you redesign the lifecycle around AI instead of sticking AI onto the existing lifecycle?
Instead 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.
All 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.
As 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.
Now 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.
This 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.
Your 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.
One 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.
Being 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.
Moving 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.
With 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.
Finally, 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.
A 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.
What 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.
The 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.
Instead 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?
All 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!
If you found this helpful, consider clapping👏 so others can find it too. *[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
Why AI Isn’t Making Developers 10x Faster (And What Actually Works) was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.