Amazon tells tokenmaxxing devs to slow their AI roll

Focus more on what matters, please, like creating useful software and accomplishing company goals

Maximize value, not token usage, Amazon has told its engineers, citing concerns about rising AI costs and complexity.

Amazon made the strategy shift public on Tuesday in a note to engineering teams outlining the changing role of its software development engineers in the age of AI.

“Our most prolific engineers have demonstrated that neither the developer role nor their output is defined by the use of AI,” Amazon VP and distinguished engineer Terk Terkowitz wrote in the note. “We're now in the era of the Renaissance Developer, blending AI tools with human judgment and domain expertise to build entirely new things.” 

REG AD

In other words, Amazon wants its developers using AI, but burning through tokens isn't the same thing as getting useful work done.

REG AD

Rather than define the developer role by how AI is used, the memo focuses on what isn't changing so fast: the need to deliver useful software and results for customers and the business.

“It is difficult to define, in a way that will stand the test of time, what good AI powered engineering practices look like,” the memo continues. “We have decided to focus on what is not changing as we evolved the SDE roles … the outcomes that matter aren’t changing, even if the inputs, tools, and techniques are changing faster than ever.”

What that means for software developers in the present moment is that AI input metrics, even if Amazon has seen some correlation with increased productivity and delivery on tokenmaxxing teams, aren’t what Amazon sees as a measurement of good use of developer time and resources.

“We are all aware of how deeply flawed these metrics are, primarily because they are disconnected from what matters,” the memo argues. 

“[U]sing these metrics could, if used as a target instead of a measure, drive negative outcomes, increasing costs, and increasing complexity,” the memo continues, referring to tokenmaxxing costs and overly complex code that’s at odds with Amazon’s mission to “invent and simplify.” 

An Amazon spokesperson confirmed that the memo’s intent was to discourage tokenmaxxing, pointing us to comments from AWS CEO Matt Garman from June in which he encouraged developers to measure outcomes, not token consumption, in making proper use of AI tools for software development. 

Amazon also wants its developers thinking more about how AI can help “improve delivery for customers” and business units, not just trying to find a place to stick it to prove it's working for them. The memo calls out some engineering teams who’ve “become less connected to their customers and business,” and says teams that are more engaged with their products and business roles “are able to take the most advantage of AI and agentic software development,” in essence calling for more teams to take a similar approach.

“If your work does not benefit from current AI tooling, that is a finding, not a failing,” the memo said. “An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for.”

REG AD

Amazon's take in the memo is starkly similar to what Microsoft told its own internal development teams in August, right down to stressing a focus on returns for customers and business instead of maximizing input. 

"Tokenmaxxing is not what we are optimizing for," Microsoft EVP Jay Parikh told developers. "I want all of us focused on maximizing outcomes that move the needle for our customers and our business."

With that, the writing seems to be on the wall for the throw-AI-at-everything-and-see-where-it-sticks approach to integrating the tech. When two companies that large start to question whether AI token consumption is a useful measure of productivity for their thousands of software engineers, it's possible the rest of the world will soon start sipping those tokens instead of chugging them.

That, or we'll soon see even more enterprises begin to embrace the philosophy of relying on "good enough" open-weight models that can handle many tasks at a fraction of the cost of more expensive alternatives – Garman made a similar case for choosing cost-effective models based on the task back in June.

If you're a bubble, that approach looks an awful lot like a pin. ®