AI makes coding easier. It also creates new requirements.

What has really become easier

AI coding assistants have moved from curiosity to default in a remarkably short time. In Google’s 2025 DORA study of almost 5,000 technology professionals, 90% use AI at work, with a median of two hours a day, and more than 80% say it has made them more productive.¹ In the Stack Overflow survey of more than 49,000 developers, 84% use or plan to use AI tools, and half of professional developers use them every day.^4,5

The gains are real where the work is well defined: boilerplate, tests for existing behaviour, translation between languages and frameworks, first drafts of documentation, and exploring an unfamiliar codebase. DORA also finds that AI adoption now goes together with higher delivery throughput, a reversal of its 2024 finding.²

The same study, however, still links AI adoption with lower delivery stability.² That combination, more output and less stability, is the signal that something else has changed.

Where the bottleneck has moved

Writing code was never the whole job. A change has to be specified, written, reviewed, tested, deployed and operated. AI compresses one of these steps dramatically. The others stay, and some grow, because there is now more code to check, and it arrives faster.

The evidence points the same way. Two thirds of developers say their top frustration is AI output that is almost right but not quite, and 45% say debugging AI-generated code takes more time.⁴ Trust is falling as use rises: the share of developers who distrust AI accuracy grew from 31% to 46% within a year.⁵

Perception is also an unreliable guide. In a randomised trial by METR, 16 experienced open-source developers worked on 246 real issues in large, mature repositories. With AI tools allowed, tasks took 19% longer. Before the study they expected a 24% speed-up; afterwards they still believed AI had made them 20% faster.⁶ A larger follow-up with 57 developers, published in February 2026, pointed to modest speed-ups with wide uncertainty; METR itself called the signal unreliable, partly because many developers no longer want to work without AI.⁷

The lesson is not that AI does not help. It is that the gain is decided outside the editor: in how clearly work is specified, how well it is checked, and how safely it reaches production.

Seven new requirements

From building and running software that operates around the clock, with AI in the daily workflow, I see seven requirements that matter more now than before. None of them is new in principle. What is new is that ignoring them has become cheaper in the short term and more expensive in the long term.

Specification becomes the new source code

When a machine writes the first draft, the quality of the instruction decides the quality of the draft. Teams that write down intent, constraints and acceptance criteria before generating code get usable output. Teams that skip this get code that compiles, passes a quick look, and fails at the edges. In practice, the most valuable senior skill has shifted from writing code to describing precisely what the code must and must not do.

Review is no longer a formality

A Stanford user study found that participants with an AI assistant wrote significantly less secure code than those without, and were more likely to believe their code was secure.⁸ This is the core risk of AI-assisted development: not that the machine makes mistakes, but that people check less carefully because the output looks finished. Review has to be treated as engineering work with time and responsibility attached, not as a click before merging.

The supply chain is now part of the code

Package hallucination turns a model’s mistake into an attack surface. In an analysis of 576,000 generated code samples from 16 models, researchers found more than 200,000 unique names of packages that do not exist.¹¹ OWASP lists this pattern explicitly and recommends cross-checking and human oversight.¹² At the same time, regulation is raising the bar: since 11 September 2026, manufacturers of products with digital elements sold in the EU must send an early warning about actively exploited vulnerabilities and severe incidents within 24 hours, followed by a notification within 72 hours, under the Cyber Resilience Act; the main obligations apply from 11 December 2027.¹⁴ The Act also requires a software bill of materials in the technical documentation.¹⁵ A team that does not know what is in its software cannot meet these duties, however the code was written.

Ownership cannot be generated

Legal questions follow the same logic. In the United States, the Copyright Office has stated that AI output is protected only where a human has determined sufficient expressive elements; prompts alone are not enough.¹⁶ Whatever the jurisdiction, the practical answer is the same: someone in the team must understand, own and be able to explain every component that ships.

From a tool to a team practice

DORA’s most useful finding is a simple one: AI is an amplifier. It makes strong teams more efficient and intensifies the problems of struggling ones. Loosely coupled architectures benefit; tightly coupled ones see little gain.² DORA has since described seven capabilities that turn AI adoption into results.³

In the systems I build and run, this translates into one rule: every AI-written change goes through exactly the same gate as a human one. It lives on its own branch, is built and tested automatically, is deployed to a preview, and is approved by a named person before it reaches production. Changes are kept small, so that review stays meaningful. The AI is fast; the gate keeps it safe. This costs a little speed on each change and saves a great deal of it over the life of a system.

For leaders, the implication is that investment in AI coding tools should come with investment in the practices around them: an explicit AI policy, review capacity, automated testing and a clear map of dependencies. Without these, the tool accelerates the accumulation of problems rather than the delivery of value.

What the evidence cannot yet say

The research base is young and moves quickly. Surveys capture perception, which the METR trial shows can differ sharply from measured effect.⁶ Controlled studies are small (the Stanford security study analysed 47 participants⁸) and hard to repeat, and the latest METR update calls its own signal unreliable.⁷ Security studies test individual samples, not complete systems with review and testing in place. And the tools improve from one quarter to the next.

What does hold across the evidence is the direction: the cost of producing code has fallen, and the value of judgement, verification and responsibility has risen. Teams that plan for that shift get the speed of AI without paying for it later.

Frequently asked questions