The interesting question about AI and software engineering is no longer whether it helps. It is when, and for whom, because the evidence points in two directions at once.

The forecasts have been confident. Consultancies have put the available productivity uplift at around 30 per cent, with less time spent on low-value code and faster movement from prototype to production (McKinsey). The tools are genuinely capable: Copilot, Cursor, Claude-based assistants and increasingly autonomous agents such as Devin can write boilerplate, docstrings and first-draft tests without complaint.

Then the measurements arrived

A controlled trial by METR found experienced developers working on codebases they knew well took 19 per cent longer with AI assistance than without it. They had expected to save about a quarter of their time. The gap went on reviewing, validating and correcting output. That result is uncomfortable, and it is also entirely plausible to anyone who has read a confident suggestion that was subtly wrong.

The opposite finding is just as well evidenced in different conditions. A study of Copilot use across open-source projects measured a 6.5 per cent rise in project-level productivity with no drop in code quality (arXiv). An enterprise rollout across 300 engineers reported a 31.8 per cent reduction in pull request review cycle time, with adoption settling at around 60 per cent (arXiv). Work out of MIT Sloan found the benefit concentrated among less experienced engineers.

Read together, the picture is not contradictory. These tools pay off in unfamiliar territory, in onboarding, and in template-heavy work. The returns shrink as familiarity grows, and in the hands of the person who knows the system best they can turn negative.

Speed is not the only variable

GitClear’s analysis of 153 million changed lines found AI-assisted work correlating with higher churn and more revision cycles (reported here), which is what you would expect from code written quickly and reasoned about later. The weak spots are consistent: business rules and regulatory constraints the model has never seen, system-level reasoning across more than one file, and non-functional requirements where the right answer depends on how the thing will be operated in three years.

What organisations are actually seeing

JPMorgan has credited coding assistants with efficiency gains of up to 20 per cent, mostly by freeing engineers from peripheral work rather than changing how core architecture is done (report). Google’s 2025 DORA report has around 65 per cent of developers relying heavily on these tools. And there is a sting: surveys suggest engineers save close to ten hours a week and then lose a comparable amount to organisational friction (IT Pro). The bottleneck was never typing.

How we use it

Scaffolding, stubs, candidate schemas, first-draft API contracts, and test cases we had not thought of, particularly around edge inputs. All of it is reviewed by someone who will still be maintaining the code afterwards. In defence and government work that review is not a cultural preference; it is the audit trail.

What seems to work

• Start where a mistake is cheap. Utility services and interface code, not the authorisation layer.

• Keep a human sign-off gate, and do not let it become a rubber stamp as volume grows.

• Tag AI-assisted code so churn and defect rates can be compared honestly rather than argued about.

• Run scanners and dynamic analysis over generated code as a matter of course. It is unfamiliar code, whoever wrote it.

• Teach people to prompt well instead of hoping for full automation, and give the model your own patterns and domain context to work from.

The honest summary is that these tools remove a layer of tedium and shift the work towards reading rather than writing. That is worth having. It is not the same as replacing the engineer, and the teams getting the most from it are the ones that stopped expecting it to.