Copilots and agents: how writing software has changed

The 2025 DORA report, produced by Google across one of the industry’s broadest samples, leaves two figures worth reading together. First: 90% of development professionals use AI, fourteen points more than the previous year, with a median of around two hours a day working with it. Second: 30% report little or no trust in the code it generates. Only 24% say they trust it a lot.

That is what the report itself calls the trust paradox. It is not incoherence: it is how you use a tool that is useful without being reliable. You take advantage of it and you review it.

On how much code AI already writes, the circulating numbers are spectacular. Sundar Pichai stated in April 2026 that 75% of Google’s new code is AI-generated and engineer-approved; the progression is striking, given that in October 2024 they spoke of more than 25%. Microsoft put the figure in its own repositories at 20-30% in 2025.

Those figures deserve careful reading. “AI-written code” means different things depending on who is speaking: accepted autocomplete suggestions, agent-generated code, or code reviewed and approved by a person. They are not comparable magnitudes across companies, and treating them as if they were leads to wrong conclusions.

The most-cited productivity study is also the most badly read. METR published a randomised controlled trial in July 2025: sixteen experienced developers, 246 real tasks, in repositories they already knew. The result was that they were 19% slower using AI, while believing they had been 20% faster.

In February 2026 METR published a follow-up, and here is the mistake worth not repeating. The claim going around is that “METR now says they are 18% faster.” That is a misreading. The result was −18%, but with a confidence interval running from −38% to +9%: it crosses zero, so it is not conclusive. The authors themselves write that their data gives “an unreliable signal” of the current effect, partly because more and more developers refuse to take part in a study that requires them to work without AI. That is why they changed the experiment design.

This matters more than it seems. If you decide your team’s tooling based on a badly read figure, you decide badly. The honest conclusion today is that we do not precisely know how much AI accelerates an expert developer on code they already know, and that anyone giving you a round number is selling you something.

The underlying shift is clear enough: from copilots to agents. From sophisticated autocomplete to systems you give orders to and orchestrate. Computerworld covered it in June 2026, citing McKinsey: integrating AI tools is not enough, workflows have to be restructured. The tool alone does not change the outcome.

That same article points to what we consider the most serious risk of all, citing an Anthropic study: automation can erode junior developers’ ability to validate code. If nobody learns to review, in a few years there will be no one left to supervise what the machine produces.

The consequence already shows in the market: demand is shifting towards senior profiles able to govern AI systems, not towards entry-level positions. It is a problem for the industry, and one of the reasons we keep a stable in-house team rather than rotating people project by project.

Our approach to all this fits in one sentence: AI writes, a person signs. Nothing reaches production without someone who understands it having read it. Not out of distrust in the tool, but because the day something breaks at three in the morning, the one fixing it is a person.