- 9 hours ago
While first-generation AI coding assistants represented a step toward industrializing development, their overall impact on delivery cycle acceleration remained limited at under 10%. Today, the paradigm is shifting. The rise of Agentic AI enables the creation of hybrid human-agent teams structured around a brand-new operating model—one that dramatically collapses delivery cycles and unlocks unprecedented 10x productivity gains. Successfully deploying and scaling this hybrid model requires a strategic combination of three success factors: 1/ Rethink the target operating model from scratch, 2/ Closely monitor impact and adoption, and 3/ Start small, but prepare to scale in a controlled way.
In this keynote, McKinsey & Company’s Stéphane Bout (Senior Partner) and Samir Nejjaï (Associate Partner) will explore how Agentic AI is fundamentally reshaping software development. Through real-life examples and live demos, they will demonstrate the tangible, capturable impact beyond the market hype, and share the secret recipe to capturing value at scale.
In this keynote, McKinsey & Company’s Stéphane Bout (Senior Partner) and Samir Nejjaï (Associate Partner) will explore how Agentic AI is fundamentally reshaping software development. Through real-life examples and live demos, they will demonstrate the tangible, capturable impact beyond the market hype, and share the secret recipe to capturing value at scale.
Category
🤖
TechTranscript
00:00Please welcome Stefan Boots and Samira Nejai from McKinsey to unpack all this.
00:29Good morning, today we are going to share a concrete return on
00:36experience on next-gen software development based on hybrid human AI teams. This is based on a series
00:46of large transformation projects conducted for software editors and IT organizations across the
00:54world by Quantum Black, the AI center of expertise of McKinsey with 7,000 AI experts across the world.
01:03McKinsey in the last past two years has deployed more than 25,000 agents across sectors across
01:13functions and 20,000 internally. The company is becoming one of the first symbiotic enterprise
01:22where 40,000 employees are collaborating with 20,000 agents, each contributing according to
01:31their specific strength. Software development is probably the first area of opportunity in terms
01:40of value at stake for Agentic AI. It represents almost 20-25% of the total value expected from
01:49Agentic AI across all enterprise functions. In the past, let's say five years, adoption of AI coding
02:02testing assistance has exploded with, for example, currently more than 20 million of users for GitHub
02:09Copilot, several millions for Cursor or Cloud. In parallel to this explosion, the capabilities have
02:20progressed significantly. While at the beginning, it was possible to get some code suggestions through a
02:26prompt. It's now possible to perform very complex task along the software delivery
02:34lifecycle with AI agents. But the key question is, what is really the impact generated, notably in terms of
02:42productivity and lead time compression? If you analyze the typical distribution of workload in a software
02:53project, you see that the programming part typically represents between 30, 40, in some cases, 50% of the total
03:03workload.
03:04With the first generation of AI coding assistant, it was possible to optimize this part, the programming task,
03:11with typically a productivity gain of 10 to 20%. If you look at the whole project, you know, this represents
03:20a 5-10% productivity gain.
03:23Interesting, but not descriptive. You can generate greater gains if you leverage AI
03:31assistant along the whole delivery lifecycle. For example, to generate functional specification,
03:37user story, or test scenario. In that case, you can expect 10-20% productivity gains at the level of
03:48the
03:48whole project. Better than when you use AI assistant only on the programming task, but still not really
03:56descriptive. In fact, the step change comes when you reinvent from scratch the whole delivery model,
04:06redistributing tasks between humans and agents. In that case, you can reach 50-70%
04:15productivity gains and a radical reduction of the delivery lifecycle lead time. Let's take two concrete
04:22examples. First, for the modernization of a large legacy system, and then the development of a new
04:31application from scratch. Thank you, Stéphane. So let's start with the first case, which is on legacy app
04:37modernization. So our client, a big bank, was facing a major obsolescence issue on his core banking
04:45system. The thing with this core banking system is that it was super large and complex. So picture
04:51this for more than 400 applications, millions of lines of code, little to no documentation. So they
04:59started with a traditional approach with developers using maybe a bit of AI assistance, but they were
05:06quickly facing a war. And they estimated that in order to conduct this massive project, they would need
05:13to put an investment on the table of more than $600 million. So here, what we have done is that
05:22we have
05:23built a literal factory of more than 100 agents in order to deliver this massive modernization. And this
05:33enabled to achieve really impressive results. So we were able to cut both effort and time by 50%.
05:41And here, the challenge was, how do you organize such a big agentic team? Because 100 plus agents,
05:53it's exciting. But how do you concretely do that? So in order to do that, we, Quantum Black, we designed
06:00an approach that we call the humanistic approach. And this approach basically relies on thinking your
06:06agent teams like you would think about your human teams. So let's dive into this.
06:13We start with the agents. So the agent in its LLM prompt is given a certain expertise. So we have,
06:20for example, a Java developer agent that is an expert in Java code. Secondly, we give him tools so he
06:25can
06:26interact with his environment. So for example, the technical writer can read and save files.
06:33With these agents and tools, we regroup them into squads, like human squads. So here, for example,
06:40we can have a squad with a planner that plans the work, a Java developer, a technical writer that will
06:45read and write the documentation, and then a critic that will review all of this. So one squad is a
06:52team
06:52that is able to achieve a specific task. For this squad to work, we will not put agentic everywhere, so
06:57we
06:58have also pieces of software, of a regular software, that enables to preprocess inputs and outputs.
07:05All of this, we put squads together and we group them into groups. And a group will pursue a specific
07:13goal. So for example, we have a group in this modernization that was focusing on documenting
07:19the legacy source code. And here you had the squad on Java documentation, another one on GSP
07:24documentation. And all of this, you chain these groups together with flows. And here you have
07:31like the full picture about how you organize 100 plus agents and deliver a massive modernization.
07:39The second use case that we will look on is about application development and maintenance. So here,
07:46another client, another bank. So we are starting with traditional squads. And these traditional squads,
07:53they had been provided with AI assistance. And as Stefan was saying, the productivity gains were not
08:00captured quickly. So basically, they see a little productivity of 5% to 10%. And actually, the time
08:06to market didn't really change. So we were still on a two-week sprint. So here, what we have done,
08:12we totally reinvented the software delivery lifecycle. We rethought it around a hybrid human and agent teams.
08:23And we were not only able to cut productivity by 50%, but also at the end, to move from a
08:29two-week
08:30sprint to a 24-hour sprint for the same scope. How does that look like? So in the morning,
08:39the product owner comes, draft the high-level requirements, and then the agent picks up and
08:45generates really detailed specs. The product owner review the specs before launch. The developer provides an
08:52overall direction about the technical design. And then, the agent also picks up the work during
08:58launch. And they create a really detailed implementation plan, which is basically,
09:03how am I going to implement all these changes in my source code? And what are all the things that
09:09I'm
09:09going to modify? After launch, the developer just review the plan, ensure that agents have everything
09:17they need to do in order to work. Then they let them work the whole afternoon. They're building stuff.
09:21They're testing it. And at the end of the day, you have your merge request. The developer just need
09:27to review and approve the merge request, and then set it back into the CI-CD pipeline. And then you
09:32have
09:33like your whole sprint in a full day. Because at the beginning, you can do that on one user story,
09:39but actually, you can scale and do it like for the whole user stories of your sprint and epic.
09:47Under the hood, what's the technical approach? So, we have seen in the industry two main
09:52approaches. So, you have the IDE approach, and you have a platform-centric approach. Both have their
09:57pros and cons. So, the IDE approach is really helping the developer to really see the workflow, adjust the
10:06workflow live and also approve every step and approve the usage of the tool. On the other side,
10:12you have a platform. And the platform enables you to scale, enables you to ensure reusability and
10:19solidization, and also prevent agent proliferation. It also enables you to have agents beyond the developer
10:28workstation. So, you can have agents that work within the CI-CD pipeline or agents that scan your
10:34different repo. So, it's only offline. So, now, we will move to a demo where we will see it live
10:42on
10:43the computer of a developer. Thank you. So, here on the demo, you can see actually what the developer
10:51is seeing. So, on the left-hand side, you have the agent workflow, and on the right-hand side,
10:56you have the application. So, on the left, you see that the developer is launching an agentic workflow,
11:00which is called the builder, with the ID of a Jira ticket. So, the agent will read the different skills,
11:07understand what is the workflow about, and execute the action. So, the first action that he identifies
11:13is, I need to fetch the Jira ticket. So, he automatically connects to the Jira repo, fetch the ticket,
11:20and also identifies that there is another input that he can use, which is a Figma design. So, now,
11:25he is also going to connect the Figma node and collect this input. With both these inputs,
11:33the agent is going to build detailed specification. So, now, we have taken here a simple evolution
11:40where you see the web app on the right, and the evolution is simply adding a checkbox for the
11:45customer to confirm the terms and conditions, and also make sure that this checkbox is translated
11:52in different languages. So, you have the Jira ticket, you have the Figma design. Now,
11:59agent is working in order to build this detailed specification. It's building it in a markdown format,
12:07which is the format that is the most easy and useful for agent to work with. So, here we can
12:14see the
12:14generation on the left, and you will see on the big screen on the right the results of this detailed
12:21specification. So, you can see on the right, these specifications are actually of high quality. So,
12:29we have all what is needed to business logic, the acceptance criteria that will be very important
12:34at the end, and also, like, we see that he picked up inputs from both the Jira ticket and the
12:40Figma
12:40design. And now, the agent is going to work on the most complex part, which is how do I translate
12:46this
12:47requirements into a detailed implementation plan, which is what do I need to modify in my source code,
12:55my configuration, and all my documentation in order to implement this new feature. So, here,
13:01this is like the most complex one, and we will see that he will also generate this detailed
13:07implementation plan in a markdown format that we will see in a second.
13:13So, here we have the implementation plan, where we have the details of what is implemented,
13:20and all the components that will be impacted, but also, we have a detailed step-by-step
13:27workflow about what needs to be done. And actually, if you look at the left-hand side, you can see
13:32that
13:32this has been translated into a to-do list, and the agent will go through its to-do list one
13:37by one
13:38in order to do all the things. So, the first thing that he needs to do is to build the
13:44functionality,
13:45and then he will need to build the unit test and test the functionality. So, the first thing that
13:51he's doing is building the functionality. So, now, we will see live this little checkbox that has been
13:57added on the right on the window. So, this is like the first change. And then, the agent will work
14:03on the
14:03second change, which is doing all the translations. So, here we see the power of an LLM that is really
14:09able to do that pretty fast and with high reliability. Third part, very important, building the unit test.
14:18So, here, the agents need to review all the acceptance criteria and also understand all the unit
14:25tests that already exist in order to build the testing that will enable at the end to ensure that
14:32everything in the specification have been done properly and in line with what has been specified by
14:38the business. So, now, the tests are built, and we are going to run them also to make sure that
14:45everything
14:45passed. Interesting enough, we see that at the first run, one of the tests is not passing. So, the agent
14:54is able to
14:55identify that and automatically adjust his workflow and say, okay, this is not working. I made a mistake.
15:01So, now, he's going to look for the mistake in both the source code and the unit test. It realized
15:06that actually
15:07the mistake is not in the source code, it's actually in the way it's tested. So, he's going to modify
15:11the unit test and run them again.
15:14Now, they are run. All tests pass. We're all good. So, the last step is to generate a very nice
15:23synthesis for the developer so he can review.
15:25So, we have a synthesis here saying what are the specifications, the implementation plan, all the files that have been
15:31modified, the acceptance criteria with the result of the unit test, and all the modifications. And in this operating model,
15:39we have done it in a way
15:41where the developer is actually able to check at each step that everything is working and pass to the next
15:48step.
15:49You can also have an operating model where you launch that in the evening and review all the results in
15:55the morning.
15:56This was an example of a transformation at scale. So, we will see what are all the lessons learned
16:00from similar at scale transformation with Stefan. Thank you, Samir. Those two real-life examples illustrate the
16:09disruptive potential of agent TKI in software development. But it's important to have in mind that
16:17capturing this potential requires a very specific transformation approach. I mean, the traditional approach
16:25consisting in deploying tools during a training session for developers, product owners, QA in teams is
16:34absolutely not sufficient. Based on our experience, we do see three key success factors to capture this potential.
16:45Rethink radically the whole delivery process. Drives the transformation with performance indicators.
16:53And third, start small but anticipate scaling from the very beginning. Let's deep dive on each of them.
17:01First, rethink the whole operating model. Five key points, five concrete learnings. The first one,
17:08the necessity to reinvent the whole process rather than pursuing an approach with fragmented use cases that are
17:18covering an individual step or even an isolated task within the process. Secondly, reinvent the process by
17:28allocating optimally tasks to agents and humans and structuring with an industrialized approach the workflow.
17:37This is a humanistic approach illustrated by Samir a few minutes ago for the legacy app modernization.
17:43Third, it's important to have in mind that this has to be done progressively. Typically, the right approach
17:50consists in controlling the output of each individual agent first and then automate end-to-end the process and
17:58control only the final outcome of the process. Fourth, the transformation of the document. The traditional
18:05approach consisting in documenting notably specification through word processing tools, you know, is no more adapted.
18:14You need a documentation formalized in a markdown format and even managed as code on the code repository itself.
18:23This documentation must be understandable by human beings, of course, but also by agents. And finally, it's important to
18:31anticipate that there is not one unique way of working. Based on our experience, you need to define several
18:37variants of operating model adapted to each situation. Modernization of a legacy application, development
18:45from scratch of a new software, evolutive maintenance of an existing software, or even refactoring or code
18:54optimization for an existing software. Each variant requires a different workflow. And that means that for
19:01teams, you know, probably they will have to adopt a different approach depending on the nature of the
19:06work they have to do. Secondly, it is extremely important if you want to concretize the impact to monitor and
19:13to
19:13monitor through a series of indicators that are measurable, that covers productivity, speed, but also quality. It's
19:22extremely important to make sure that the progression in terms of productivity and speed is not at the
19:30detriment of the quality of the code that is produced. It's also important to set up a continuous improvement
19:36approach. You don't capture the gains immediately. It takes time. And so it's important to set up a series of
19:43performance, recurring performance dialogues where teams analyze where they are against the target and develop a series of
19:51concrete action to continue to progress. In terms of organizational structure to manage the change, we do
20:00recommend a two-level approach. You have a center of expertise and then in each team you have a relay
20:06in charge of
20:07ensuring that the new way of working is perfectly adopted. And finally, in terms of, I would say, pace for
20:17the
20:17transformation, we recommend to start small with a pilot domain where you deploy the new SDLC AI powered
20:27end-to-end. And when this is stabilized, when you have got concretely the result, then you can deploy that
20:34across the whole organization. It's also important, as indicated by Samir, to have a clear approach in terms of
20:42technology architecture. Start with an IDE-centric approach is often very practical because easier. But if you want to deploy
20:51agents
20:52along the whole software lifecycle, very often you have to move rapidly towards a platform-centric approach that will allow,
20:59for
21:00example, to deploy agents downstream in the CI-CD part. So this was, today, a return on experience of what
21:08we can do now with
21:09agentic in software development. Thanks a lot for your attention. With Samir, we are at your disposal. If you have
21:15questions, we will be very happy to deep dive with you. Thank you very much.
Comments