Previous

Most software engineering teams across our portfolio now use AI to write code. Work that previously took days now takes hours. Yet CEOs keep putting the same question to us: if writing software has become so much easier, why has delivering products to customers not improved at the same rate?

We have been examining this across our portfolio and have developed a playbook for CEOs, CTOs and CPOs. Our conclusion is that the answer lies in how software businesses are managed, not in the AI tools themselves.

The bottleneck has moved

According to Sonar's January 2026 survey, developers estimate 42% of the code they commit is now AI-generated. Yet 96% do not fully trust it – and, even so, fewer than half consistently verify it before committing. Meanwhile, the tools have moved on from suggesting the next few lines, to editing whole files, running tests and changing systems directly.

Generating code has become cheap and fast. Establishing whether it is reliable, secure and fit for purpose has not.

In the same survey, 38% of developers said reviewing AI-generated code takes more effort than reviewing a colleague’s. So teams produce more code, while their most experienced engineers spend more time checking it. The productivity gain is real, but much of it is absorbed by oversight.

Knowing what to build still matters most

The other issue is a familiar one. AI is good at building what you ask it to build, but less useful when no one has properly established what needs building in the first place. Poorly defined requirements have always been costly. What has changed is how quickly a team can now turn them into something that resembles a finished product. A convincing demonstration can be produced in days, but that does not mean it meets a genuine customer need, or that it can be secured and maintained over time. When development moves this fast, the temptation is to spend less time on the brief, not more.

This compounds the problem. More code means more work to verify, and poor specification means some of that code should never have been written at all.

What to do about it

The answer is not to slow AI adoption. It is to manage these two constraints deliberately.

First, define the requirements clearly before development starts. Establish the problem you are trying to solve for the customer, the decisions already taken and the likely points of failure. AI can help by challenging assumptions and building quick prototypes, but a prototype should inform the specification, not quietly become the product.

Second, build in verification from the outset. Agree what success looks like, set the tests and acceptance criteria, then use AI to produce code against them. Senior engineers’ judgement is then focused on where it adds most value, rather than spread across an ever-growing pile of output.

Finally, feed what happens after release back into the brief. Customer complaints, support tickets, defects and usage data should shape the next set of requirements directly.

None of this is new. What has changed is the arithmetic. The reward for doing it well has multiplied – and so has the penalty for not doing so. DORA's 2025 research describes AI as an amplifier of existing organisational capabilities. That is exactly what we are seeing across our portfolio.

The questions I would ask as a board member

I would not start with which AI assistant the business uses, or how much more code its engineers write. I would ask what difference it is making to delivery.

Are we moving from an agreed customer requirement to a released product more quickly? Are we seeing fewer defects? Are our experienced engineers spending less time checking and correcting work? Is the cost of delivering a finished product coming down?

These are measures of productivity. Lines of code, numbers of prompts and licences purchased are not.

That is why we have made this a central theme of our Tech Forum. The question is no longer how much faster AI can help engineers write code. It is whether businesses can turn that capability into better products, more reliable delivery and lower costs.

Ben Hollowood brand bg

Words by Ben Hollowood

Nov 04, 2026