Your Minutes Are the Other Bill: Count the Time You Spend Checking the AI
People overestimate AI's effect on their own time by roughly 40 percentage points on average. That finding comes from METR's early-2025 randomized controlled trial: developers finished the study believing AI had sped them up by 20%, while the measured effect was a 19% slowdown.1 METR restates that gap in exactly those terms — overestimating "AI's effect on their time spent on tasks by 40 percentage points on average" — in its 2026 write-up.2 The API bill shows up in your dashboard. The verification pass shows up nowhere — until you start counting.
This is a piece about the second bill.
The Study Everyone Cited Wrong
In early 2025, sixteen experienced developers completed 246 real tasks in mature open-source repositories — codebases averaging over 22,000 GitHub stars and more than a million lines of code, on projects where the developers already had an average of five years of prior experience.3 The tasks averaged roughly two hours each. Some sessions used AI tools; some did not. Every session was recorded.
The preprint — Becker, Rush, Barnes, and Rein, arXiv:2507.09089v2, July 2025 — found that allowing AI access increased task completion time by 19% (95% CI: +2% to +39%).4
That is not a typo. The direction was negative.
Before the study, developers predicted AI would cut completion time by 24%. After finishing, they estimated AI had reduced their time by 20%.1 The measured effect ran opposite to both estimates. METR described "strong evidence that anecdotal reports/estimates of speed-up can be very inaccurate."5
This result has since been qualified. METR's own blog now carries an explicit banner: these results are out of date, and the researchers believe the 2025 finding no longer reflects the current impact of AI on open-source developer productivity.6 A February 2026 continuation, using more powerful models, found directional improvement — returning developers at −18% (CI: −38% to +9%), new developers at −4% (CI: −15% to +9%) — but both confidence intervals cross zero.7
What is not out of date is the direction of the self-report error. That gap has not closed.
Your Forecast Was Also Wrong
The 19% slowdown measured in 2025 was not a prediction failure by ordinary people guessing blindly.
Expert economists forecast 39% shorter completion times. Expert ML researchers forecast 38% shorter.8 The people with the strongest professional reasons to be calibrated were the farthest off.
The METR 2026 survey — 349 technical workers across February to April, including 87 software engineers, 71 researchers, 129 academics and PhD students, and 48 founders and managers — found a median self-reported value change of 1.4–2x and a median self-reported speed change of 3x.9 These are not minor overestimates.
The 40 percentage point average overestimate documented in the 2025 RCT1 tells you something structural: how you experience AI-assisted work is not the same thing as the clock. Cognitive fluency — the feeling that output arrived fast — is not task completion time. You feel faster because the blank space fills in quickly. Total wall time, which includes prompting, waiting, reading, and checking, is invisible unless you instrument it.
"Reading AI output is extra effort," wrote Niklas Gruhn in August 2026. "Read it, understand it, validate it, and then write a response in your own words."10 That sequence is a clock. Most people are not running it.
Where the Time Actually Goes
The METR study was unusual in recording and labeling every session. Of 128 original recordings — 143 hours of footage — 74 recordings representing 84 hours survived quality filtering and were analyzed.11
The labeled breakdown found that on AI-allowed work, roughly 4% of a developer's time was spent in pure waiting: waiting on AI to generate output. That figure comes from the 44 AI-allowed issues with valid labeled screen recordings.12 Four percent sounds small. But the researchers also found that time did not vanish from elsewhere — it reallocated. Time saved on direct coding was offset by overhead in review, prompting, and waiting.13 The "waiting" bucket was measurable. The "reviewing and re-reading" bucket was embedded in everything else.
Here is why self-report fails specifically on the review bucket: when you estimate how long you spent checking AI output, you are guessing at something that never had a clock on it. The generation felt fast. The reading felt fast. Discovering that the output needed correcting felt like a brief interruption, not a loggable event.
METR noted in their 2026 update that measuring your own time has become harder, not easier, as AI systems grow more capable. With agentic tools running in the background, a developer can genuinely work on an unrelated task while the agent runs — blurring the line between "time I spent" and "time the agent spent."7
The bill is real. The meter is broken.
The Measurement Gap Persists
Sean Goedecke made the relevant point from the opposite direction: "The most important skill in prompting is expertise in the domain you're prompting for."14 The expert is not immune to the time cost — they are better positioned to complete the verification pass quickly. But "quickly" is still a duration that must be counted.
The planning fallacy is the closest documented cousin. When people estimate task completion times, they reliably undercount because they reason from the best case, not from historical averages. The AI version is structurally identical: you remember the sessions where the first output was clean and correct. You discount the sessions where you re-prompted three times, re-read the response twice, and found the error in the fourth paragraph.
What you should track is not hard to define. For every AI-assisted session: log clock time from first prompt to accepted output. Include the reading passes. Include the correction loops. Compare that total against your baseline for equivalent tasks without AI. Run it for two weeks — prospectively, with a timer, not in retrospect.
That converts a feeling into a number.
What to Do About It
The cheapest instrument is a timer running alongside your session. The most useful data point is the ratio of generation time to verification time — how long the model took versus how long you took.
Once you decide to verify a specific claim, the substrate you check against sets the unit price of each check. Verification against files you hold locally — text you can search by exact phrase in seconds — costs far less time per check than re-reading cloud documents you cannot query.
The technique for making that local search both fast and auditable is covered in Make the AI Quote Your Note Before You Believe It. The habit described there converts minutes into seconds per check. It does not eliminate the verification pass; it cuts the cost per unit.
Niklas Gruhn put the underlying calculus plainly: "I can talk to Claude myself. It's going to be faster and I get to control the context."15 That is the judgment at the margin of every AI-assisted task. Some tasks, the AI clears the work. Some tasks, the verification pass costs more than the generation saved. You cannot make that call without the data.
The API bill is already counted. Count the other one.
The invisible meter charges the same rate regardless of whether you read it. Start reading it.
If you keep research notes locally — in plain Markdown files you can search without a login — mnmnote.com is built for that.
Frequently Asked Questions
Does AI actually save time for experienced developers?
The METR 2025 RCT — 16 developers, 246 tasks on their own mature projects, using best-available early-2025 tools — found AI access increased completion time by 19% (95% CI: +2% to +39%). METR's 2026 update notes these results are out of date; a 2026 continuation shows directional improvement with confidence intervals crossing zero. Neither result supports "AI saves experienced developers time" as a general law.
How much time do people spend checking AI output?
The METR labeling study found approximately 4% of a developer's time on AI-allowed work was pure waiting on AI. Time spent reviewing and re-prompting was embedded in the rest of the session and not isolated as a separate measurement — that gap is exactly what this piece addresses.
Why do I feel faster with AI but sometimes take longer?
The METR 2025 study documented this precisely: developers predicted 24% faster before tasks and estimated 20% faster afterward, while measured time ran 19% in the opposite direction. Cognitive fluency — output arriving on screen quickly — does not equal total task completion time.
How should I measure AI productivity honestly?
Log clock time from first prompt to accepted output for AI-assisted sessions, including reading passes and correction loops. Compare against your baseline for equivalent tasks without AI across at least two weeks of prospective logging. Retrospective self-report is insufficient — the METR study shows it can be directionally wrong by 40 percentage points on average.
Is AI making experienced developers faster or slower in 2026?
The 2026 METR continuation study found directional improvement: −18% for returning developers (CI: −38% to +9%), −4% for new developers (CI: −15% to +9%). Both confidence intervals cross zero. Evidence in 2026 is ambiguous rather than negative, but not strong enough to declare a reliable speedup.
What is the hidden cost of using AI for knowledge work?
Minutes spent verifying, re-reading, re-prompting, and correcting. These are metered by your calendar, not by the API. The substrate you check against matters too: verification against locally searchable files costs less per check than re-reading cloud documents you cannot query.
Does expertise change how the time cost works?
Domain expertise makes the verification pass faster — you can assess correctness without relearning the domain from scratch. But expertise does not eliminate the pass; it reduces the cost per unit. The pass still takes time that needs to be counted.
How long does it take to verify AI output for a typical task?
No clean controlled study isolates verification time from total session time. The METR labeling study is the closest available data; it found time reallocated toward review, prompting, and waiting — but did not produce a per-task verification cost. Instrument your own sessions to find out.
Footnotes
-
Becker et al. arXiv:2507.09089v2. Pre-study forecast: "Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%." Post-hoc estimate: "After completing the study, developers estimate that allowing AI reduced completion time by 20%." Measured: "allowing AI actually increases completion time by 19%." The paper reports these as separate figures and does not itself use the phrase "percentage points"; the 40-point average characterization of this study's overestimate is METR's own, stated in 2. ↩ ↩2 ↩3
-
METR. "AI Usage Survey." May 11, 2026. https://metr.org/blog/2026-05-11-ai-usage-survey/ Archived: https://web.archive.org/web/20260804024650/https://metr.org/blog/2026-05-11-ai-usage-survey/ The 40-percentage-point figure appears on this page as METR's restatement of its own earlier study, not as a survey result: "our study in early 2025 found that people overestimated AI's effect on their time spent on tasks by 40 percentage points on average." The originating measurement is the early-2025 RCT — see 3 and 1. ↩ ↩2
-
Becker, Rush, Barnes & Rein. "Measuring the Impact of AI on Experienced Open-Source Developer Productivity." arXiv:2507.09089v2, July 25, 2025. https://arxiv.org/abs/2507.09089v2 Archived: https://web.archive.org/web/20260804024531/https://arxiv.org/abs/2507.09089v2 ↩ ↩2
-
METR. "Measuring the Uplift of AI Models: Update." February 24, 2026. https://metr.org/blog/2026-02-24-uplift-update/ Archived: https://web.archive.org/web/20260804024550/https://metr.org/blog/2026-02-24-uplift-update/ (95% CI +2% to +39% for the 19% estimate from the 2025 RCT.) ↩
-
METR. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." July 10, 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ (Quote verbatim-confirmed against the live page, accessed 2026-08-12.) ↩
-
METR 2025 blog post — staleness banner. See 5. "These results are out of date… We believe these historical results no longer reflect the current impact of AI models on open-source developer productivity." ↩
-
METR. "Measuring the Uplift of AI Models: Update." February 24, 2026. 4. 2026 re-run: returning developers −18% (CI −38% to +9%), new developers −4% (CI −15% to +9%). Also: "those estimates can be quite unreliable." ↩ ↩2
-
Becker et al. arXiv:2507.09089v2. "This slowdown also contradicts predictions from experts in economics (39% shorter) and ML (38% shorter)." ↩
-
METR 2026 survey. 2. "In February–April 2026, we ran a survey of 349 technical workers (including 87 software engineers, 71 researchers, 129 academics and PhD students, and 48 founders and managers)." Median self-reported value change: 1.4–2x. Median self-reported speed change: 3x. ↩
-
Niklas Gruhn. "Don't be a meat proxy." gruhn.me, August 3, 2026. https://gruhn.me/blog/2026-08-03/ Archived: https://web.archive.org/web/20260804024623/https://gruhn.me/blog/2026-08-03/ (Author confirmed via github.com/gruhn/gruhn.me, owner profile: Niklas Gruhn.) ↩
-
Becker et al. arXiv:2507.09089v2 (PDF). 128 recordings / 143 hours labeled; 74 recordings / 84 hours analysed after quality filtering. ↩
-
Becker et al. arXiv:2507.09089v2 (PDF), §C.2.9: "on the subset of 44 issues with valid labeled screen recordings, we find that when AI is allowed, developers spend approximately 4% of their time waiting on AI generated outputs when working with AI." (Re-verified against the v2 PDF, accessed 2026-08-12.) ↩
-
Becker et al. arXiv:2507.09089v2 (PDF). Time reallocated to reviewing, prompting, and waiting — offsets time saved on direct coding. ↩
-
Sean Goedecke. "LLMs Reward Expertise." seangoedecke.com, July 24, 2026. https://seangoedecke.com/llms-reward-expertise/ Archived: https://web.archive.org/web/20260804013253/https://seangoedecke.com/llms-reward-expertise/ ↩