Token Maxing Is Breaking Big Tech's Engineering

Remember when we thought lines-of-code metrics were the dumbest way to measure engineering productivity? Well, big tech just found something worse: token maxing.

Gergely Orosz, the former Uber engineer behind The Pragmatic Engineer newsletter, dropped some wild intel about what's actually happening inside companies like Meta, Microsoft, and Salesforce. And it's not the AI productivity revolution you're reading about in press releases.

The Leaderboard Problem

Here's the setup: You're an engineer at Meta making $400k+. Leadership is pushing AI adoption hard. They've built internal leaderboards showing how many AI tokens every engineer is using. Your peers are racking up massive token counts. You look at the bottom 25% and start sweating.

What do you do?

If you're like a lot of engineers Orosz talked to, you start gaming the system. Ask the AI agent to summarize documentation you could've just read. Run autonomous agents to build stuff you don't need. Generate code you won't use. Anything to get that number up.

"Instead of reading the documentation, I will ask the agent to summarize it for me and ask questions even though it doesn't do a good job answering it, but my token count goes up," Orosz explained. "People just want to not be in the bottom 25% or bottom 50% for token count."

At Salesforce, there's literally a minimum monthly spend target—around $175. Engineers are hitting it the same way you might rush to meet a step count goal: artificially, anxiously, and without actually improving anything.

Meta had a leaderboard. They shut it down after it became public. Engineers are still token maxing because the fear doesn't go away just because the scoreboard does.

Why Leadership Pushed This Hard

The weird part? This started with a real problem. About six months before the current AI tools got good, CTOs were genuinely worried their engineers weren't using AI at all. Orosz was at a dinner with tech leaders in Amsterdam where one CTO complained that their engineers were "really skeptical of AI and they're not really using it."

Experienced engineers had valid reasons for skepticism. Early AI coding tools on existing codebases were, to be blunt, kind of trash. They didn't help with refactoring. They couldn't find bugs. They mostly just got in the way.

But leadership kept hearing about Anthropic writing tons of code with Claude, kept seeing AI company revenues climbing, and made a correlation-causation leap: our engineers need to use more AI or we'll fall behind.

The most extreme example? Coinbase CEO Brian Armstrong sent an email demanding everyone use AI tools. A week later, on a Saturday, he fired an engineer. "They got the message," Orosz said. "Everyone just started to use it."

Which brings us to a provocative point Orosz made about why this works at big tech specifically:

"Have you ever wondered why big tech loves to do LeetCode style interviews, algorithmic interviews which have nothing to do with the job?" he asked. "It selects for a specific type of person. It selects for the person who's smart and willing to put up with absolute bullshit to get the job."

That same person will put up with bullshit to keep the job. Including token maxing.

The Productivity Paradox

So is any of this actually making engineers more productive?

Individually, maybe. Orosz thinks AI tools are helping at the personal level. But at the team level? "We're kind of a bit question mark because we should be moving faster and there are a few companies that do... but a bunch of companies are not. It seems hard to retrofit all this AI into the way we have been working."

There's a study that came up in the conversation—engineers felt 20% more productive with AI but were actually 20% less productive on demonstrated results. Small sample size, one outlier who was legitimately crushing it, but the perception-reality gap is interesting.

The real unlock might not be making existing engineers faster. It might be enabling non-technical people to code without waiting for engineering resources. Different kind of productivity gain, harder to measure on a leaderboard.

What Engineers Are Actually Becoming

Setting aside the token maxing weirdness, the role of software engineer is legitimately changing. And AI is accelerating shifts that were already happening.

Testing collapsed into engineering years ago—most companies don't have dedicated QA anymore. DevOps collapsed in next. Now product responsibilities are getting absorbed too. The "product engineer" role that was niche in 2022 is becoming table stakes.

Teams are shrinking. Someone at John Deere—a 200-year-old tractor company, not a startup—told Orosz their two-pizza teams are becoming one-pizza teams. Expectations for early-career engineers are higher. You're supposed to know the business, plan strategically, ship independently.

There's a meme going around that engineers are now "engineering managers for AI agents." Orosz, who's actually been an engineering manager, called BS on this. Managing agents is nothing like managing people:

"You don't have to deal with people drama, people problems, conflict between your team. Unless the next generation of agents starts to fight with each other... it's more like a tech lead role where you're mentoring engineers but you don't have the people management."

DHH (creator of Ruby on Rails) told him it's more like wearing a mech suit—you can do seven things at once, faster, and you're still in control. Better analogy.

The Learning Curve Nobody Talks About

Orosz brought up Simon Willison—Django creator, prolific blogger, definitely not just a "top Hacker News commenter"—who told him even after two years of working with AI tools, he was still figuring out what works.

"There's no manual," Orosz said. "And I think that's something that is a bit hard for us. Two things about AI that for any of us engineers is hard to understand. One is it just takes a long time to get good at it and you need to keep doing it. And the second thing is understanding the theory will not make you better at using the tools."

That second point breaks engineers' brains. We're used to learning how compilers work, how assembly works, and that knowledge making us better at writing low-level code. With AI tools, understanding transformers and attention mechanisms and probability distributions doesn't really help you write better prompts or structure better workflows.

You just have to practice. And keep practicing. And the workflow that works for you individually might break when you're on a team, so you learn again.

What's Happening Behind The Scenes

While engineers token max on the surface, big tech companies are actually doing something more interesting internally. They're rebuilding their entire development infrastructure around AI.

Uber isn't shipping a bunch of flashy new consumer features. But internally? They're building custom background coding agents integrated into their monorepo. They're creating MCP gateways integrated with service discovery. They're retooling their on-call systems. Their code review platform now categorizes changes by risk automatically.

Every major tech company is doing some version of this. The infrastructure transformation is real even if the token maxing is stupid.

Which raises the actual interesting question: Is token maxing just a dumb intermediate step while companies figure out what actually matters? Or is it a warning sign about how AI adoption gets forced top-down without understanding what engineers actually need?

I'm leaning toward "both, and it's going to get weirder before it gets better."

—Tyler Nakamura