For decades, the bottleneck in software development remained the same: There was never enough engineering capacity to build everything a company wanted to build. AI is changing that equation, fast. Coding assistants have given way to autonomous agents that can spec, write, test, and deploy software with minimal human input, compressing timelines that once took weeks into days, even hours.
But the technology is moving faster than most organizations can absorb it. The companies seeing real gains aren’t the ones that handed developers a new tool; they’re the ones that have fully rethought the way software gets made. That means smaller teams, broader roles, different skills, and a fundamentally different relationship between human judgment and machine execution.
In this video Explainer, three McKinsey experts—Janaki Palaniappan, Martin Harrysson, and Matt Linderman—discuss what is actually changing on the ground, where the productivity gains are real versus illusory, and what leaders need to get right as AI takes on a growing number of software development tasks.
This interview has been edited for length and clarity.
How is AI changing the day-to-day work of software engineers?
Janaki Palaniappan: The way that AI is changing the lives of software engineers is through experimentation. Before, you would say I would love to have a code assistant to help me write faster and better code. Today that’s table stakes. Everyone has the ability to code faster with these coding agents. That means now it’s a lot more about experimentation with new, more innovative ideas that we think we might bring to market.
Matt Linderman: Over the last six months, we’ve seen an absolute game change in how software engineers, product managers, and DevOps folks are using AI across the end-to-end product development life cycle [PDLC]. As the code accelerates, the other steps become the bottleneck. First it was code review. Then it was product management. A lot of what we are seeing clients struggle with and then overcome is what should come next. How do we define the road map as engineering is accelerating?
Martin Harrysson: It’s a true paradigm shift in how the work gets done. If you think about day-in-the-life just a few years ago, you’d spend a lot of time literally writing code, running tests. Now, the end-to-end coding activities are increasingly getting done by agents. The job of someone building software is much more about figuring out what I need to build, how do I parse out the work into different tasks I can give agents, what do I inspect when they come back? At a fundamental level, how you interact with your system to build software has really been turned on its head.
Where are organizations already seeing productivity gains? And why are so many struggling to turn those gains into value?
Matt Linderman: I’m doing work with a private-equity-owned software company. The CTO [chief technology officer] ran an experiment: two full scrum teams working together on a redesign versus one streamlined squad made up of one product manager and three developers. The small team was working in totally new ways, unconstrained from their normal agile process, and they completed the task in four days versus four weeks for the other team, which was four times larger. That then got folks asking: How did you do that? Then you start to think about how to replicate that, not just on the one task but for 80 percent, 90 percent of what we do.
Janaki Palaniappan: Individual productivity improvement is the first paradigm of gain we see: I’m doing a task, I’m using AI, I improve. That may make you more productive, but it doesn’t lead to any real bottom-line or top-line impact. To get there, leaders look at the entire end-to-end workflow. Within product development, you have to think about the inception of the idea itself through discovery, testing, coding, launch, and scale. That’s where you see real acceleration to market.
Martin Harrysson: At the individual and small-team level, we’re seeing a lot of impact. But where most are running into bottlenecks is scaling to hundreds or thousands of developers. You quickly run into constraints: team structures, roles and responsibilities, collaboration overhead that hasn’t changed even though you have these tools. Enterprise processes around planning and security reviews move at a much slower pace than what you can do now if you’re really leveraging these tools.
How are software teams changing when AI is integrated into the whole development process?
Matt Linderman: We usually think about the changes on three levels: process and operating model, talent and roles, and the technology that enables that. We started by taking tools like Copilot and Cursor and overlaying them across existing steps. Then we added agents where we didn’t have tools. Now we’re building essentially end-to-end flows—what we’re calling agent factories. And as you move toward those flows, you change the team. We’re seeing team structures become much smaller, with much more generalist-type roles—two to three people versus six to ten in the original team—moving from specialized front-end, back-end, QA roles to what we’re calling “definer” and “builder” roles.
Looking for direct answers to other complex questions?
Janaki Palaniappan: At the squad level, you look at the traditional eight or nine person team coming down to about three or four, working directly with agents as teammates. The roles themselves are becoming more T-shaped: product manager, designer, developer, QA are all converging as AI starts to do more of that job. At the enterprise level, the disciplines don’t go away—design, product management, architecture are still incredibly important—but now they’re being set as standards, embedded as code within your workflow.
What skills are becoming obsolete for software engineers—and what’s becoming essential?
Matt Linderman: The overall shift is that people have to move toward a tech-lead skill set much faster in their career. Individuals are now handling the entire end-to-end flow: thinking about the spec, the right technical solution, writing the code, testing it, releasing it. That skill set historically belonged to the tech lead. Now developers are building it in year two or three of their careers versus year six.
Janaki Palaniappan: The repeatable tasks—code writing, testing, writing that first version—are becoming automated. But the skills that become really important are strategic: systems thinking and ownership. The agent can do the work for you, but you, the human, have to own the output. When I use these tools, I think of it like this: A junior colleague produced something for me. I’m looking at it and asking, do I agree with this? Can I stand behind it, can I defend it?
Martin Harrysson: Things that have become more important: being able to decompose a problem into different parts, parsing out work that can be assigned to agents, thinking about architecture, thinking in terms of evaluations and test-driven development. Things that have become less important: deep experience in particular programming languages and the syntax and tactics of writing code. Agents can do a lot more of that work now.
Where do humans continue to add value as AI takes on more of the building?
Matt Linderman: The human has a critical role to play, especially early in the process. If you can move faster on engineering, figuring out what to build becomes the constraint. The “what to build” has always been the human role throughout product management—and while agents can accelerate it, we still need real direction. Out of the million directions you could choose, which do we want to explore? That skill of looking at the four or five options, even if offered by agents, evaluating them and choosing the right path—that’s critical right now.
Janaki Palaniappan: At the end of the day, we start with a human problem, and we end with a human problem. The ability to build new software at scale has become so much cheaper—you can essentially build many, many things. But the question is: Are those the right things to build? Will people actually want them? Those are things a machine is not going to figure out. And a human is still required to explain a solution, convince people, and get them to buy in.
Martin Harrysson: Clients are facing a problem they haven’t had in a long time: They have to get much quicker at figuring out what to build. If you can build almost anything very quickly, practically for free, then everyone can do that—your competitors, new upstarts. So, it puts a high emphasis on deciding what to build. Some say that if you strip this back and look forward, the only thing remaining in software development will be taste or judgment about what users will like. I don’t think we’re quite there yet, but that’s the direction.
How is AI changing the software development life cycle from requirements through deployment?
Matt Linderman: We’ve always had the vision of test-driven development and other best practices, but in practice the execution wasn’t there, given the amount of work required. The technology now allows you to truly follow those best practices—define your requirements in far more depth and detail, check all the various regulations, and do this at much higher quality and speed. A lot of the real innovation is happening much earlier in the process, around what to build. You can now connect product management systems into flows that operate more autonomously: collect user feedback, cluster it into surface pain points, look up competitors, come up with ideas, mock up a prototype, all asynchronously.
Janaki Palaniappan: There’s no one product development life cycle anymore. The life cycle depends on the type of work you’re doing. Greenfield development with a brand-new stack looks really different from an existing product in market, which looks different again from modernization or tech debt work. The idea of test-driven development has been around for years, but it was hard to make a reality. Today, it can become one. Automated bug fixes, automated maintenance—you can now retire tech debt and modernize your stack in a much faster, more automated fashion.
Martin Harrysson: We need to really think about this as a redefining of the life cycle, not just a speeding up of existing steps. There are whole steps that we no longer need to do at all or need to do in a different order. We need to put more emphasis on risk and resilience up front, and then not have so many human-in-the-loop review steps throughout. Because if you still do, you won’t get the performance gains you’re looking for.
How far are we from AI systems that can autonomously build and deploy software?
Martin Harrysson: We’re seeing this happen in some narrow areas, two of which work best: greenfield builds with few constraints and a clear problem definition, and modernization—taking software that already exists and rebuilding it in a new stack, where the target outcome is very well defined. But I’d caution against thinking full autonomy is imminent. We tend to be notoriously bad at estimating how long these things take. Think of self-driving cars: The technical pieces were supposedly in place years ago, but there are so many edge cases to sort out. The same is true for enterprise software.
Janaki Palaniappan: AI autonomously building and deploying software is already here. Leaders are already looking at the bifurcation of their backlog and asking themselves, what things are minimal risk that can basically be spec’d, developed, deployed without any human intervention, because the risk is low? And that is only going to increase. The software development where humans get involved will be very much on new innovations where you really need a human to pressure-test things. The biggest thing we need to figure out is the risk appetite and security posture for autocommitting and autodeploying into the market.
Matt Linderman: That has been the vision for four years, and we already have solutions today that can build autonomously end to end. But the question is whether they can do that at high fidelity, high quality, and with security. Right now, we’re not there. The human steer in terms of ideation is critical: Given that you could quite literally move in any direction, having a human guide the exploration is very helpful.
What risks do organizations face when incorporating AI into software development?
Janaki Palaniappan: Risk is a real issue here. It’s important to have a clear posture of what you will and will not risk within the enterprise. Ring-fence the critical capabilities that you cannot risk today; at the same time, you can start doing small experiments in AI workflow deployment in other areas to see what works. As you learn more, you may say: We’ve built up enough understanding of how to manage risk that we can start doing this in the critical capability areas as well.
Matt Linderman: You have to use the models to get ahead and build much more secure software than you were ever able to before. The models are very good if you target them at finding holes in your code base. Before you release anything, have it review your code base, identify all the same flaws it would have used as vulnerabilities, and patch them before release. It becomes the responsibility of every creator of software to use these tools for their own defensive purposes.
Martin Harrysson: Security and risk have often been treated as something you do after you build the software. What is clear is that this work has to move to a lot earlier in the process; you have to think about this as you design the product. While most AI-generated code has the potential to be more secure over time, so far it has often been more verbose and less secure than human-written code. We need to think through what to look for up front.
