This is your last article that you can read this month before you need to register a free LeadDev.com account.
Key takeaways
- Tokens, lines of code, and pull requests measure activity, not business impact.
- AI can increase developer output while shifting the bottleneck into review, testing, integration, and maintenance.
- Leaders should measure the full path from idea to customer value, then use AI where the real constraint lies.
We have all seen the posts by now. Technical and non-technical people alike are celebrating how they use AI agents to maximize their code output. They share the number of lines generated, pull requests (PRs) opened, tasks completed, and tokens consumed. The numbers are oftentimes enormous, which makes them easy to celebrate.
The era of “tokenmaxxing” has taken this one step further. Once token usage appears on a dashboard, it is only a short time before teams compare it, leaders reward it, and engineers begin optimizing for it.
There is nothing inherently wrong with consuming a lot of tokens. Experimentation is how teams learn what these tools are good at and how to best adapt them. However, as the experimentation phase comes to a close, technology leaders are starting to ask a more uncomfortable question: what is the return on those tokens?
If an organization spends $1,000 on tokens, did that create more than $1,000 of value? Did customers receive useful features sooner? Did conversion, revenue, or other meaningful metrics improve? Did production incidents fall? Or did the organization simply produce more code for someone else to review, maintain, and eventually delete?
That is the throughput trap: mistaking an increase in code production for an increase in delivery.
More like this
Writing code is no longer the bottleneck
For most of software’s history, writing code was expensive. Turning a product idea into a working implementation required a substantial amount of product input and engineering time. It made sense for productivity efforts to focus on speeding up that part of the process.
AI has changed the economics of software development. Code can now be produced in minutes, sometimes seconds, and at a fraction of the cost. A developer can ask an agent to create an API, tests, update a database schema, and open a PR while they work on something else or drive other agents.
This is a real productivity gain. The 2025 DORA report found a positive relationship between AI adoption, software-delivery throughput, and product performance. Yet it also continues to have a negative relationship with delivery stability. DORA’s conclusion was not that AI is useless but that it acts as an amplifier, magnifying the strengths and weaknesses already present in an organization.
AI may remove the constraint of writing code without eliminating the constraints around that code. Product requirements still need to be understood. Architectural decisions still require judgment. Changes still need to be reviewed, tested, deployed, and supported.
The bottleneck has moved from code generation to somewhere else, but organizations are still measuring the old one.
The review queue keeps growing
The explosion of code first becomes visible in code review. An agent does not have limits other than the ones enforced by the plan limits. It can create a second PR while the first one is waiting. Human reviewers do not scale in the same way.
Senior engineers who once focused on architecture, mentoring, and complex product problems are increasingly spending their time reviewing and validating machine-generated code. AI has not eliminated the work – it has shifted more of it onto the people whose time and attention are already the most limited.
This also changes the economics of starting work. Before AI, the cost of implementation forced teams to think before building. Now, it is often faster to ask an agent to create a solution than to check whether one already exists. The result is more work in progress, more parallel initiatives, and more code arriving at the same narrow review gates.
When every team builds its own version
AI is also changing how teams design software. AI makes it extremely easy for a team to build a complete vertical solution. Need authentication logic? Generate it. Need a special parser? Generate that too.
Building a shared library is much slower. Teams have to find other users, agree on an interface, assign ownership, document the abstractions, and support it over time. Generating a local version requires none of those conversations.
From the perspective of an individual team, this choice is rational. From the perspective of the wider organization, it can leave five teams owning five slightly different versions of the same capability. Codebases grow outward faster than teams can consolidate and reuse what they already have.
AI agents are generally optimized to complete the task in front of them. They are not accountable for the cost of owning the entire codebase several years later. Given a goal, AI can easily create a lot of arcane code that is difficult to maintain and especially troublesome when something goes wrong in production.
There is also the question about taste. When almost anyone can produce software, the differentiator is no longer simply the ability to build something. It is knowing what should be built and how it should be delivered to the user. That becomes harder when every team is independently building a vertical solution. Products may begin to look and behave inconsistently. In the worst cases, they may not work well together at all.
New York • September 15 & 16, 2026
The pace of change keeps accelerating. See what other leaders are doing about it, at LDX3 New York.
Output, delivery, and value are different things
Engineering leaders need to separate three ideas that are often bundled together.
- Output is the material the team produces: tokens consumed, PRs, lines changed, tasks completed
- Delivery is the organization’s ability to move a useful change into production safely: metrics like lead time, review time, deployment frequency, recovery time, and rework.
- Value is what happens after delivery: customer adoption, revenue, retention, reduced support volume, lower operating cost, or reduced business risk.
AI can improve output without improving delivery. It can improve delivery without creating value if the team is building the wrong thing. That is why a token dashboard cannot answer the return on investment (ROI) question on its own.
The better conversation starts with the business result and works backward. What customer or operational outcome are we trying to change? What part of the path is currently slow? Is code generation actually the constraint?
AI is excellent at prototypes, boilerplate, migrations, test scaffolding, documentation, and well-bounded changes. However, if the constraint is unclear requirements, a multi-day review queue, brittle integration tests, or lengthy privacy and legal reviews, generating more code may only make the problem worse.
Escaping the throughput trap
First, define the outcome before starting the agent. Every meaningful AI-assisted task should have a clear user or operational result, not merely an implementation request.
“Add a recommendation service” describes output. “Increase the percentage of new users who find a relevant item in their first session” describes an outcome. Defining that outcome may also require speaking with other stakeholders and building consensus before implementation begins. That work matters because it confirms that the team is solving a real business problem rather than simply producing another technical artifact.
Second, control batch size. Agents should not be allowed to turn one idea into a giant PR simply because they can. Smaller changes are easier to understand, test, review, and reverse. AI should increase the frequency of small, validated changes, not the size of the review burden.
Third, reward reuse and deletion. Before generating something new, ask whether an existing component can be extended. Give teams credit for removing code, consolidating duplicate implementations, improving shared libraries, and simplifying systems.
Finally, measure the queues. Code review still matters, especially when teams need to understand what is entering their production systems. Track time spent waiting for review, PR age and size, escaped defects, rework, rollbacks, and the time between deployment and meaningful customer adoption.
These signals reveal whether AI is accelerating the entire delivery system or simply flooding its bottleneck.
Optimize for value creation, not tokens or code
The answer is not to stop using AI or to discourage engineers from consuming tokens. AI-coding tools are too useful, and their capabilities are improving too quickly, for that to be a serious strategy.
That said, leaders should remember that metrics become instructions. Put token usage on a leaderboard and people will maximize tokens. Celebrate PR counts and people will create more PRs. Reward customer and operational outcomes and teams will start asking whether the code needs to exist at all.
The best AI-powered engineering organizations will not be the ones that produce the most code. They will be the ones that turn ideas into reliable customer value with the least unnecessary code, coordination, and maintenance.
That is the real productivity opportunity. AI should not help us build more software for its own sake. It should help us deliver more value regardless of code output.
