Software production is shifting from labour-constrained to compute-constrained. Money now buys cognitive throughput directly. But tokens multiply the system they are plugged into, and the multiplier can go negative.
Author: James Phoenix | Date: July 2026
The Old Constraint Was People
For the entire history of the industry, scaling software output meant one thing: hire more programmers. The pipeline was slow and expensive at every step. Recruit, onboard, coordinate, pay a salary, absorb the management overhead, and hope the person stays long enough to repay the onboarding cost. The marginal unit of production was a human, and humans come with notice periods, ramp-up curves, and meetings.
That constraint shaped everything. It is why headcount was the universal proxy for engineering capacity, why “we don’t have the people” was a legitimate reason not to build something, and why a solo developer competing with a funded team was mostly a romantic story.
The New Constraint Is Compute
The pipeline I actually run now looks nothing like that. Allocate tokens, run agents in parallel, review the outputs, merge the useful work. The marginal worker is rented by the token, activated in seconds, run overnight, and discarded without an exit interview.
I burn through hundreds of dollars of subscription capacity a month across Claude Code and Codex, and the striking thing is not the number. It is that the number is the constraint. I hit usage limits, not hiring pipelines. Software production is moving from labour-constrained to compute-constrained: the binding limit is how much artificial cognition you can afford and direct.
This is why software increasingly feels pay to win. Money used to buy engineers at one remove, with all the friction of an employment relationship in between. Now it buys cognitive throughput directly, the way quant firms buy compute, factories buy machinery, and film studios buy render farms. Developers have joined the capital-intensive professions.
The Production Function
The relationship I keep coming back to:
Value = Tokens × Engineering leverage − Coordination debt
Each term deserves its own treatment, but notice the shape first. Tokens are a multiplier, not an addend, so they amplify whatever they touch. And the equation has a subtractive term, which means it can go negative. You can spend more on AI and end up with less software. That minus sign is the most important character in the equation, and most of the discourse about AI-assisted development ignores it entirely.
Tokens: What Money Actually Buys
Someone on a $20/month plan can attempt one implementation of a hard feature. On ten times the budget I can attempt several, run adversarial reviews against each, generate the test suites, compare the architectures, and throw the losers away. I am not ten times more skilled than the $20 developer. I can simply afford to explore ten times more of the solution space, which is the economics of Zero-Cost Divergence with a price tag attached.
That is what tokens buy: attempts, parallelism, retries, and verification passes. Breadth of search, purchased by the drink. Nothing about that requires talent, which is precisely why it feels unfair, and precisely why it is only one term in the equation.
Engineering Leverage: The Multiplier
Tokens multiply the system they are connected to, and most systems do not deserve multiplying.
A weak engineer with unlimited tokens produces huge incoherent diffs, duplicated abstractions, architecture drift, superficially passing tests, and technical debt accumulating faster than anyone can comprehend it. The tokens work exactly as advertised. They amplify the operation, and the operation is bad.
A strong engineer with a good harness gets disproportionate value from the same spend, because every agent runs inside constraints that direct, bound, and verify it. Repo-owned architecture docs, executable acceptance criteria, eval gates that must pass before an agent may declare success, separate agents for implementation and adversarial review. This is the argument of The Harness Is Cheaper Now restated as economics: the harness is not overhead on top of your token spend, it is the exponent on it. The spec-driven camp is really the camp that understood this term of the equation first.
Coordination Debt: The Term Nobody Prices
Watch where a heavy token budget actually goes and three kinds of burn appear.
Productive burn: features implemented, tests written, bugs fixed, migrations run. The thing you are paying for.
Coordination burn: re-explaining the repo to a fresh context, correcting architectural drift, reviewing mediocre patches, asking agents to redo work they almost got right. The tax of managing workers who forget everything between shifts.
Thrash burn: five approaches started, four abandoned, enormous diffs generated and discarded, agents wandering without a termination condition. Agent sprawl is thrash burn with a mechanism attached.
Coordination and thrash burn cost tokens at exactly the same rate as productive burn, and they also cost the one thing tokens cannot buy, which is my attention. This is where the “middle manager to a pair of energetic junior engineers” feeling comes from: the coordination term compounding quietly while the token counter looks impressively busy. The failure mode is not spending $400 a month. The failure mode is spending $400 a month to become the unpaid project manager of workers who never learn. Every invariant moved into a repo-owned doc, every acceptance criterion made executable, every eval that replaces a manual review is a repayment of coordination debt, and repaying it raises the leverage multiplier at the same time.
The Stratification
Play the equation forward and the industry splits into three groups.
Developers who use one chat window occasionally. Developers running several coding agents continuously. And operators running evaluated, parallel agent pipelines with real compute budgets, whose output starts to resemble a small engineering department.
The gap between these groups widens, because the terms compound. More tokens justify more harness investment, a better harness raises the return on every future token, and the operator learns to spot coordination debt before it metastasises. Meanwhile the bottleneck skills stop being typing speed and recall, which were always proxies anyway, and become deciding what should exist, defining correct behaviour, decomposing work, and maintaining architectural coherence. Exactly the skills concentrated at the planning and validation boundaries.
Return on Tokens
So yes, software is becoming pay to win, in the narrow sense that money now converts into engineering throughput with far less friction than hiring ever allowed. Current subscription prices are almost certainly the introductory offer. The moment an agent can reliably turn $2,000 of inference into more than $2,000 of economic value, serious builders will spend it without blinking, the way factories buy another production line.
But the equation says the durable advantage is not the token budget. Tokens are the most commodified term, available to anyone with a credit card. Leverage and coordination debt are built, and they compound privately. The winners will not be whoever buys the most tokens. They will be whoever earns the best return on tokens. Which raises the obvious next question, how you would even measure that return, and that question has its own note: Measuring Coding Agent Leverage.
