AI coding tools have crossed an important boundary. They no longer merely predict the next line. They explain unfamiliar repositories, propose multi-file changes, write tests, review pull requests, and, increasingly, take an issue and return a draft patch. GitHub’s asynchronous coding agent, announced in May 2025, made that shift concrete: an assigned task can run in a separate environment and produce commits in a draft pull request for a person to inspect (GitHub).
That changes software development less by eliminating programmers than by redistributing their attention. Producing a plausible first draft becomes cheaper. Specifying the right problem, supplying context, judging tradeoffs, and proving that a change is safe become more valuable.
A productivity gain—but not a universal one
The strongest early evidence showed real gains on bounded work. In GitHub’s randomized experiment with 95 professional developers, participants asked to build the same JavaScript HTTP server finished with Copilot in 1 hour 11 minutes on average, versus 2 hours 41 minutes without it. GitHub summarized the result as “55% faster than the developers who didn’t”. Completion rates were 78% and 70%, respectively.
Adoption subsequently ran ahead of settled evidence. Stack Overflow’s 2025 survey, based on more than 49,000 responses, found that 84% of respondents were using or planning to use AI tools in development and 51% of professional developers used them daily. Yet 46% distrusted AI accuracy, compared with 33% who trusted it (Stack Overflow). That combination—heavy use and limited trust—captures the new workflow.
Results also vary sharply by task and user. A 2025 randomized study from METR followed 16 experienced open-source developers completing 246 real issues in repositories they knew well. With then-current AI tools, they took 19% longer, even though they expected to be faster and still perceived a speedup afterward (METR). The study was narrow, but its lesson is broad: speed on a greenfield exercise cannot be assumed to transfer to mature codebases with tacit conventions and high review costs.
The bottleneck moves to verification
When generating code is inexpensive, reviewing it can become the scarce resource. An assistant may create a correct-looking change that mishandles an edge case, duplicates an existing abstraction, introduces an outdated dependency, or silently broadens access to sensitive data. The reviewer must understand both the output and the surrounding system well enough to detect what is missing.
That helps explain an apparent contradiction in Google’s 2024 DORA research. Greater AI adoption was associated with higher individual productivity, flow, and job satisfaction, but a 25% increase in AI use was also associated with an estimated 1.5% reduction in delivery throughput and a 7.2% decline in delivery stability (DORA). Faster local code production can enlarge batches, increase review queues, and expose weak testing or release practices.
The practical response is not to ban generated code. It is to strengthen the system around it. Teams need reproducible tests, small changes, protected branches, dependency and secret scanning, clear ownership, and traceable human approval. NIST’s Secure Software Development Framework already organizes this work around preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities (NIST). AI raises the volume and pace; it does not remove those obligations.
Expertise shifts up the stack
Entry-level work will change most visibly. Boilerplate, basic migrations, documentation drafts, and routine test scaffolding can now be produced quickly. That may reduce some traditional apprenticeship tasks, but it also creates a training problem: developers still need the mental models required to challenge an answer. Organizations that automate junior work without replacing its learning value may save time today and weaken their future review capacity.
Senior engineers are not exempt. Their advantage increasingly lies in architecture, domain knowledge, failure analysis, and knowing when a superficially reasonable solution violates a non-obvious constraint. Prompting matters, but durable value comes from turning ambiguous business needs into verifiable technical specifications.
The right unit of measurement is therefore not lines written or suggestions accepted. Teams should track lead time, escaped defects, change-failure rate, review burden, security findings, and maintainability over months. They should compare performance by task category, because an assistant that accelerates isolated test writing may slow a repository-wide refactor.
AI coding assistants are rewriting development as a control problem: machines can propose more changes than humans could previously author, while humans remain accountable for what ships. The teams that benefit most will not be those that generate the most code. They will be those that turn abundant generation into reliable software without losing understanding of the systems they maintain.