Capacity got cheap. Judgment did not.

A senior software engineer in a major market costs comfortably over a hundred thousand dollars a year once the employer's side is counted. That figure is not ours; it is the public reference point everyone building software has internalised as the price of entry. Set beside it the two line items that now supply much of the same production capacity: an agent subscription in the low hundreds of dollars a month, and a handful of virtual CPUs on a shared host, cheap enough against either to barely move the arithmetic. These are different kinds of purchase, and hiring a person was never only a way to buy output.

What collapsed is capability per dollar. An agent carries no memory of a decision taken months ago unless somebody wrote that decision down. It has no relationship with anyone, so it cannot be trusted the way a person is, on the evidence of a hundred previous calls. It cannot be accountable either, because accountability is something you hold a person to across time and this thing has no across-time. It holds no view about what deserves to exist. Describe a mediocre feature well and it will build exactly that, quickly, with tests.

That list reads better as a job description than as a set of complaints. Remembering why the system is shaped the way it is, being trusted because of the last hundred calls, deciding whether a thing deserves to exist at all: that half of the work stays with the people. The engineering problem of the past two years has been the working relationship between the two, which mostly comes down to what has to be written down before an agent can use it and what has to be checked after.

Raw production capacity is no longer the thing our studio budgets for. Writing the code, wiring the endpoint, migrating the schema, sweeping a rename through forty files: that work used to set how many engineers you needed and how much money you had to raise before you were allowed to start, and we now buy it on a subscription.

What the objection gets right

The strongest version of the counterargument has nothing to do with hype. It is that capability is uneven in a way averages hide. We have watched an agent carry a schema migration cleanly through every call site it touches and then, on a task no harder, write against an interface it half-remembers, passing an option that has never existed. The lumps in that distribution sit nowhere a career of supervising engineers teaches you to look, so the instinct transfers badly.

The objection is right, and it moves the cost rather than cancelling it. Verification scales with the consequence of a change more than with the volume of code, and it answers to engineering effort in a way headcount never did.

Everything else prints a receipt

Every remaining line of a modern product's cost structure meters itself. Hosting bills by request and function-second, the database by compute hour and gigabyte, and storage, egress, transactional email and model usage all price per unit on a dashboard that updates continuously. Our usage numbers from Vercel and Supabase arrive on the same timescale as the work that generated them.

The old sequence put the invoice at the end: ship the feature, wait a quarter, then find out in a finance review that the thing people love most is also the thing burning the most compute. Now the running cost shows up in the week the feature is written, early enough to price the product around it.

The constraint moved

Put the two halves together and the main constraint on our studio has moved. 'Can we afford to build it' used to shape what we attempted, how many things we ran at once, and whether we raised money at all, and for us it matters much less now. Two harder questions took its place: do we know what to build, and can we tell whether it worked.

• Knowing what to build: which of eleven plausible features is the one people will use, before the evidence exists.
• Distribution: the standing ability to put a working product in front of the people it is for. Engineering getting faster does nothing for it.
• The discipline to kill things, which is the hardest of the three because it means conceding that the work was good and the bet was wrong.

Judgment and verification were always the scarce inputs. The cost of producing code kept them out of sight: when capacity was the expensive part, a studio could be wrong about what to build for a long time and blame the roadmap or the quarter. Plenty of ordinary mistakes survive the change, including an implementation that is wrong, a service that falls over under load, and a change that shipped because nobody confirmed it worked. Those have known remedies and bounded costs.

The shape this makes

When the marginal cost of attempting a product falls far enough, the sensible shape of a small company changes with it. Committing everything to one guess made sense when a guess cost a year of salaries, and concentration was a response to that expense as much as a conviction about focus.

We run a handful of products at once — Eloist is the busiest — with agents working directly on the repos and modest shared machines underneath. At the cost structure of a few years ago that would have been dilettantism; at this one it is ordinary portfolio behaviour.

The real risk never shows up on a bill. Cheap attempts make it easy to accumulate a graveyard of things eighty percent finished that nobody depends on. Our portfolio is more likely to outrun our attention than our budget, and attention is the input that did not get cheaper. So we run fewer live bets than we can technically afford, and close the rest while closing them is still cheap.

The company shapes we inherited were rational answers to expensive capacity. Raise a round to buy a team, grow the team until it needs process, adopt process that makes each decision slower and more expensive to reverse. Every step followed from the cost of production, and the cost of production changed. A small team can hold several real products at once now, with the machines supplying capacity and the people supplying judgment, and whether it should comes down to how quickly and honestly it can tell which of its bets is working. Companies used to be built around the expense of building. Increasingly they will be built around the expense of knowing.