The Productivity Trap: When AI Activity gets Mistaken for Progress
Some organisations are using AI token consumption as a measure of progress.
DORA recently wrote about this pattern under the label “tokenmaxxing”: internal leaderboards, usage targets, and incentives based on how many AI tokens people consume.
The intent is understandable: leaders want people to experiment and avoid a situation in which expensive AI tools are available but go largely unused. They also want visible evidence that the organisation is moving.
But AI usage is not the same as improvement, activity is not the same as progress, and productivity is not the same as flow.
This is not a new problem. Software delivery has always had a habit of reaching for easy-to-count proxies: lines of code, commits, story points, tickets closed, pull requests merged, deployment counts.
Some of those measures can be useful in context, but none of them tells the whole story on their own.
Asking “how many AI tokens were consumed this week” may indicate adoption, but it does not tell us whether the organisation is becoming more effective.
For that, we need to ask a different question: “Where is the work actually flowing better?”
AI can Make Activity Easier to Produce
One reason AI is so compelling is that it reduces the effort required to get started. A test case, document, email, user story, prototype, or implementation option can appear much faster than before.
For many people, the initial activation energy of work is a real source of friction. AI can help people get moving. It can help them externalise thinking, explore alternatives, and move from creation to refinement more quickly.
But when the cost of producing something falls, the amount produced often rises. More things for other people to read, check, review, challenge, approve, integrate, maintain, or explain.
This increase in downstream demand is the productivity trap: a person or team may feel faster locally, while the wider system becomes noisier, busier, or harder to coordinate.
Saved Time does not Automatically Become Realised Value
The idea that “AI saves time” is compelling, but where does the saved time go?
If a developer produces code faster, but review, testing, architecture decisions, security checks, or release governance become overloaded, the system may not deliver value any faster.
If a product manager creates more polished discovery artefacts, but teams still lack clarity about which problem matters most, the organisation may simply produce better-looking ambiguity.
If a leadership team receives faster summaries and more analysis, but decision rights remain unclear, the bottleneck has not been removed. It has just been dressed up in better language.
This is why local productivity is not enough; organisations do not create value through isolated moments of speed; they create value through connected systems of work.
DORA’s Warning is Really a Flow Warning
DORA’s writing on tokenmaxxing warns against mistaking raw AI usage for meaningful performance, but I think the deeper warning is about flow.
If we optimise for token consumption, people will consume more tokens, but that does not mean the right work is moving through the system more effectively.
As I’ve said many times, AI is an amplifier. It magnifies the strengths of organisations that already have strong underlying systems, and the weaknesses of those that do not.
If the system is already unclear, AI may help people move faster inside that lack of clarity. If teams are already overloaded by review and coordination, AI may create more things that need reviewing and coordinating. If decision-making is already slow, AI may generate more inputs into decisions that still do not get made.
In this sense, AI does not just save time; it reveals what the organisation is able to do (or not do) with time saved.
The Work may not Disappear: it may Move
Another useful point from DORA’s recent writing is that AI’s impact on the software delivery lifecycle is not a simple linear improvement.
AI may accelerate initial creation, but some of the saved time is then reallocated to auditing and verification. That matches what many teams are starting to experience: that work does not vanish; rather, it moves.
From writing to reviewing, from implementing to integrating, from generating options to deciding between them. From doing the work manually, to trying to understand whether the AI-assisted version is good enough, safe enough, and aligned enough with the user need.
This changes the shape of work, and the team interactions involved.
Who needs to review AI-generated work?
Where does domain knowledge need to sit?
Which decisions can be made locally?
Which risks need specialist input?
Where does platform support help, and where does it become another dependency?
Where do teams need clearer boundaries, better enabling support, or more explicit decision rights?
These are not tooling questions, they are organisational design questions.
Better Questions Than “How Much AI Are We Using?”
I am not arguing that adoption metrics are useless.
In the early stages, it may be perfectly reasonable to ask whether people are experimenting with AI tools at all. There is little point talking about impact if no one has crossed the threshold into meaningful use.
But adoption metrics should not become the destination.
The more useful questions are:
Where is AI helping work move faster?
Where is it creating more downstream demand?
Where has review or verification become more important?
Where are people producing more output without improving outcomes?
Where has the constraint moved?
Where are teams now coordinating around work that used to be simpler, smaller, or slower?
Where do we need to make a decision about the system, not just the tool?
These questions shift the conversation from AI usage to flow, and that shift matters because the goal is not to maximise AI activity; it’s to improve the organisation’s ability to deliver meaningful outcomes.
The Real AI Productivity Question
The next stage of AI maturity will not be about who can consume the most tokens or who can generate the most output.
It will be about whether organisations can convert AI-enabled capacity into a better flow of value.
Can teams deliver meaningful outcomes sooner?
Can they reduce unnecessary coordination?
Can they make better decisions with less delay?
Can they reduce cognitive load rather than create new forms of it?
Can they preserve human judgement where it matters most?
Can they use saved time to improve the system, rather than simply pour more work into it?
That is the leadership challenge: to ask whether the system is becoming more effective because of AI adoption. If we want AI to improve organisations rather than simply accelerate them, flow is where we need to look.
Turning AI Signals into Flow Decisions
A practical starting point is to treat AI adoption as a source of signals that show where the shape of work is changing. The problem is that this learning often remains informal. It appears in retrospectives, Slack threads, leadership conversations, delivery reviews, architecture discussions, or workshop notes. But then disappears back into the noise of day-to-day work.
This is the space I am exploring with Fast Flow Toolkit, to help teams and leaders move from: “We think AI is helping.” To: “Here is where the work changed and how we know flow improved.”
If AI is changing how work gets done, we need a better way to see how that change is affecting the wider system. Once we can see that, we have a better chance of making thoughtful flow decisions rather than simply celebrating more activity. DM me if you’d like to be involved with the beta. www.fastflowtoolkit.com
