“Necati, how can I burn more tokens?”
Someone asked me this recently.
I had to pause.
I understand wanting engineers to use AI. Give them access. Give them time to learn. Let them try approaches that might fail.
But why would consuming more tokens become the objective?
Maybe your team is solving harder problems. Maybe an agent is repeating the same failed attempt twenty times. The token count goes up in both cases.
You need to understand which one is happening.
Token Usage Does Not Explain the Result
DORA addressed this directly in Finding balance in the era of tokenmaxxing. It acknowledges that encouraging usage can help people experiment, but warns that token consumption becomes easy to game when treated as a performance target.
I agree. Encouraging people to learn a tool makes sense. Asking them to prove their value through consumption creates a different incentive.
This measurement problem existed before AI coding agents. The 2021 SPACE framework argues that developer productivity cannot be captured by one metric or by individual activity alone.
I think token counts belong in that same conversation. They tell you something about usage. You still need to investigate what that usage accomplished.
Imagine two developers working on the same bug.
One asks an agent to rewrite a large part of the application. Another uses AI to understand the failure, identifies a configuration problem, and changes two lines.
Who did the better job?
You cannot answer that by looking at their token consumption. You have to inspect the fix, understand the consequences, and check whether the problem is actually solved.
I made a related point in Evaluating an LLM Is Different From Evaluating a RAG System: before choosing a metric, understand the behavior you need and the failure you want to catch. A score becomes useful when it helps you make that judgment.
Count the Work After Generation
There is also work that happens after generation.
In March 2026, DORA published an analysis of 1,110 written responses from Google software engineers, collected in 2025. Engineers described faster creation alongside additional verification effort and a heavier burden on reviewers. These are observations from one company, not a controlled experiment. But they describe a cost that deserves attention.
If an engineer generates a change in ten minutes and another engineer spends three hours understanding and correcting it, you have to count both people’s time.
I have written before about blindly trusting AI-generated code. If you are a professional developer, you are responsible for what you ship. Generating more code does not remove that responsibility.
Measure Progress Across the Team
Now, I am not saying every team should reduce its AI spending.
A higher bill can be reasonable if the team delivers better results. Experimentation also needs room. You will not know every useful application before trying it.
But when you evaluate the result, ask questions about the work.
Did a useful change reach users sooner? Did review become easier or harder? How much rework followed? Did reliability improve? Did the team learn something it can use again?
Look at these together. Replacing a token leaderboard with a pull-request leaderboard would leave the same problem.
For a CTO, this requires more judgment than checking a dashboard. You need to understand where AI helps, where it creates extra work, and what your incentives encourage people to do.
That is part of the job.
If you measure AI activity instead of progress, you are not leading an AI-first engineering team.
You are approving a larger API bill.