AI coding changes the demand for review and engineering practice

Company experiments and open-source research measure different development settings. Teams still have to fund the route from a plausible draft to an accepted, maintainable change.

Software teams do not deliver value when a draft is generated; they deliver a change that works in its intended environment and can be maintained. AI can shift effort from typing code toward specifying a task, checking assumptions and reviewing a larger supply of proposed changes. That creates a workforce question about review capacity and learning. A team that measures only completed tickets may miss the work accumulating around them, while a team that dismisses every useful completion may ignore a real opportunity to remove repetitive effort.

[Microsoft Research's June 2025 account of three field experiments](https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/) describes randomised access to a coding assistant at Microsoft, Accenture and an unnamed Fortune 100 company. The combined analysis covered 4,867 developers and estimated a 26.08% increase in completed tasks, with noisy individual experiments and larger gains among less experienced developers. This is evidence about measured work in those settings, not a universal forecast for software employment or a finding that every additional completed task creates equivalent long-term value.

Other settings produce different results. [METR's July 2025 study](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) found that experienced open-source developers working in familiar repositories took 19% longer when allowed the studied AI tools. That result is tied to its participants, tasks and early-2025 tools. It does not establish that AI generally slows software work. The contrast with the company experiments is a reason to examine the work and population being measured, rather than selecting whichever percentage supports an existing staffing plan.

The evidence also changes over time. In its [24 February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/), METR said selection problems made its newer experiment an unreliable signal of the current productivity effect. Developers' reluctance to participate without AI could bias the estimate. The update is not a clean demonstration of a new universal speedup or slowdown. As checked for this article on 16 October 2026, these sources support qualified, setting-specific conclusions. They do not justify replacing an actual team's measurements with a historical headline.

Consider an explicitly fictional software team working across Bengaluru and Berlin. A junior developer uses an approved assistant to propose a change to a synthetic service's retry behaviour. The code looks plausible and passes a simple test, but a maintainer notices that retrying after an uncertain response could duplicate an operation. The team adds a test for that case and narrows the change. This is an illustrative development exercise, not a vulnerability report or a claim about a named product. The learning lies in explaining the failure condition, not producing more code.

The employer can recognise several responsibilities in that small example. Someone specifies the intended behaviour and boundaries. Someone implements the candidate change. Someone reviews tests, dependencies and assumptions. Someone decides whether the change is suitable to release. One person may perform more than one role, but the responsibilities should not vanish because an assistant produced the first draft. A staffing model that assumes all implementation time is interchangeable with review time risks creating a bottleneck among the people authorised and experienced enough to accept changes.

For workers, the development path should include practice in those responsibilities. A newer developer can learn to write a failing test, trace an unfamiliar function and explain why a suggestion was rejected. A maintainer can teach how local constraints differ from a generic coding example. The team should preserve some exercises without assistance, so that it can see whether people can reason about the system when suggestions are unavailable. These are proposed training choices, not research findings that a particular course improves hiring prospects or guarantees a promotion.

The workload measures need to follow a change past its first completion. A local assessment could record review effort, reopened issues, escaped defects, dependency changes and time until a maintained release. It should distinguish a small routine edit from a change crossing several systems. The relevant comparison includes time spent reading suggestions and repairing an unsuitable approach. No single measure should become a hidden incentive to split work into ever-smaller tickets or accept code whose future maintenance falls on somebody else's shift. Those are work-design risks to investigate, not effects proved by the cited experiments.

Hiring decisions deserve similarly explicit assumptions. An employer might decide to preserve apprenticeship tasks, create supervised review rotations or invest in better test infrastructure. It might also change staffing if its own evidence and demand justify that decision. The studies do not choose among those options. A company should explain whether it expects more output, shorter queues, improved reliability or a different cost structure, then evaluate that expectation. Workers should be able to ask how newly required verification skills will be supported and recognised, rather than being told only to become faster.

Geography and organisational setting matter. A distributed product team, a small agency maintaining old customer systems and an open-source maintainer can face different access, review and release constraints. The fictional Bengaluru–Berlin team cannot treat a corporate experiment as a result for all Indian or German developers. Its permitted tools, repository context and obligations to customers have to be specified. A model's general coding benchmark also cannot establish the outcome of its particular development process. The comparison should stay close to the actual work people are expected to perform.

Companies can begin by examining where proposed changes wait today and who carries the cost of a mistaken acceptance. Workers can build evidence of judgment through reviewed tests, clear explanations and well-documented decisions to reject unsuitable suggestions. A useful assistant may broaden what a developer can attempt, but that opportunity needs a route to reliable acceptance. The durable workforce question is how the team develops and funds that route. Faster drafting and stronger engineering can coexist; the connection between them has to be designed and measured rather than assumed.

Evidence diagram and readable guide


Original explanatory infographic: Different studies measure different software work. The final acceptance exercise is editorial proposed practice, not a measured gain or employment forecast.

[Open the complete evidence diagram](/assets/future-work-workflow-software-review-capacity-20261016.svg)

Read the diagram

**AI coding changes the demand for review and engineering practice**

Different studies measure different software work. The final acceptance exercise is editorial proposed practice, not a measured gain or employment forecast.

- **Different software settings** Keep company task-completion experiments separate from familiar open-source repository work.

- **Company experiments** 4,867 developers; combined estimate 26.08% more completed tasks in the June 2025 account.

- **Familiar repository study** The July 2025 METR report found 19% longer completion time with the studied early-2025 tools.

- **Current-effect limitation** METR February 2026 describes selection problems and an unreliable newer signal; no universal current estimate follows.

- **Proposed acceptance exercise** Review the fictional retry change and test the uncertain-response duplicate-operation case.

- **Fund review and practice** Keep maintainer acceptance and supervised engineering learning visible in the work plan.

Completed tasks and elapsed implementation time are unlike units from different populations. Do not subtract, average, pool or rank these figures.

How the connections work

- The setting boundary identifies what the company completed-task estimate measures.

- The boundary separately identifies the familiar-repository elapsed-time measure.

- The company estimate remains historical and setting-specific when discussing a current effect.

- The repository result is read alongside the later selection-limit update.

- The evidence limitation motivates a proposed local acceptance exercise, not a claimed speed gain.

- The proposed acceptance exercise makes review and learning responsibilities visible.

Relationship key

Solid arrows show the stated evidence or proposed information handoff. Dashed arrows mark an editorial bridge or return for review. They do not show a measured causal effect. Shapes distinguish records, boundaries, processes, review questions and authority limits.

Diagram references

- [The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers](https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/)

- [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

- [We are Changing our Developer Productivity Experiment Design](https://metr.org/blog/2026-02-24-uplift-update/)