Amazon warns engineers not to confuse heavier AI use with better work

Amazon engineers should be judged by what their work achieves over time, not simply by how much AI they consume. In a memo made public on October 27, the company warned that token counts, tool adoption and code activity are flawed measures on their own—and can encourage higher costs and unnecessary complexity.

The guidance circulated internally in September before Amazon posted it on its website, according to CNBC. It revises how the company describes the roles of software development engineers and managers as AI becomes part of their work. Publication makes public a distinction in Amazon's approach: adopting AI is not, by itself, evidence that engineering work has improved.

A scorecard that can reward the wrong thing

The memo calls several familiar measures “deeply flawed” for assessing teams' AI usage: tokens consumed, the rate of AI-tool adoption, and code changes or reviews. Tokens are the units of data AI models process and generate. Counting more of them records activity, but Amazon cautions against treating that activity as a sufficient measure of the value a team delivers.

Amazon is not telling managers to discard those numbers. Its instruction is to consider token usage and code generation “with care and judgment,” alongside other data. The distinction is between using a count as one piece of evidence and allowing it to stand in for results. The company says the latter approach can produce both extra spending and excessive complexity.

There is a concrete precedent inside Amazon. In May, the company shut down an internal leaderboard after discovering employees were consuming tokens to climb its rankings. That behavior is known as tokenmaxxing: maximizing AI usage with little regard for the output. The memo addresses the same incentive problem by favoring long-term outcomes over consumption alone.

Launches and successful changes, not a token ceiling

Marc Brooker, an Amazon Web Services vice president and distinguished engineer, offered a more concrete productivity measure in an interview with CNBC. Amazon looks at “feature velocity,” including how many launches teams deliver and how many successful changes they make in production—the systems customers actually use. His examples focus on work reaching users successfully, rather than the volume of AI activity behind it.

Brooker described the decision as a return-on-investment question: important customer or business problems warrant tools, time, tokens and human effort. He cautioned against spending tokens on problems that do not matter, while acknowledging that their importance can be hard to judge in advance. That leaves room for experimentation. Separately, an Amazon spokesperson told CNBC the company has not capped employees' token usage.

If your work does not benefit from current AI tooling, that is a finding, not a failing.

Amazon's AI-usage memo, quoted by CNBC

Knowing when AI does not help

The memo also gives engineers permission to identify tasks where current tools do not help. It says an engineer who can explain those limits is demonstrating the judgment Amazon wants. The expectation is not simply to use AI whenever it is available, but to assess whether it benefits the particular work and be able to explain that assessment.

That discretion sits alongside a firm commitment to AI, not a retreat from it. Amazon says the technology's effects on software engineering are only beginning, and future best practices are still emerging. Even with those uncertainties, the memo says the company is certain AI will remain at the center of software engineering practice.