Sources checked on 12 October 2026.
Imagine a product team reviewing its first month with AI agents. Engineers are submitting more changes. Tasks that once occupied an afternoon now produce a working draft before lunch. The adoption report looks encouraging.
Then someone asks when the customer will receive the feature.
The change is waiting for review. Another needs a decision about how it should behave. A third passed its tests, but nobody has checked whether those tests cover the customer’s problem. The team has accelerated several pieces of work. The delivery date has barely moved.
For a leader deciding where to invest next, that gap deserves a closer look. The useful question is how much of the time saved survives the rest of the process.
Read the productivity numbers carefully
Fiona Chen and James Stratton analysed roughly 300 million work events across 718 Jellyfish client firms, covering January 2021 to March 2026. Their August working paper compares firms adopting AI tools at different times. Following AI-agent adoption, they estimated these changes. [1]
Completed issues and projects showed small positive changes that were not statistically significant. More code therefore did not translate into a clearly measurable increase in completed software work. [1]
The 49% measures calendar time, including waiting and revisions. It does not mean reviewers spent 49% more hours reading code. The observational design relies on assumptions about comparable trends, and the sample consists of consenting platform customers. Models released after March fall outside its observation window. [1]
Those limits leave room for a practical question: where does work accumulate after a team makes one stage faster?
Follow the work after the demo
A demonstration usually ends when the tool produces something impressive. An organisation has to keep going.
Consider an illustrative sales workflow. An assistant prepares a proposal in minutes. Before it reaches the client, someone checks the pricing, confirms the delivery promise and approves an exception. If the exception still waits until Thursday’s management meeting, faster drafting may have little effect on the date the client receives an answer.
That example is an extension of the argument, not a finding from the software study. Its value is diagnostic. It gives a leader somewhere specific to look.
Choose a recent piece of work and reconstruct its route. When did preparation begin? When was a usable draft ready? When did somebody review it? What sent it back? When did the customer receive the result?
This separates the time spent doing the work from the time spent waiting for the organisation to act. It also makes the next investment more concrete. A better model might help with preparation. A clearer approval rule might address the delay that actually matters.
There is a leadership decision inside that distinction. Someone has to decide which exceptions genuinely need a senior person and which can proceed under agreed conditions. Leaving every decision at the same approval level can consume the capacity that faster production creates.
There are gains worth pursuing
Evidence from another setting shows why the conclusion should remain specific.
In Generative AI at Work, Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied an AI assistant used by 5,172 customer-support agents. Productivity, measured as customer issues resolved per hour, increased by 15% on average. The effects varied substantially across workers. This was a study within one company, not a forecast for every business. [2]
The outcome measure matters. A resolved customer issue is closer to the purpose of a support operation than the number of suggested replies the assistant generates.
A company evaluating its own tools can make the same distinction. For a proposal assistant, count proposals that reach clients and track the time they take. For a research assistant, examine whether its work supports a decision that somebody can defend. For a product team, follow changes through to use by customers.
Activity measures still have a place. They can show whether people use the tool and where production has increased. They need to sit beside measures of completion and quality, so the company can see what the extra activity accomplishes.
Budget for the organisation around the tool
The purchase is often the easiest part of an AI programme to describe. It has a vendor, a price and a renewal date. Changes to responsibilities, approval rules and working methods are harder to put on the same procurement sheet.
The research on the Productivity J-Curve offers a useful lens. Brynjolfsson, Daniel Rock and Chad Syverson explain how technologies such as AI require complementary investments, often in intangible assets that are poorly measured. Their model helps explain why measured productivity can lag while those investments are being built. [3]
For an AI rollout, a reasonable proposal is to make the surrounding work explicit. Who owns the workflow? Who can change it? How much time is available to improve the handoffs? What evidence will justify expanding the rollout?
Suppose a pilot exposes repeated uncertainty about what counts as an acceptable result. The team could give reviewers clearer acceptance criteria and require each submission to include the evidence needed to assess it. It could also reduce the number of changes in progress while it clears the existing queue.
These are interventions to test. Their usefulness will depend on the workflow. The point is to give them an owner and a measure, instead of expecting them to happen somewhere outside the AI budget.
Innovation needs room to finish
Cheap generation gives an innovation team more possibilities to consider. That can be valuable when the team is exploring a problem.
Evaluation still needs attention. A prototype needs a user, an experiment needs a question, and a promising result needs somebody with authority to act on it. Producing more candidates creates an opportunity only if the organisation can examine them well enough to choose.
One way to use the saved time is to protect it for that examination. If AI shortens prototype preparation, reserve some of the recovered capacity for customer testing before increasing the number of prototypes. Decide in advance what evidence would justify continuing, changing direction or stopping.
That gives innovation a route beyond the presentation. It also makes success easier to assess. The team can point to something it discovered, a decision it changed or a product it delivered.
For the next AI review, bring one completed piece of work alongside the adoption dashboard. Show where time was saved, where it was spent again and when the result reached the person who needed it. Then use that evidence to choose the next change.
For your next AI review
Time saved | Time spent later | Delivery date |
|---|---|---|
Where did preparation get faster? | Where did the work wait or come back for review? | When did the result reach the person who needed it? |
The next AI investment should have to explain how that date moves.
Sources
[1] Fiona Chen and James Stratton: Artificial Intelligence in the Firm: Bottlenecks in Software Production. Working paper, version dated 4 August 2026. Software production, review duration and research limitations.
[2] Erik Brynjolfsson, Danielle Li and Lindsey Raymond: Generative AI at Work. The Quarterly Journal of Economics, May 2025. Customer-support productivity.
[3] Erik Brynjolfsson, Daniel Rock and Chad Syverson: The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. American Economic Journal: Macroeconomics, January 2021. Complementary investment and productivity measurement.
One email when we publish. Research, product decisions, and what teams report back.
