On 1 October 2026, David Pralong, a senior partner at McKinsey, wrote in Fortune that AI's most cited successes are misleading CEOs. Software teams were among his examples, and the reason is uncomfortable: those teams already had something before the models arrived.
What they had, according to Pralong, were "testing, continuous integration, and code review practices" that made it possible to benefit from AI. He adds that those cases are "a starting point, not a template" that can be dropped into any company.
That gives this piece its thesis: to adopt AI in a development team, the first step is not choosing the agent but checking the net that catches errors. If the team cannot check what goes in, an agent produces more code than anyone can verify.
Why the tool is not the first question
DORA, Google's research programme on software teams, sums it up in its 2025 report on AI-assisted development: AI's primary role is as an amplifier, magnifying an organisation's existing strengths and weaknesses. A team that integrates daily and reverts without drama gains speed. A team that deploys with fear deploys faster with the same fear.
In September 2025, DORA published a model with seven capabilities that, according to its analysis, amplify or unlock the benefits of AI. Three concern data and platforms, one is user focus and another is having a clear stance on AI. The remaining two are exactly the net Pralong describes:
On the first, DORA writes that as AI increases the velocity of changes, the version control system becomes a critical safety net, and it recommends that teams become highly proficient in using rollback and revert features. On the second, that working in small batches is "especially powerful" in an AI-assisted environment.
An agent does not bring quality: it brings volume. Quality comes from the net the team already has for checking every change.
The net, piece by piece
These are the pieces worth looking at before giving a team an agent. None is new; what changes is how much they matter when the pace of change goes up.
| Piece of the net | What it catches or prevents | Question for your team |
|---|---|---|
| Tests the team trusts | A change breaking something that already worked | When a test fails, does someone investigate, or is it rerun until it passes? |
| Continuous integration | A change that only works on its author's machine | Does every change go through the same suite before it is merged? |
| Small changes | A review made impossible because the change is huge | How long does a typical change take to review, and how many lines does it have? |
| Version control and reverting | An error costing hours instead of minutes | When did you last revert something, and how long did it take? |
| Review with judgement | Code nobody understands getting in | Does review check what the change does and why, or only its style? |
| Written acceptance criteria | Code that does what was asked but not what was needed | Before starting, is it written down how you will know the work is right? |
The first five pieces come from Pralong (McKinsey) and DORA's model; the sixth and the questions are onext's own reading
Review is the piece that changes most: when the author is an agent, review can no longer assume there is someone who knows why each line was written. We cover it in reviewing AI-generated code. And acceptance criteria can become the condition for integrating a change, as we explain in your spec is already an eval; it is the basis of Spec-Driven Development (SDD), development guided by specifications, summarised in what SDD is and how it keeps code under control.
What the productivity figure says, and what it does not
The most cited study of coding assistants in real companies is by Cui, Demirer, Jaffe, Musolff, Peng and Salz (Microsoft Research, June 2025). It combines three randomised experiments at Microsoft, Accenture and an anonymous Fortune 100 company, with 4,867 developers: those with access to the assistant completed 26.08% more tasks, with a standard error of 10.3%. Less experienced developers adopted it more and gained more.
Limit It is an average across three large companies, with a wide margin of error, and the study does not describe what each team's safety net looked like. It does not prove that without tests or continuous integration there is no gain. What you cannot do is take that 26% as a promise for your team: the only figure that counts is the one you measure yourself, before and after.
What is reasonable to read alongside Pralong and DORA: the gains Pralong cites appear in teams that already knew how to check and undo their changes. And without that net, even if the team goes faster, nobody can tell whether it is going better.
The order we propose
Adopting AI does not require stopping the team or rewriting how it works overnight. It requires an order:
- Check the net with a pilot team. The six questions in the table, answered with the team's own data, not opinions.
- Fix the biggest hole. If tests are unreliable or changes are huge, that comes before any licence.
- Measure the baseline. How long a change takes to reach production today and how many are reverted. Without that figure, you will not know afterwards what has changed.
- Bring in the agent on work already planned. In parallel with the team's sprint, with limited permissions and the usual review.
- Compare and decide whether to scale up. With your data, not a study's.
This order does not deny that adoption is also organisational, as we argue in AI success in development teams is organisational, nor that people, processes, tools and indicators have to be looked at together, as in the four perspectives of a development team working with AI. This piece answers a narrower question: what comes first. And once the agent is in, the rules it must follow do not belong in a text the model can ignore, but in controls that apply themselves, as we explain in Claude Code for teams: context is not control.
Where onext fits in
If you are thinking about how to adopt AI in your development team, the first step in AI-Accelerated Development is a free diagnostic, and if the diagnostic shows no difference, there is no Quick-start. When there is a Quick-start, you do not need to stop delivering: it works with a pilot team, on real work already planned and in parallel with its sprint. And in the process, a person decides where there is risk.
Pick a small change that went wrong in recent months. Ask at which point your team would catch it today and how long it would take to undo. If the answer is "in production" and "we don't know", you already know where to start, and it is not the agent.
Frequently asked questions
What is a development team's "safety net"?
It is the set of practices that catch an error before it reaches production or let you undo it quickly: tests the team trusts, continuous integration, small changes, version control with the habit of reverting, and code review with judgement. It is not a tool: it is how the team works.
Why check the safety net before buying licences or agents?
Because AI speeds up what is already there. DORA's 2025 report describes it as an amplifier of each organisation's strengths and weaknesses. If the team has no way of checking what goes in, an agent produces more code than anyone can verify.
Is AI useless without tests or continuous integration?
There is no data to claim that. What McKinsey does say, in David Pralong's piece in Fortune, is that the software teams that achieved gains already had testing, continuous integration and code review practices. The observed gain came with a safety net; without one, nobody knows whether a fast change is also a good change.
How much does a coding assistant improve productivity?
A study of 4,867 developers at Microsoft, Accenture and a Fortune 100 company measured 26.08% more completed tasks, with a standard error of 10.3%. It is an average across three large companies, not a promise for yours: the way to find out is to measure it in your team, before and after.
Do you have to stop delivering to prepare the safety net?
No. The sensible approach is to start with a pilot team, on work that was already planned and in parallel with its sprint, fix the biggest hole in the net first and measure before scaling up.
How do I know whether my team's safety net is ready?
With a simple test: pick a small change that went wrong in recent months and ask at which point it would be caught today (a test, continuous integration or review) and how long it would take to undo. If the answer is "in production" and "we don't know", that is the first job, before the agent.
Sources
- David Pralong (McKinsey), "McKinsey senior partner: Why AI's easiest wins are misleading CEOs", Fortune, 1 October 2026.
- Kevin M. Storer and Derek DeBellis (Google Cloud), "Introducing the DORA AI Capabilities Model: 7 keys to succeeding in AI-assisted software development", 23 September 2025.
- DORA, "State of AI-assisted Software Development 2025" (accessed 13 October 2026).
- Zheyuan (Kevin) Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng and Tobias Salz, "The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers", Microsoft Research, June 2025.
- The table of questions, the proposed order and the final test are onext's own reading.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →