Moonshots and Microchips: What the Apollo Program Can Teach You About Your AI Budget

There’s a new status symbol in tech leadership: how many tokens your engineers burn.

In March, NVIDIA CEO Jensen Huang made a provocative claim on the All In Podcast: if your $500,000 engineer isn’t consuming at least $250,000 worth of tokens, something is wrong. Silicon Valley being Silicon Valley, some people took this warning seriously. A trend called “tokenmaxxing” — using AI token consumption as a proxy for productivity — was born.

Tokenmaxxing is, to be direct, a bad idea. But it opens up a fascinating conversation about what productivity really looks like at this moment in time.

The Tokenmaxxing Trap

Most organizations I’ve chatted with are currently only spending a few thousand dollars per engineer annually on AI tooling, nowhere near the $250,000 Jensen Huang is advocating for. AI spending is hard to pin down anyway. It doesn’t fit neatly into annual planning cycles, and it is growing in ways that are difficult to explain to a CFO who approved a number a few months ago. Leaders across industries describe taking their team’s AI tooling estimates and simply adding random amounts. They don’t have a model for the right number; they are guessing. Uber reportedly burned through its entire 2026 engineering AI budget in a single quarter. Nobody knows the true cost of a token, partly because usage is still being subsidized by the providers. The floor could move.

Even if the budget was predictable, though, using token consumption as a productivity signal fails for at least two reasons.

First, vanity metrics corrupt behavior. This is the part that should concern anyone in a leadership role.  If you gamify token consumption, engineers will optimize for token consumption. Poor prompt design, circular agent loops, and unnecessary re-querying: all of these drive up spend with zero benefit. The metric becomes the goal.

Second, individual productivity gains don’t automatically roll up to business outcomes. Engineers can feel more productive, pull requests can come faster, AB test velocity can tick up — and actual product impact can stay flat. Individual throughput is the easiest thing to measure, but it is not the most meaningful thing to optimize for. Token consumption is one more layer of abstraction on top of a measurement problem that most companies haven’t solved yet.

But here’s where the conversation usually goes wrong: people hear “tokenmaxxing is bad” and conclude that efficient token usage is what we should be chasing. That’s the wrong lesson. “Tokenminning” would be just as dangerous.

Science Isn’t Engineering

To understand why, we have to start by drawing a distinction between science and engineering. Science doesn’t abide by budget the same way engineering does. Science’s output isn’t a reliable product. It’s a discovery. It’s messy, expensive, and the breakthrough is usually the unexpected thing you stumbled across while trying to solve something else. Engineering takes that discovery and builds something that holds load, ships reliably, and scales. You don’t want scientists building a bridge. But you also don’t want engineers running a laboratory.

Right now, most organizations are in a science phase with AI. They’re figuring out what’s even possible. Expecting engineering-grade ROI from science-phase work is a category error — a costly one. If you optimize token efficiency before you’ve discovered what you’re actually building, you risk never making the discovery at all. 

The question that’s hard to answer cleanly: how do you know your people are learning from their token spend, rather than just burning it? Some organizations are starting to build two-axis measurements (i.e., token consumption vs. efficiency score) to find engineers who are both high-volume and high-quality in their AI use. While these measurements are emerging, be careful not to allow the metric to become the goal.

Funding Moonshots

Last month, like millions of others, I found myself watching the Artemis II launch and landing coverage (along with those gorgeous pictures), and feeling the same sense of possibility that defined the original space race. It got me thinking about what the Apollo program actually represented and so I went back and watched JFK’s famous address to an audience at Rice University in Houston, where construction of the Manned Spacecraft Center (now known as the Johnson Space Center) was underway.  The speech is famous for its inspirational quote: “We choose to go to the moon […], not because [it is] easy, but because [it is] hard.”

Image Credit: National Archives

I realized in watching his speech that going to the moon wasn’t just a big goal; it was an engineering mandate. And today it serves as a blueprint for transforming discovery into something real enough to organize belief, talent, and budgets around.

If you listen closely, behind the audacious and lofty vision Kennedy was laying out, he was also intelligently building a case for tripling the federal space budget. He justified the cost in terms the audience could process: less than what Americans were spending on cigarettes that year. He pointed to concrete wins in satellite superiority. He was honest that no one knew exactly what the journey would yield. And then he said something that gets less attention than the famous line but is no less important: “that goal will serve to organize and measure the best of our energies and skills.”

The moon wasn’t the point. The challenge was.

The Apollo program did reach the moon, with six months to spare, using computing technology that would embarrass a modern calculator. But the lasting legacy wasn’t the landing itself. The need to build an Apollo guidance computer created an early mass market for integrated circuits, which drove down prices and made the semiconductor industry viable. Margaret Hamilton’s work on fault-tolerant real-time software helped establish software engineering as a discipline. NASA-funded fuel cells seeded what became today’s commercial fuel cell industry. Fire-resistant materials developed after the Apollo 1 fire later showed up in firefighting gear, aircraft seating, and stadium roofing. Patient monitoring technology designed to track astronaut vitals became the foundation of modern ICU equipment.

None of that was the goal. It was the byproduct of organizing a massive effort around a difficult challenge.

The powerful thing about AI is that it compresses cycle times dramatically. The distance between discovery and production is weeks and months, not decades. The engineer who gets more productive is shipping features that will show up in your product next month. You don’t have to wait for a fuel cell industry to emerge from your moonshot. You can see the returns accruing.

Image Credit: NASA

Your AI Moonshot

So what does this mean for a technology leader trying to justify an AI budget to a skeptical CFO?

You need a moonshot: a specific, ambitious destination that organizes your team’s efforts and gives you something to measure against. Not “be AI-first.” Not “use AI to improve productivity.” Something concrete enough that the journey has structure, even if the destination shifts.

Intercom’s CTO Darragh Curran set a goal to reach 2x R&D productivity within 12 months and made it explicit: “We must deliberately chase it and overcome all obstacles in our way, as opposed to being passive and hoping it happens to us.” Sure, maybe doubling productivity isn’t exactly a moonshot, but it’s certainly a stretch goal. And it doesn’t tell engineers exactly how to get there, but it tells them where they’re going.

Here are three ways to think about this practically:

Budget for the phase you’re actually in. If your teams are still in discovery (i.e., figuring out what AI can do for your specific business problems), budget like you’re funding a research initiative with a defined time horizon and a concrete deliverable at the end. This is an experiment. Expect inefficiency and learn from it rather than punish it. 

Ask the learning question, not the efficiency question. The right metric right now isn’t how efficiently your engineers use tokens. It’s whether their token usage is generating organizational knowledge and moving you in the right direction. Are they shipping experiments faster? Building institutional blueprints for what works? Identifying and developing new skills that compound over time? 

Watch out for local optimization killing global architecture. Agentic coding can produce impressive early results and quietly terrible systems two months later. The agents optimize locally; nobody is thinking about the global design. Systems thinking and architectural judgment, not prompt fluency, are becoming the scarcest and most valuable skills on an engineering team.

What We’re Watching

At Karat, as we develop the next generation of technical assessment, we’ve deliberately chosen not to optimize for AI cost efficiency yet. That’s a version 3.0 problem. We’re still discovering the science by identifying and evaluating the skills that matter for the current phase: problem framing, systems thinking, curiosity, adaptability, and the ability to work productively with AI tools without delegating critical judgment to them.

The engineer for the AI era isn’t the one who burns the most tokens. Or the least. It’s the one who learns when to spend them and how to compound what they learned across the organization.

Which raises the question that really matters: how are you learning from your tokens?

Jeff Spector is the Co-Founder and President of Karat, the trusted standard for measuring talent quality. Karat helps engineering leaders at companies like PayPal, Atlassian, and Citi make their most important talent decisions through human-led, AI-native talent evaluation.