Software Engineers or Tokens

The most valuable engineer on a team used to be the one who could get from a problem to working code the fastest. Quietly, that has stopped being true. The fastest typist is being replaced — not by a machine, but by the person at the next desk who learned to spend tokens.

For most of the history of our craft the scarce resource was human hours. You wanted more software, so you hired more people, or you asked the ones you had to stay later. Now there is a second resource, cheaper and stranger: the token, the unit a language model reads and writes. On a growing list of work, a pile of tokens outweighs a pile of human hours. Not because tokens are smarter than us. Because they are more elastic.

Tokens fan out for free. Ask a person to apply the same migration across forty services and they get sloppy by the twelfth; tokens give the fortieth the same attention as the first. They are patient with exactly the work that burns good engineers out — the tests nobody backfills, the fourth integration against a badly documented API, the TODO from 2023 that loses every priority battle against shipping. And they make being wrong cheap, so you can try three approaches and throw two away for the price of a coffee.

It is tempting to read all of that as "we won't need engineers." That is exactly the wrong conclusion. Tokens are tireless and fast, and they are also confidently wrong. A model will hand you a beautiful, plausible, subtly broken solution with total composure. It doesn't know about last quarter's incident. It doesn't feel the cost of being wrong. It won't be in the room when the pager goes off.

Writing the code was always the easy part. The hard parts — deciding what is worth building, judging whether the output is actually correct and not merely plausible, holding the context that lives in hallway conversations and old postmortems, owning the consequences when something breaks — none of those got cheaper. When the typing is free, judgment becomes the whole job.

So the winner is not the machine, and not the engineer who pretends nothing has changed. It is the engineer who knows how to spend tokens well: who can break a fuzzy goal into pieces a model can execute, specify them precisely, and catch the confident-but-wrong ten percent before it ships. It was never software engineers or tokens. It is software engineers times tokens, and that beats an engineer working alone, badly.

The industry will keep hiring engineers. It will just prefer a different kind — the ones who treat tokens as the most flexible tool they have ever been handed, and who bring the one thing tokens never will: the judgment to know what is worth doing, and whether it was done right. Spend your tokens well.