AI adoption figures in software development are frequently misquoted. What they actually measure, what they do not change, and which practices to tighten when code is not written by a person.
Reports on generative AI adoption in software development keep producing headlines that travel fast: teams doubling their output, two-thirds of code written by assistants, 90% just around the corner. It is worth pausing on what those figures measure before concluding, because most of them are quoted in a way the original data does not support. And then the question that actually matters: what happens to quality when a growing share of the code was not written by a person.
The most repeated data point comes from a Jellyfish report, picked up by the tech press in early 2026: around 64% of companies generate the majority of their code with AI assistance, and that proportion could reach 90% within a year. It matters to read it precisely: the 64% and the 90% describe how many companies use AI predominantly, not what percentage of code the machine writes. Those are two very different claims, and the second one is what became the headline.
The same applies to doubled output. What the report measures is pull request throughput: organizations adopting AI aggressively report double the PRs of low adopters over a three-month window. More pull requests is not the same as more delivered functionality, or more business value.
And autonomous agents — the ones generating pull requests without human intervention — are still a minor share: in the top decile of companies, they went from 10% of PRs in January 2026 to 14% in February. It is growing fast, but it is a long way from the story that code now writes itself.
None of this makes the shift any less real or deep. What changes is the conversation: we are not debating whether AI replaces developers; we are debating how a team works when a significant share of what reaches review was not written by a human.
This is not an opinion running against the report: it is what the report says. The data shows the incentive behind adoption is tied to measurable productivity gains rather than quality improvements, and that accelerating production guarantees neither fewer errors nor better maintainability.
Generating code faster does not by itself solve a software project’s underlying problems: poor architecture, accumulated technical debt, or missing business judgment. AI speeds up writing, but it does not replace technical judgment about what to build and why. A team that doubles its speed on a badly designed foundation reaches the problem sooner — it does not avoid it.
When a significant share of the code was not written by a person, code review and testing stop being one more step and become the first line of defense. The teams that hold quality are the ones that tightened their code review practices and expanded automated test coverage — not the ones that simply adopted a new tool.
There is a side effect worth anticipating: if pull request volume doubles while review capacity stays the same, the bottleneck shifts to review. The risk is not only that bad code gets in, but that code gets in which nobody looked at closely because the queue was too long. Scaling review capacity is part of the AI adoption project, not a consequence that resolves itself.
Generative AI is most effective working within clear boundaries: a well-defined architecture, explicit API contracts, and consistent code conventions. Without that frame, the speed a team gains is paid back later in incidents and refactors.
In mission-critical systems, this weighs double. A wrong architectural decision in a banking platform or a system with compliance requirements is not fixed with a pull request: it is fixed with a project. A tool that writes faster does not change who decides what gets built.
For a company building custom software, the question is not whether to use generative AI, but how to integrate it without sacrificing delivery quality. That means more rigorous review processes, sound architectural practice, and teams that understand both the tool and the craft of building software.
At Sagant, we have brought AI into our development processes while holding the same quality standards we have always demanded. Technology changes how we work; technical judgment is still what makes the difference.
How is your team approaching generative AI adoption in the development cycle? We would love to hear about it.
