Editorial clarification r6 · 8 August 2026: the issue now connects its analysis to precise Practicum worksheets. Facts, sources and the overall conclusion remain unchanged.
AI can speed up writing, analysis or code without speeding up the work as a whole. This issue looks at why local productivity and system outcomes diverge, and what to measure instead of generated lines.
What actually changed
In DORA's software-delivery research, a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. The authors also observed improvements in documentation, code quality and review speed. Source: DORA, "Impact of Generative AI in Software Development", 2024.
This does not prove that AI caused the decline. DORA reports an observed relationship in a specific domain: software development and delivery. The result still matters because a faster individual step does not guarantee a faster or more reliable flow of work.
What became cheaper, and what became more valuable
Producing a first version became cheaper: a function, test, document or explanation. Framing the task, checking changes, managing dependencies and preventing extra output from becoming a queue of unfinished work became more valuable.
The issue's conclusion: AI often moves the constraint. Once production accelerates, review, integration, release decisions or rework may become the limiting step.
Three signals to verify
- −1.5% delivery throughput was associated with a 25% increase in AI adoption in DORA's data. This describes the flow of changes, not typing speed. Source: DORA, "Impact of Generative AI in Software Development", 2024. Before expanding AI access, record baseline cycle time and review-queue time for one task type; compare those with the full path to an accepted change, not with generated lines.
- −7.2% delivery stability was observed with the same increase in adoption. The authors point to larger changes as a possible risk: AI makes it easier to produce more code that still requires verification. Source: DORA, "Impact of Generative AI in Software Development", 2024. Limit the size of AI proposals and name a reproducible test, review and rollback before the pilot; if returns or post-release errors rise, stop scaling rather than generating faster.
- In METR's early randomized study, 16 experienced open-source developers completed 246 tasks 19% more slowly with AI, despite expecting to be faster. METR now explicitly describes that result as becoming outdated for newer tools. Its follow-up covered 57 developers, 143 repositories and more than 800 tasks, but strong selection effects in AI use prevent a reliable estimate of the effect size. Sources: METR's early study, 2025 and METR's update, 2026. Run a short A/B pilot in a familiar stack with preselected quality, cycle-time and rework measures; buy or renew the tool only on the result in that process, not on an expectation of speed.
How to read it
DORA studies organizations and software delivery; METR studies experienced developers working in familiar repositories. The results cannot be generalized to every profession or combined into one universal number. They support a narrower claim: the measured effect depends on the boundary of the measurement and on where the new control point appears.
What it changes for people and work
- Professional: measure time from an accepted task to an accepted result, including verification and rework, not the feeling of speed.
- Manager: more drafts are not more throughput. Watch the review queue, cycle time, return rate and failures after release.
- Team: agree which changes AI may prepare directly and where an independent reviewer and an explicit definition of done are required.
What it changes for teams and business
Buying an AI tool is not a process redesign. If approvals, work-in-progress limits and ownership of the release remain unchanged, extra output merely fills the queue faster. Economic value appears when the team redesigns the whole path to the outcome.
Working map for the week
| Decision | When it fits | First move | Boundary |
|---|---|---|---|
| Expand AI access | A task type repeats | Measure cycle time, review, returns and errors for two weeks before the pilot | Do not treat typing speed as flow |
| Let the model prepare changes | Tests and review exist | Limit proposal size and name a test, reviewer and rollback | Do not scale when returns or post-release errors rise |
| Buy or renew a tool | Comparable tasks are available | Run a short A/B pilot in a familiar stack | Do not pay for an expectation of speed instead of a process result |
Continue in the Practicum
Do not begin with a purchase or a blanket permission to use AI. First run one process through the Volume 2 workbook: it separates tasks the machine may take, tasks under review and tasks whose decision stays with a person. For the chosen mode, build an Volume 2 workbook so quality and rework are measured before scaling, not explained after release.
One sensible next move
Choose one repeatable task type and measure four things for two weeks: total cycle time, verification time, return rate and failures after use. Then enable AI for two more weeks on comparable tasks. If production gets faster but the total cycle does not, find the moved constraint instead of asking the model to generate even faster.
Confidence and sources
DORA reports an association, not a causal effect. METR's early study was randomized but small and used early-2025 tools; the larger follow-up is affected by self-selection. The moved-constraint conclusion is the Practicum's editorial interpretation and should be tested in the reader's own process.