The AI Headcount Equation

AI makes each engineer more productive, so companies everywhere are rethinking how many engineers they need and how much of the work AI can absorb. I think the math behind that decision is more complicated than it first looks, and I want to walk through the terms it’s usually missing.

The naive version of the math looks like this:

(fewer engineers × salary) + token cost  <  today's engineers × salary

In other words, a smaller team using AI should cost less than the current team, and the difference is the savings. A lot of companies are running this calculation right now. However, I think it leaves out a few terms that decide whether the trade actually works.

The Cost of Adopting AI

First, it’s worth understanding why the cut is even on the table. The whole industry leaned into AI at once, so adopting it stopped being a choice. If your competitors ship faster because their engineers have AI behind them, you have to adopt it as well to keep up. That makes AI a cost of doing business.

And it’s a real cost that includes more than just tokens. There’s also the harness around the model that makes agent output trustworthy enough to ship: the evals, the observability, the test infrastructure, and the context and memory plumbing. None of it is a one-time build you amortize and forget, and the costs grow as you push for more output:

• More agents means more orchestration to build and maintain.
• More output means more behavior to observe and evaluate.
• More AI-written code means more surface area to test and maintain.

Most companies didn’t have this line item a year ago, and it grows the harder the team pushes for output.

Paying for AI with Headcount

If you bolt AI onto your existing team, your burn goes up, because now you’re paying full salaries and a growing AI bill on top. To hold burn where it was, something has to give, and that something is usually headcount. From what I’ve seen, these layoffs are less about AI replacing anyone’s job and more about freeing up salary to pay for the AI itself.

There’s a second reason as well. AI amplifies whoever is using it, so companies want that leverage concentrated in their strongest engineers. When one engineer with AI is making ten or a hundred times the decisions, you want those decisions coming from your best people. So the cut serves two purposes: it funds the AI, and it decides who gets amplified by it.

The Productivity Gains

And you might genuinely come out ahead, because the productivity is real. Garry Tan has been doing the public math on it, and even after you discount the extra verbosity AI produces, you’re left with a large multiple. A single strong engineer with good tooling can now produce what previously took a small team.

On paper, the trade looks great: the same burn with fewer people and more output. If that holds, it’s less of a cost cut and more of an investment, and it would be a mistake not to take it.

The output can also be higher quality, but only if you’ve built the evals and tests to verify it. Without that verification, you’re just shipping mistakes faster.

The Attribution Problem

Most of this equation is measurable: the salaries you cut, the tokens you burn, the infrastructure you maintain, and the output showing up in PRs and shipped features. However, the payoff is much harder to measure, because you can’t tell how much of the company’s results that extra output is responsible for.

Value is rarely traceable at the level of a single feature. At the level of the whole company, the results are real, but there are too many other factors involved: the market, the sales motion, the product bets, and timing. If the business does better, you can’t prove that AI-amplified velocity was the reason rather than any of those, and it never lands on the P&L with its own line.

That leaves you paying an immediate, itemized price for a return that is deferred and hard to attribute. It’s a dangerous combination, because it makes it easy to convince yourself the payoff is there when you can’t actually verify it.

There’s another risk here. AI speeds up whatever you’re already doing, and that includes building the wrong thing. If you have product-market fit and know your unit economics, moving faster compounds in your favor. If you’re still guessing what to build, you’re now guessing more expensively.

The Problem for Startups

All of this is survivable for a company with margin. A big company adopts AI, the cost line grows, a quarter looks worse than planned, and the existing business absorbs it while everyone waits to see if the output pays off.

A startup runs the same bet with runway instead of margin, and every part of it hits harder:

• Startups have to compete on speed to matter at all, so adopting AI isn’t optional for them.
• Every dollar of AI spend comes directly out of the months of runway they have left.
• If the payoff doesn’t materialize, there is no next quarter to adjust in.

Unfortunately, the startups under the most pressure to show progress before their next raise are the same ones that can least afford the bet if it doesn’t pay off.

For a startup, the more important question isn’t how many people to cut, but whether the extra output actually turns into a working business before the runway runs out. I don’t think there’s a universal answer here, but being honest about the missing terms in the equation is a good place to start.

// END