AI can help produce code and complete some software tasks faster, but a code change is not the same thing as a finished engineering outcome. The evidence varies by setting and measure; it does not show that the work of understanding a need, fitting a change into a system, and checking its result has disappeared.
Does AI actually make software engineers more productive?
Sometimes, on some measures. The studies available by 2026 do not point to one universal productivity effect: they examine different developers, tools, tasks, and outcomes. A task completed is not necessarily a measure of total time spent delivering, validating, and maintaining a change.
As an Amazon Associate I earn from qualifying purchases.
| Evidence | Setting and measure | What the result does—and does not—show |
|---|---|---|
| DORA’s 2025 report and Google Research’s report page | DORA combined more than 100 hours of qualitative research with survey responses from nearly 5,000 technology professionals worldwide. | DORA’s synthesis describes AI as an amplifier of an organization’s existing strengths and weaknesses. This is a broad organizational interpretation, not a universal causal estimate of how much faster AI makes an individual engineer. |
| METR’s early-2025 randomized trial | Experienced contributors worked on tasks in established open-source repositories; the study measured time to complete tasks with and without AI tools. | For those participants, tools, tasks, and that study period, AI use made tasks take 19% longer, with a confidence interval from 2% to 39% longer. The result should not be generalized to all developers or workplace projects. |
| Three workplace experiments reported in *Management Science* in 2026 | Randomized experiments at Microsoft, Accenture, and an anonymous Fortune 100 company; the combined analysis covered 4,867 developers and measured completed tasks. | Access to generative AI coding assistants was associated with a 26.08% increase in completed tasks, with a standard error of 10.3%. Less experienced developers had higher adoption rates and greater gains. This is a task-completion finding in those workplace experiments, not proof that every part of engineering took less time. |
| Microsoft Research’s workplace study | A randomized controlled trial examined developers’ experiences using generative AI coding tools at work. | With sustained use, developers’ perceptions of the tools as useful and enjoyable increased, while views about generated-code trustworthiness did not change. The study summary says 84% of participants reported positive changes in daily work practices. These are reported perceptions and experiences, not a code-safety or defect-rate result. |
These findings cannot be averaged into a single AI productivity percentage. METR measured time on a particular set of tasks; the workplace experiments measured completed tasks in different organizations. DORA offers a broader synthesis, and Microsoft Research reports on developers’ experiences and perceptions. Each answers a different question.
Why do some AI coding studies show slower work while others show gains?
The results are not necessarily contradictory. A tool can help one group finish more assigned tasks while slowing another group on unfamiliar or demanding work. The studies differ in at least four important ways:
#1 Best Overall
- Work context: METR studied experienced open-source contributors working in established repositories. The *Management Science* experiments took place in workplace deployments at three companies.
- Participants: METR’s participants were experienced contributors; the workplace experiments covered broader developer populations, with larger gains among less experienced developers.
- Outcome: Time spent per task and the number of tasks completed are not interchangeable. Neither measure alone captures every activity involved in getting a change safely into use.
- Tools and period: The studies took place at different times and examined the tools available in their respective settings. Results from an earlier tool environment need not describe later use.
METR’s later update is especially important when interpreting newer productivity estimates. In 2026, the organization said its subsequent experiment gave an unreliable signal of the current productivity effect because of selection and time-measurement problems. METR reported that 30% to 50% of developers it surveyed said they had chosen not to submit some tasks because they did not want to do them without AI; that figure describes selection in this study, not the share of developers generally who use AI. The researchers also said time was difficult to measure for some developers using concurrent agents. They believed developers were likely more sped up in early 2026 than METR’s early-2025 estimate suggested, but described the evidence for the size of the increase as weak. METR’s update explains the design change and limitations.
If AI writes the code, what work is left for the engineer?
Generating a plausible implementation is one part of a software change, not a definition of the whole job. The remaining work depends on the request and the system, but commonly includes:
- Establishing the real need: Work out what problem a change should solve, what behavior users or other systems depend on, and what constraints apply.
- Supplying system context: Identify relevant interfaces, conventions, dependencies, and existing behavior. An implementation that looks reasonable in isolation may not fit its surrounding codebase.
- Choosing and integrating a solution: Decide whether a proposed change is appropriate, connect it to the rest of the system, and handle cases the initial request may not spell out.
- Checking behavior: Evaluate whether the change does what it is meant to do, including relevant edge cases and interactions. Code generation by itself does not establish correctness.
- Taking responsibility for the result: Make a judgment about whether the change is ready for its intended use and what follow-up it may require.
An AI assistant may help with some of these activities, just as it may draft code. But the cited studies do not measure the complete engineering lifecycle or establish how much of this work has been eliminated. Faster production of a patch is meaningful only if the patch addresses the right problem and its result holds up in context.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Can you trust AI-generated code without reviewing it?
The evidence here does not establish that generated code is inherently unsafe, nor does it establish that it is safe to accept without checking. Microsoft Research found no change in participants’ perceptions of generated-code trustworthiness during sustained tool use. That is a finding about perception, not a technical assessment of correctness, security, defects, or long-term maintenance.
Review should therefore be tied to the change’s purpose and consequences, rather than to confidence in the tool alone. A useful evaluation asks whether the implementation matches the intended behavior, fits the system, and has been checked in ways appropriate to its risk. The studies cited here do not prescribe one review process or show that one uniform level of review is sufficient for every change.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How should a team tell whether AI is saving engineering effort?
Start by being precise about what “productivity” means. If the question is whether AI helps produce more code, track that separately from whether it helps deliver useful changes. If the question is whether it saves engineering time, task counts alone are not enough.
- Define the outcome: Decide whether you care about task completion, time to a usable change, or effort across implementation and evaluation. Do not treat one as a substitute for another.
- Compare like with like: Separate task types, experience levels, and work contexts. A result from one group or repository may not transfer to another.
- Include work after generation: Account for the time spent understanding, integrating, checking, and revising a change when those activities matter to your question.
- Watch for what the measure misses: People may select different tasks when a tool is available, and time can be hard to attribute when multiple agents or tools are used concurrently.
- Interpret results at their actual scope: A gain in completed tasks supports a claim about task completion under the measured conditions; it does not, on its own, prove an equal gain in end-to-end delivery or a reduction in total engineering effort.
The practical conclusion is not that AI has no productivity benefit, or that it removes no work. It is that producing code is easier to count than completing engineering. The available evidence shows gains in some workplace settings, slower task completion in one early-2025 study of experienced open-source contributors, and substantial limits on what those measures say about the whole job.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
