Amazon published an updated role guideline for software development engineers, and the memo is better than most corporate AI pronouncements. It also contains a contradiction it never quite resolves.
The good part first. The document explicitly avoids defining good AI practice, on the grounds that any definition written now will look antiquated within a year and risks freezing engineering practice "in amber." Instead it anchors on what isn't changing: customer impact, business results, team outcomes. That's the Bezos line about asking what stays the same rather than what changes, and it's the right frame for a role guideline.
The best sentence in the memo is this one: "If your work does not benefit from current AI tooling, that is a finding, not a failing. Document why, share it with your community of peers, bring it to your manager, and work to find solutions."
That's a mature stance, and rarer than it should be. It treats a negative result as evidence rather than resistance.
Then the metrics section arrives
The memo knows exactly what's wrong with the obvious measurements. Token usage, AI tool adoption, throughput metrics like code changes and reviews — it calls them "deeply flawed" and "disconnected from what matters." It names the failure mode directly: used as a target instead of a measure, they drive negative outcomes. Tokenmaxxing is at odds with frugality; measuring lines of code is at odds with invent and simplify.
Good. That's Goodhart's law stated in Amazon's own vocabulary.
And then: "We have found that these input metrics correlate well with the outputs that matter and expect they will continue to do so for some time." We recommend "paying special attention to the 10th percentile (finding those teams who aren't embracing AI effectively) and the 90th percentile (finding those teams who are heavily using AI and understanding whether they're seeing delivery increases to match)."
That's not a contradiction in logic — the memo explicitly says correlation isn't causation and asks managers to understand the distribution rather than rank it. But it is a contradiction in practice. "Pay special attention to the 10th percentile" is how a metric becomes a target. Nobody needs to write "token usage is your performance rating" for it to function that way; it's enough that leaders are told to look, and that the look is attached to teams.
The unfalsifiable premise
The memo also asserts something it doesn't evidence: "teams and individuals who are not adopting AI or increasing output metrics are falling behind."
Maybe that's true at Amazon, and the authors have the data. But the sentence is doing a lot of work with no numbers. And there's an obvious confound: teams that ship more also adopt more tools, because they're the teams with the capacity to try things. Adoption correlating with output doesn't establish that adoption causes output, and the memo's own framing — frontier teams embrace AI and deliver more — is compatible with either direction.
The one place it does get specific is the expectation for leaders: sufficient understanding means you've used these tools on production work, can describe a task where they helped and a task where they did not, and can explain that judgement. That's a good bar. It's also a bar that requires judgement about when not to use AI, which is the same judgement a percentile metric will punish.
What would actually measure well
If you're going to track something, track the things earlier in this newsletter's reading: cost per accepted change, and what a change leaves behind at "done."
Amazon's memo gestures at this with "throughput metrics like code changes and reviews," but throughput is the weakest version. The useful measures are defect-at-done, review debt, time-to-restore, and the ratio of generated code to reviewed code. Those are harder to game and closer to the outcomes the memo says it cares about.
Token usage is the easiest metric to collect and the least connected to value. A team that spends fewer tokens to ship the same quality is doing better, not worse, and a percentile target on adoption would tell them the opposite.
The real tension
Amazon is a large organization trying to say "use AI, but don't do something stupid for the metric" to thousands of engineers, and the memo is an honest attempt at that. The contradiction isn't hypocrisy; it's the structural problem with managing a fast-changing practice through metrics.
You can have a principle ("outcomes, not tools") or a proxy ("adoption percentile"), but you can't have both as management instruments. The moment the proxy is measured and discussed at the percentile level, it becomes the instrument, and the principle becomes the caveat nobody remembers at calibration time.
The memo's own best line — a finding, not a failing — is the test. If an engineer documents that AI doesn't help their work and is then ranked in the 10th percentile of adoption, the sentence was decoration. If the organization can actually hear that finding without punishing it, the memo is real.