How AI Is Changing Software Development and Code Review

Artificial intelligence now accelerates the drafting phase of software development, from explaining an unfamiliar module to producing tests and implementation code. The durable change is not autonomous software creation, however: developers are moving from writing every line toward specifying intent, reviewing generated work and deciding whether it is safe to ship.

That distinction matters because faster code production does not automatically mean faster software delivery. Recent evidence suggests that AI can remove friction from bounded tasks while transferring effort into verification, integration and maintenance. Its impact therefore depends less on how much text or code a model produces than on the quality of the engineering system around it.

The productivity question no longer has one credible percentage

Claims that an AI assistant makes every developer a fixed percentage faster confuse several different kinds of work. Generating a small function in a controlled exercise, changing a mature repository, reviewing a pull request and operating a production service are not interchangeable tasks. A measured improvement in one setting should not be presented as a universal result.

The changing evidence is unusually clear in METR’s work with experienced open-source contributors. Its early-2025 experiment found that AI-allowed tasks took 19% longer, but a later study produced apparent speedups while losing the conditions needed for a reliable causal estimate: developers increasingly declined work without AI, selectively withheld tasks they especially wanted AI to handle and sometimes ran multiple agents concurrently. In February 2026, METR’s follow-up assessment said developers were probably benefiting more than in early 2025, while stressing that selection effects made the size of that improvement weakly supported.

The responsible conclusion is not that AI always slows development or that it now guarantees a speedup. It is that capability and working habits are changing faster than a single benchmark can describe. Teams need measurements tied to their own repositories, task mix and definition of completed work.

Where AI changes the development lifecycle

AI has its clearest role as a drafting and navigation layer. A developer can use it to summarize unfamiliar code, locate likely dependencies, propose an implementation, create test cases or turn notes into documentation. These uses reduce the cost of reaching a first candidate solution, especially when the task has clear boundaries and the relevant context is available.

The effect becomes less predictable as work approaches production. Generated code still has to match local architecture, security requirements, data contracts, performance constraints and undocumented operational knowledge. A plausible patch can compile and pass narrow tests while misunderstanding the product requirement or creating a failure that appears only under real traffic.

DORA’s March 2026 analysis captures this split: its 2025 research found that 90% of technology professionals used AI at work and more than 80% believed it improved their productivity, while higher adoption was associated with both greater delivery throughput and greater delivery instability. A qualitative review of 1,110 Google engineers’ responses also found recurring value in code generation, information seeking, review and testing, alongside verification overhead across all examined use cases.

This makes AI an amplifier of the surrounding workflow. Strong automated tests, small changes, readable interfaces and current documentation give a coding agent useful constraints. Weak ownership, oversized pull requests and fragile deployment practices let it produce uncertainty at greater speed.

The developer’s role shifts toward specification and judgment

Developers will still write code, but typing syntax becomes a smaller share of the valuable work when a model can produce a reasonable first pass. More effort moves upstream into framing the problem and downstream into proving that the result satisfies it. Precise acceptance criteria, architectural boundaries and explicit non-functional requirements become productive inputs rather than administrative overhead.

Review also changes in character. Checking generated work is not equivalent to reviewing a familiar colleague’s patch: the output may be fluent without reflecting a stable mental model of the system. Reviewers must reconstruct assumptions, examine edge cases and verify that tests would fail for the right reasons. When generated changes are large, the reviewer becomes the bottleneck even if the author finishes quickly.

This raises the value of skills that models cannot independently own: choosing trade-offs, resolving ambiguous requirements, investigating production behavior and accepting responsibility for a release. Domain knowledge becomes more important, not less, because it lets a developer detect when an answer is locally wrong despite looking technically polished.

Trust remains the practical limit

Adoption is already broader than confidence. The 2025 Stack Overflow Developer Survey found that 84% of respondents used or planned to use AI in development, yet 46% distrusted its accuracy and 33% trusted it. The most common frustration, reported by 66%, was receiving a solution that was almost correct; 45% cited the extra time required to debug generated code. Respondents were also notably reluctant to delegate deployment, monitoring and project planning.

Those findings explain why human oversight is not a temporary formality. Software can affect payments, personal data, physical operations and access to essential services. A model cannot carry organizational accountability for a vulnerability, an incorrect migration or an outage, so the team deploying the change must retain an auditable path from requirement to verification.

For proprietary projects, trust also includes data handling. Teams should decide which source code, logs, credentials and customer records may be exposed to a tool before enabling it across a repository. Technical controls should enforce that decision; a policy that depends entirely on every developer remembering which prompt is safe will fail under routine pressure.

How teams can capture speed without moving the bottleneck

The useful unit of measurement is a delivered, reliable change—not generated lines, accepted suggestions or prompts submitted. A team evaluating AI assistance should compare similar work over time and observe the entire path from task selection to production. Otherwise, a shorter coding interval can conceal longer review queues, added rework or more incidents.

Start with bounded work. Documentation drafts, test scaffolding, repetitive transformations and well-specified fixes are easier to verify than architectural decisions or unfamiliar security-sensitive code.
Keep changes small. A compact patch lets a reviewer understand the intended behavior and identify unsupported additions before they spread across the codebase.
Require independent checks. Generated tests should not be the only evidence for generated implementation. Existing regression suites, static analysis, security scanning and human review provide different failure signals.
Measure downstream effects. Review time, change failure, rollback, escaped defects and maintenance effort reveal whether local drafting speed survives the rest of delivery.
Preserve learning. Junior developers need opportunities to reason through failures and design choices rather than accepting outputs they cannot explain.

For solo developers and small product teams, the same logic applies at a different scale. AI can make a prototype affordable and shorten the path from an idea to something users can try. But production readiness still includes authentication, backups, observability, accessibility, dependency management and a plan for failures—work that a convincing demo can easily hide.

The lasting impact is a new division of labor

AI is unlikely to affect software development as a single wave of automation. It is creating a new division of labor in which machines generate and search rapidly while people supply context, choose constraints and validate consequences. The balance will continue to shift as agents improve, but the need to connect code with user intent and operational reality remains.

The competitive advantage is therefore not simply access to a coding model. It is the ability to give the model appropriate context, contain its work inside reviewable boundaries and obtain fast evidence about correctness. Teams that solve those workflow problems can convert generation speed into delivered value; teams that do not may merely create more code for humans to inspect.

AI Writes Code Faster, but Developers Inherit a Verification Tax