CNBC reported on an internal Amazon memo telling engineers to apply judgement to AI token usage rather than maximising it. Amazon has not capped token use. What it has done is more interesting: it acknowledged that token counts and adoption rates are flawed metrics, and said it will track launches and successful production changes instead.
Strip the AI framing off and this is one of the oldest failure modes in software management. The thing you can measure easily is almost never the thing you want.
The metric was never the goal
Nobody at Amazon ever wanted high token consumption. They wanted shipped software. Token count got adopted as a proxy because it is trivially instrumentable, it produces a graph that goes up, and it correlates with the behaviour they were trying to encourage in the early adoption phase.
Then the proxy became the target, and the correlation broke. This is Goodhart’s law with a new noun in it. We have run this experiment before with lines of code, with commit counts, with story points, and with test coverage percentage. Each one started as a reasonable signal and degraded the moment someone’s review depended on it.
The giveaway is the word in the coinage itself. “Tokenmaxxing” is what engineers call it when they can see the metric is being gamed, including by themselves.
Why the correction is harder than the mistake
Switching to “launches and successful production changes” is directionally right and much harder to measure. A launch is lagging, lumpy, and attributable to a team rather than a person. It resists the dashboard. That is precisely what makes it a better metric and precisely why organisations drift back to the easy proxy.
There is a related piece doing the rounds, Here Be Monsters, arguing that engineers still need enough underlying knowledge to recognise when something is wrong and to investigate deeply when it is. I think these two stories are the same story viewed from different heights.
If you optimise for token throughput, you are implicitly optimising for volume of generated code. Volume of generated code is only valuable if someone retains the ability to tell when it is wrong. The memo is management noticing that the metric was quietly eroding the capability that makes the output worth anything.
What I take from it as a student
The uncomfortable version of this, for someone about to enter the industry, is that the skill being selected for is not “can use AI tools”. That is becoming table stakes and it is not scarce.
The scarce thing is the judgement to know when the output is wrong, which you can only build by having done the work manually enough times to have an intuition for what correct looks like. Which is an argument for doing some things the slow way on purpose while you still have the luxury of time to.
Sources: CNBC on the Amazon memo, Here Be Monsters, via TLDR.