Tokens Are Rocket Fuel, Spending Tokens Is Rocket Science

Last month I gave a talk at AI Engineer World’s Fair in San Francisco. I only had 20 minutes to explain what I’ve been learning in my research across hundreds of thousands of developers about how the most revolutionary technology of our lifetimes is completely transforming the world of software engineering.

So of course I decided to spend the first 5 minutes teaching everyone in the audience about rocket science.

Why? Because when you look at the data, rocket science and AI-assisted software engineering have two important things in common: both use massive amounts of resources with incredible potential to achieve astronomical goals—and in doing so, both face severe headwinds, punishing constraints, and diminishing returns.

Despite the cliche, the fundamentals of rocket science are actually pretty straightforward.

The place to start (and for our purposes, the place we’ll stop) is the “classical rocket equation”, credited to Konstantin Tsiolkovsky and independently derived by several others (including fellow WPI alum and “Father of Modern Rocketry” Robert Goddard) more than a century ago.

Let’s use this form:

Here’s how it breaks down:

• Δv is the change in velocity

• v_e is the “exhaust velocity”, which is a property of the rocket propellant (basically, bigger is better)

• m₀ is the “initial mass” (think the complete, fueled-up rocket + payload sitting on the launch pad)

• m_f is the “final mass” (think the empty rocket, fuel spent, with just the payload remaining)

Succinctly, the rocket equation tells us that there is a relationship between the amount of fuel spent (captured by the mass ratio m₀ / m_f ) and the amount of velocity gained… and that relationship is logarithmic.

Put another way: to launch a payload into space, first you need some fuel, then you need even more fuel to propel that fuel (and the payload), and then you need even more fuel to propel all that other fuel (and the payload), and so on and so on.

Each extra unit of rocket fuel buys diminishing amounts of velocity gain.

All the major engineering challenges in rocketry derive in some way from this harsh reality, which astronaut Don Pettit referred to as “the tyranny of the rocket equation”.

At Jellyfish, we help software engineering teams measure how their teams are using AI coding tools and agents, and how those behaviors relate to outcomes like what code actually ships. Accordingly, we have a view into how many tokens developers and teams are spending, and how it relates to coding outcomes such as merged pull requests.

The plot below represents data from approximately 1 million developer-weeks of activity from the Jellyfish platform. Each dot is the average token spend and average pull requests merged per week for an equal-population bin of the data (~20K samples each, grouped by token spend).

Look familiar? Just like the rocket equation, code output increases rapidly with consumption at first, but then the gains level off.

Each extra token spent buys diminishing amounts of coding output.

There’s a lot going on in this chart, so let’s break it down. I’d like to call out three things:

1. I’m asserting here that token spend is a reasonable proxy for AI maturity / “ways of working”. As you move to the right (increasing token spend), we enter new regimes of AI coding behavior and agentic development.

2. The majority of activity (~70%) is happening at or below 50M tokens / dev / week. I’ve labeled this the agentic barrier—we find again and again that many teams struggle to graduate beyond this level.

3. As you get above the agentic barrier, the diminishing returns really start to kick in: the heaviest-spending decile of developers burns roughly 10x the tokens of the median developer, but merges only about 2x as many PRs. This stratosphere is currently where the headwinds of software factories become the most punishing.

Obviously, rocket scientists don’t respond to the tyranny of the rocket equation by burning more fuel and hoping. They engineer around the constraints (e.g. multiple-stage vehicles, lighter materials, better propulsion). Getting the most out of AI-assisted development calls for the same deliberate approach.

So let’s go through each of these in detail: what’s going on in the data, and what you can do about it.

Although the fad of “tokenmaxxing” seems to have come and (thankfully) gone, token spend itself continues to be a useful metric.

In addition to the obvious reason—namely, that tokens are the de facto currency of inference—token spend is also a pretty good first-order proxy for how developers and teams really work. This is because it’s quite difficult in practice to burn 100M+ tokens a week doing fancy autocomplete in your IDE, or even running interactive sessions with agents. Spending more tokens requires categorically changing the way that you develop software.

To illustrate this, I’ve broken the curve down into regimes:

• Interactive coding (< 50M tokens / dev / week). At the low end, you’re doing fancy autocomplete in Cursor. At the high end, you might have agents writing most or all of the code, but you’re still “botsitting”, limited to a small number of concurrent sessions and throttled by human attention.

• Autonomous agents (50M to 200M tokens / dev / week). In this regime, you’ve developed the process, platform, and infra to allow agents to work in more autonomous ways. There is still a lot of manual work involved in pointing them at the right things and validating their work, but your agents can handle increasingly larger chunks of development on their own.

• Agent orchestration (200M+ tokens / dev / week). Spend in this regime is characteristic of highly autonomous teams of agents. At the high end (and beyond), things increasingly look like scaled “software factories”.

That brings us to the first headwind: the agentic barrier. Roughly 70% of the developer-weeks we track sit below the barrier, where agentic software development is largely characterized by interactive workflows with heavy oversight.

Why are so many teams stuck? Because human attention doesn’t scale, and unlocking meaningful autonomy requires moving some big rocks: serious investment in infrastructure, permissions, and trust.

Let’s start with attention. In our data, we find that 81% of developers max out at one or two agents at a time. Even developers who occasionally run four or more spend the vast majority of their time focused on just one. We see this frequently: human attention has hard limits, making it a precious resource and a potential bottleneck.

So how do you move past the attention cap?

Invest in context. Autonomy starts with agents that have access to everything they need to know to work unsupervised, armed with both the information they need and the ability to answer new questions independently. A great place to start here is context files like Cursor rules and Claude skills, which have become default patterns for customizing coding agents. In a recent study of Cursor users, we found that the heaviest skill users merged 27% more PRs than the baseline.

Move the big infrastructure rocks. Meaningful autonomy requires significant platform investments like sandboxed environments, permissions, orchestration, and access to data. These are major efforts, and I see many teams struggling to prioritize investing in them. An agent that is held captive on your laptop and can’t access important code or data without your direct oversight will be perpetually limited in its usefulness.

Treat trust as a platform investment. Infrastructure investments aren’t the only thing giving teams pause; they are also concerned about quality and risk. Unfortunately, there aren’t really shortcuts to building trust. Guardrails, evals, observability, and access controls can help, but ultimately trust takes time, which is why teams need to start building it as soon as they possibly can.

Suppose you crushed every challenge in the last section—you’ve got agents that run in the background, and can orchestrate them in ways that start to look like the “software factories” everyone is buzzing about. Unfortunately, there’s still another headwind. Our data shows that in this regime, you should expect to see token spend climbing faster than output. Before long, you may really start to feel the pain of these diminishing returns.

There are a variety of reasons why token costs start to compound at this level, such as more unshipped work, more optionality and parallelism, and higher review and integration costs. But what can you do about them?

Address the merge-rate gap. We find that agent-authored pull requests currently merge at about 61%, versus about 79% for human-authored PRs. In other words, when a human opens a PR, it dies on the vine about 20% of the time (typically for good and totally mundane reasons). For agents though, the rate of dead PRs is double that.

The biggest culprit here is the review bottleneck. Code got faster to produce, but for most teams review and integration are struggling to keep up. If you’re scaling agents, your agent merge rate is one of the most important numbers you can watch, and improving it is usually about process (review capacity, PR sizing, verification before the PR opens) rather than model quality.

Recognize that not all unshipped work is waste. Agentic coding has unlocked new ways of working and dramatically lowered the opportunity cost of exploration. So, perhaps it’s not surprising that we find that agent PRs are 4x as likely as human PRs to be “speculative work” (prototypes, spikes, explorations, or parallel solutions). These new ways of working yield real benefits, trading token cost for things like faster time to market or de-risking product investments. The goal isn’t to drive unmerged work to zero; it’s to make the speculation deliberate and to know which work is intentionally disposable versus which is waste.

Watch compounding coordination costs. It’s well known for human organizations that increasing complexity comes with nonlinear costs (e.g. Brooks’s Law). Complex agent workflows are subject to similar scaling dynamics. We find that as token spend climbs, an increasing share of the work is agents reviewing, integrating, and aligning with other agents. For example, among the bottom decile of token spenders, about 1 in 8 tool calls goes to review and integration, versus 1 in 4 for the top decile. Whatever the equivalent of Brooks’s Law for agents is, I doubt we can repeal it—but you can measure it, and squeezing coordination overhead is one of the highest-leverage optimizations available in the high-spend regimes.

Track outcomes over outputs. The most sobering version of the diminishing-returns story shows up when you look past pull requests. Remember the stat earlier where 10x token spend was producing 2x the PR throughput? If you look instead at deliverables (e.g. actual features and epics shipped), the gain is only about 27%. How can this be possible? Basically, coding got dramatically faster but the rest of the machine is lagging. Roadmaps, release processes, enablement, and planning still move at the old cadence, so the extra capacity just bleeds out anywhere it can, like bug backlogs, speculative work, and internal tooling—things that might be helpful, but don’t drive the business like new products or customer-facing work. In this light, the most impactful fixes are the least technical of all: evolving all the processes around engineering, and measuring the token cost of what actually reaches a customer.

As someone who did a bit of genuine rocket science early in my career, I certainly love this rocket equation analogy. However, the good news is that the analogy only goes so far. Unlike aerospace engineering, the token curve isn’t governed by immutable laws of physics; it’s a snapshot of what’s happening in an industry where we’re all still figuring out how to do this well. It’s observational, which means individual organizations can (and do) beat the odds, and as best practices for context, autonomy, trust, and process catch up with raw code generation, the entire curve could very well bend.

A hundred years ago, Robert Goddard launched the first liquid-fueled rocket from a farm in Auburn, Massachusetts. His breakthrough wasn’t building a bigger rocket or burning more fuel than anyone had before; it was designing an engine that worked. That’s the challenge in front of engineering organizations right now: learn to be good rocket scientists.

Token spend is scary for a lot of organizations right now, and unfortunately the pain is going to get worse, because we’re all going to spend astronomical amounts of fuel in the coming years—we have to because we’re going to astronomical places.

I’ll end with the same challenge I gave the audience in San Francisco last month:

Don’t just code faster. Code further.