# The strangest developer productivity metric of all time > Source: > Published: 2026-08-12 09:00:00+00:00 I wonder these days. How did we ever write software without AI? I mean, I know we did. It was possible. But with AI it’s like wearing roller skates and a rocket pack. Naturally, we want to encourage developers to embrace this wondrous power. But just as naturally, our industry has found a way to convolute the whole thing. Instead of a sensible game plan, we have a blanket metric that, by embracing raw token usage as a measure of excellence, gamifies AI use in the worst possible way. Welcome to the bewildering world of tokenmaxxing. The more lines of code (LOC) you write, the more productive you are as a coder. Right? Wrong. Terribly wrong. It’s tough to imagine a more wrong-headed measure of software success than the amount of code produced. [LOC](https://www.infoworld.com/article/2161123/lines-of-code-and-unintended-consequences.html) is actually a measure of how sprawling a system is, an indicator of the breakable surface area. Well-considered designs often aim to reduce the LOC. Streamlined systems often reveal a lot more thinking and refining than actual coding. But the amount of tokens you consume when using AI? That is a worse measure than LOC. Not only does it imply that you are working without a plan, just racing to spew forth unmediated code, but also may suggest that you are stuffing the prompts with fluff, running up the meter without any intention of creating working software. Predictably, tokenmaxxing gives us both shoddy software and poor productivity. Surprisingly, it can even menace the infrastructure. Although the downsides of tokenmaxxing are starting to break on the industry, it is still a very live issue. We are looking for a good way to get developers to engage effectively with AI. It’s just this ain’t it. Perhaps the most eye-opening example of tokenmaxxing comes from Meta, where an employee implemented an internal leaderboard called [Claudeonomics](https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/). The leaderboard aggregated the AI usage of over 85,000 employees and ranked the top 250 power users based purely on how many tokens they had burned through. Those at the top of the leaderboard were rewarded not for clean code and elegant architecture, but for raw token consumption. The winners were given gamey titles like “Token Legend” and “Session Immortal.” In just one 30-day period, this system pushed Meta employees to consume a face-melting 60.2 trillion AI tokens. The fallout was what you might expect. Compute consumption as a corporate status symbol, according to a breakdown by [The Pragmatic Engineer](https://blog.pragmaticengineer.com/the-pulse-tokenmaxxing-as-a-weird-new-trend/), led to copious waste. Developers ran internal agents just to burn through tokens, generating throwaway work with little to no actual effect. Worse still, this token consuming frenzy damaged the company’s own infrastructure. Engineers reported that site outages were directly caused by careless AI code generation, driven by developers who were more focused on reaching Session Immortal status. It’s a kind of notoriety, I suppose, if not immortality. But still, there is a kind of almost childlike faith in technology and AI in particular that seems to underlie the trend. Leaders must sincerely believe in the possibilities of the thing, to pour so liberally from the bottom line. I hate to sound like a broken record, but there simply is no replacement for the intelligence and insight of experienced lead developers and their feedback into the loop. Meta isn’t the only tech giant to wander into this particular bramble. Over at Amazon, the pursuit of AI adoption spawned a short-lived, unofficial leaderboard known as Kirorank. Designed to track employee activity on the company’s Kiro IDE, the dashboard quickly descended into absurdity as engineers gamed the system. Developers figured out that the easiest way to climb the ranks wasn’t to write efficient code, but to spin up autonomous AI agents and assign them busy work. Amazon [pulled the plug on Kirorank](https://www.cio.com/article/4178825/amazon-deletes-devs-tokenmaxxing-leaderboard-to-minimize-costs-2.html) in a [matter of weeks](https://www.i-programmer.info/news/105-artificial-intelligence/18905-amazon-moves-to-reduce-tokenmaxxing.html), realizing they were footing the bill for compute costs just so their own engineers could chase a vanity metric. The financial backlash from this trend has been drastic. Companies that once cheered for unbridled AI adoption are now desperately trying to staunch the bleeding. [Giants like Salesforce and DoorDash](https://mediacopilot.ai/corporate-america-rationing-ai-costs/) have abruptly shifted from mandating AI usage to actively rationing it to manage ballooning API costs. The blind pursuit of AI consumption has been so intense that Uber reportedly [burned through its entire 2026 AI budget](https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/) in just the first quarter of the year. When you prioritize the sheer volume of tokens consumed over the quality of the software delivered, you don’t get digital transformation. You get a very expensive illusion of productivity. The winners in this equation are the AI providers. Sometimes, as in the case of Amazon, they are the same big tech players burning the tokens, either directly or indirectly. It’s a strange, incestuous ecosystem. Tokenmaxxing creates fluff, but it also degrades architecture. When we look at the data from the past few years, the results of rampant code generation are grim. According to [a June 2026 analysis](https://www.gitclear.com/recent_ai_developer_productivity_code_quality_research) of some 600 million code changes, code block duplication skyrocketed by 81% as AI authorship ramped up. Remember the old truism that whenever you cut and paste a block of code, you should treat it like a code smell? Well, there is a whole lot of cutting and pasting going on in AI-powered development, and nobody seems to be paying attention. At the same time, refactoring (the actual thinking and refining part of the process) plummeted by 70%, compared to 2022. Much of the volume of code generated by AI is disposable. It serves an immediate purpose (hopefully) and isn’t necessarily intended to address systemic concerns. The [rate of short-term code churn](https://dev.to/code-board/code-churn-doubled-while-we-were-celebrating-ai-speed-gains-2d0f) (code that is written and then significantly altered or deleted within two weeks) more than doubled from a pre-AI baseline of 3.3% in 2021 to 7.1% in 2025. [A May 2026 study](https://qz.com/ai-coding-tools-code-volume-releases-gap-nber-study-061126) found that, although using autonomous agents increased a developer’s commit volume by as much as 180%, it translated to a mere 30% increase in actual releases. This is a picture of high noise, low signal. We are writing more lines than ever, but we are throwing them away faster. The root of the tokenmaxxing phenomenon lies in a misapprehension of how AI intersects with actual engineering work. In 1976, Charles Goodhart observed that when a measure becomes a target, it becomes a corrosive measure ([Goodhart’s Law](https://en.wikipedia.org/wiki/Goodhart%27s_law)). AI project management is currently realizing it is entangled in this trap. Rather than tracking how long work takes from beginning to end, or whether system quality is improving, management often relies on easily defined (and easily gamed) dashboard metrics like the percentage of code that is AI-generated, or raw token volume. What this completely misses is the massive value of “non-code” AI work. Some of the highest-value interactions with an AI assistant involve debugging stack traces, analyzing fuzzy business requirements, or understanding edge cases. An engineer might spend an hour conversing with an LLM to pinpoint a root cause, ultimately resulting in a clean, three-line fix. That is brilliant, efficient engineering. Yet, under a tokenmaxxing regime, that engineer looks less productive on the manager’s dashboard than the one who just asked the agent to spit out 500 lines of spaghetti code. Some of the very best uses of AI are in thoughtful learning, discovery, and design. Like the brainstorming, whiteboarding, and conversations that have always provided the substratum for creating software, the value of that kind of AI use is almost impossible to estimate or distill into a metric. When the measurement we use to understand the health of software engineering becomes so divorced from the actuality, the financial mechanics turn violently against the enterprise. From an economic viewpoint, tokens are an input cost, not an output value. Worse, output tokens can cost up to five times as much as input tokens across top-tier frontier models. When you incentivize code generation, you are pressing on an incredibly leveraged part of the IT budget. This absurdity has given us the burgeoning field of AI finops. Companies are scrambling to build sensible guardrails, circuit breakers, rate limits, and virtual routing layers to put bounds around the burn, and find insights into the actual ROI. The waste often comes from obvious failures like context stuffing, where developers dump entire codebases into prompts instead of using surgical inputs, and “agent loops,” where autonomous agents recursively call themselves. It is the financial equivalent of leaving the lights on in an empty skyscraper. If we want to harness the roller-skates-and-rocket-pack of AI without landing in the ditch, we have to return to the hoary old ethos of software development. That ethos is inherently resistant to the tendency exemplified by tokenmaxxing. Excellence in software engineering has always been about stripping away the unnecessary and magnifying the essential. It is about thinking, refining, and planning, before we ever start generating code. AI is a magnificent tool for accelerating that process, but only if we remain responsible stewards. There is a final irony to consider. When we use AI to learn, explore, and design, we are using it not to code directly, but to realize higher-order benefits. In the end, one of AI’s greatest values to coders is its ability to analyze code, explain code, plan code, and accelerate exploration. The most astonishing and important aspect of AI may be that it can make us better software engineers.