The AI Productivity Paradox: Faster Drafts, Same Delivery Date

The Fortune coverage of AI’s productivity paradox draws on a February 2026 working paper surveying almost 6,000 executives in the US, UK, Germany, and Australia. Averaging across those countries, 69% of firms reported using AI and 89% reported no effect on labor productivity, measured as sales volume per employee, over the previous three years.

Those are executives’ estimates across whole firms, including firms that don’t use AI, and the technologies range from text generation to robotics. They leave open a practical question for your team: was useful time saved, and where did it go? An approval backlog is one possible answer. A tool that creates as much checking work as it saves is another.

The Thursday Meeting Still Happens Thursday

Consider a release that can be approved only at the Thursday 2pm meeting. Suppose AI gets the draft finished on Tuesday instead of Wednesday, but either version would enter the same meeting. The document still needs the same approvals. The Thursday 2pm meeting still happens Thursday at 2pm. The work got drafted faster; its earliest approved release date didn’t move.

The engineer may have recovered time for testing or another task. That saving deserves to be counted even if payroll stays the same. Whether it buys additional output depends on what gets finished with the time. A shorter drafting step, a shorter customer wait, and a lower cost are different results.

Change the premise and the answer changes. If faster drafting gets a release into this Thursday’s meeting instead of the next one, it can improve delivery without changing the approval process at all. You need the change history before you need a new org chart.

Volume adds another wrinkle. If reviewers already have more changes than they can clear, and their capacity stays fixed, generating more drafts increases the queue. The team can spend less effort writing each change while making changes wait longer to ship. The constraint may have moved to review, or review may have been the limit all along. An adoption chart can’t distinguish those cases.

Check the Saving Before Reorganizing Around It

In METR’s July 2025 randomized study, 16 experienced open-source developers completed 246 tasks in projects they knew well. Allowing early-2025 AI tools increased completion time by 19%. Afterward, the developers still estimated that AI had reduced their time by 20%.

That result belongs to those developers, tasks, and tools. It doesn’t forecast what newer models will do in your codebase. It does challenge the assumption that a faster-feeling workflow has saved effort. Before blaming the review queue, include the time spent prompting, inspecting output, correcting it, and getting the change through the same quality checks as unassisted work.

There is also evidence of gains reaching the finished task. In the 2024 working paper Generative AI at Work, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied a staggered rollout of an assistant to customer-support agents serving one software company. Their dataset covered 5,172 agents. For the subset with resolution data, they estimated a 15% increase in issues resolved per hour with AI assistance.

The assistant supplied suggested replies and relevant technical documentation during customer conversations. It had been trained on past customer-agent conversations, including examples from strong performers. The human agent could edit or ignore its suggestions and retained the final decision over what to send. A useful suggestion could become a customer response inside the same conversation.

Our reading is that this arrangement gives a task-level saving a direct route into completed work. The study doesn’t isolate that arrangement as the cause of the gain; the model and its task-specific training came with it. Nor did everybody benefit equally: less-experienced workers gained more, while the most skilled agents saw small declines in conversation quality. Copying the tool would give you none of those results by right.

Change What the Work Is Waiting For

Take one recurring kind of change and trace it from an agreed request to something a customer can use. Compare similar assisted and unassisted work with the same acceptance criteria, choosing the comparison before you know which changes went well. A few easy AI-assisted changes against a difficult unassisted project won’t tell you much.

Count active effort across the author, reviewers and anyone correcting the result, including discarded attempts. For comparable accepted work, subtract assisted effort from unassisted effort to estimate the labor saving. Record that effort as it happens. A ticket’s open and close dates can’t tell you how much of the interval somebody spent working.

Use the change history for a different measurement: when the draft reached review, when review began, when it was accepted, and when the customer could use it. If a reviewer finds missing test results, separate the time spent waiting for review from the work needed to supply them. Otherwise, you can mistake an unfinished change for one held up only by approval.

If the finished change and its evidence were ready on Tuesday but release still waits for Thursday, the next question belongs to whoever owns that approval. Could they review the evidence when it’s ready? Could a smaller, independently releasable change meet the same requirements? Where a customer commitment or a genuine risk requires the gate, keep the protection and be explicit about the delivery limit.

That alternative needs the same scrutiny as the AI tool. If reviewing on demand repeatedly interrupts the engineers who must finish other work, the earlier approval may come at another change’s expense. Compare total effort, corrections and customer delivery dates before crediting the new process.

If review is consuming the saving, improving the input may be cheaper than adding reviewers: clearer acceptance criteria, a narrower change, or evidence that lets a reviewer check the result without reconstructing the whole task. Count the effort spent preparing that evidence too. If the tool still adds net work, use a different approach for that task. Your existing team can investigate these choices without another software purchase.

Less effort and lower spend also need separate accounts. If salaries stay the same, recovered time is capacity the team can use elsewhere. For a cash-saving claim, identify the expense that actually fell, then include the tool and setup costs before reporting a net saving.

Bring finance the change history next time. If the result is less effort for the same delivery date, say that, including what the recovered capacity was used for. If the promise was faster delivery, point to the completed change that reached a customer earlier. Keep the adoption dashboard for the question it can answer: whether people are using the tool.