Jensen Huang says every engineer should consume 100,000 tokens daily. Shopify's CTO says the real metric is what you do with them. Both are right. Both are dangerous.
The "tokenmaxxing" conversation took off after Huang's keynote claim: if your $200K engineer isn't burning through six figures of tokens per year, you're underutilizing AI. The logic seems sound. More tokens = more AI assistance = more productivity. Except it isn't.
Mikhail Parakhin at Shopify runs one of the most AI-dense engineering organizations on Earth. Their internal data shows December 2025 as an inflection point where daily active usage went vertical. But here's what caught my attention: the distribution skews hard. The top 10% of users consume exponentially more than the bottom 75%. If this trend continues, he notes, you end up with "one person consuming all the tokens."
That's the problem with raw volume metrics. They optimize for motion, not progress.
The anti-pattern Parakhin describes is running "multiple agents in parallel that don't communicate with each other." This burns tokens efficiently—if your goal is burning tokens. But parallel generation without iteration is just expensive dice-rolling. What actually works, in their internal data, is depth over breadth. Serial research loops where one agent builds, another critiques with a different model, and the first revises based on feedback.
Higher latency. Higher quality. Fewer tokens wasted on dead ends.
This maps to what we're seeing in production systems. The coding models with the highest benchmark scores often produce bloated diffs. GPT-5.4 over-edits; Opus 4.6 under-edits. The evaluation metric that actually matters isn't pass@1—it's whether the fix required touching three files or thirty. Cognitive complexity beats token count.
The deeper issue is what happens when you institutionalize token budgets as KPIs. Engineers start optimizing for the metric. You get microservices making a comeback because they let teams ship independently and burn more tokens in parallel. You get PR review queues choking not because humans are slow, but because the volume of AI-generated code outpaces any review capacity—human or machine.
Shopify's internal solution is spending more on review than generation. Their ratio of critique-to-generation tokens is deliberately inverted from what most teams run. They use their strongest models (Opus 4.6, GPT-5.4 Pro) not for initial code generation but for validation. The generation is cheap and fast. The verification is slow and expensive.
This is where Huang's directionally-correct argument meets reality. Yes, we need more AI compute in the development loop. But framing it as "token budget per engineer" creates the wrong incentives. It suggests consumption is the goal rather than outcome.
The parallel I keep returning to is lines-of-code metrics from the 2000s. We learned—painfully—that more code meant more bugs, more maintenance, more technical debt. LOC stopped being a vanity metric when we started measuring cyclomatic complexity, test coverage, and deployment frequency. Token consumption needs the same evolution.
What matters is the ratio of deployed value to token spend. One 50-token prompt that fixes a production incident beats 50,000 tokens of speculative architecture exploration. A single critique loop that catches a security flaw before merge is worth more than ten parallel agents generating competing implementations.
The infrastructure bet here isn't just bigger context windows or cheaper inference. It's trace-based evaluation systems that understand what actually moved the needle. Parakhin notes that Shopify is building internal telemetry around "PR merge velocity" and "rollback rate per AI-generated change"—not "tokens consumed per engineer."
The teams that get this right will have compound advantages. Their codebases stay clean because critique agents prevent messes. Their deployment pipelines stay fast because review bottlenecks are automated, not overwhelmed. Their engineers spend tokens on iteration loops that converge, not parallel branches that diverge.
If you're setting AI budgets this quarter, consider flipping the question. Instead of "how many tokens can we afford," ask "what's our critique-to-generation ratio?" Instead of tracking consumption, track conversion rate from prompt to production.
Tokenmaxxing is a trap. The teams winning this phase are tokenminimizers—maximizing output per token, not tokens per dollar.
Top comments (0)