I spent ten minutes with Claude Code one evening this week.
Not ten minutes prompting, or tweaking, or trying to discover the right incantation. Ten minutes actually working. In that time, it produced roughly forty-eight thousand lines of code.
That number is absurd enough that it immediately invites skepticism, including my own. So I measured it. I tracked what was happening, how much time I was actually involved, and what the output looked like when translated into the units we normally use to reason about engineering work.
What unsettled me was not simply the volume of code. It was how little my own pace seemed to matter. The system continued to produce whether I typed quickly or not. My role drifted almost immediately from writing to deciding, redirecting, and occasionally stopping it from going somewhere unhelpful.
Curiosity turned into instrumentation. I built a few Grafana dashboards to see what was actually happening under the hood. Over the course of an hour, the system generated about forty-eight thousand lines of code. My direct involvement during that window totaled roughly ten minutes.
Using a very generous estimate of seventy-five production-quality lines per developer hour, that output corresponds to nearly four weeks of work. When I ran multiple agents in parallel across two repositories, the ratio climbed even higher. Briefly, it reached five figures.
I do not think lines of code are a meaningful proxy for value. I have spent enough of my career deleting them to be certain of that. But lines of code are still how organizations budget, staff, and estimate. In that context, the arithmetic becomes difficult to ignore.
A senior engineer costs something like one hundred fifty to two hundred thousand dollars a year when fully loaded. Call it a hundred dollars an hour to keep the math honest. At that rate, each line of production code costs roughly a dollar.
The cost per line I observed here was a fraction of a cent.
I am on a two-hundred-dollar-per-month plan. In one hour, the system generated over seventy dollars’ worth of equivalent API output. My share of that hour’s subscription cost was less than thirty cents. Whatever else one thinks about this setup, it is not expensive.
At this point, there is usually an objection, sometimes spoken and sometimes not. Surely you cannot be reviewing tens of thousands of lines of code. Surely quality collapses under that kind of volume.
Of course I am not reading it line by line. That would be pointless, and it would miss the more important shift that is happening here.
The responsibility for quality moves upstream.
I rely on automated tests that fail loudly and early. I track not just whether tests pass, but how well they interrogate the code: branch coverage, mutation testing, behavior-level acceptance criteria written before implementation begins. I use specialized agents that critique one another’s output. Guardrails prevent dangerous operations before they happen. When something breaks, I see it immediately.
What I spend my time on looks very different than it used to. I define constraints. I clarify intent. I decide what matters enough to pursue and what should be abandoned early. When the system disagrees with itself, I intervene. When it behaves correctly, I largely stay out of its way.
This has uncomfortable implications for teams.
A single developer, equipped with these tools and some discipline around how to use them, can now produce the raw output that would previously have required an entire organization. That does not mean judgment, taste, or architectural sense have become irrelevant. If anything, they matter more, because they are now the limiting factors.
The question facing engineering organizations is not whether this is philosophically satisfying. It is whether they can afford to ignore it. Faced with this kind of leverage, choosing not to experiment starts to look less like prudence and more like denial.
The work itself has changed shape. The job used to be producing code. Increasingly, it is about defining outcomes, setting boundaries, and validating behavior. It feels less like typing and more like directing, less like construction and more like editing.
If you want to dismiss this as “vibe coding,” you can. If you want to worry about what it means for junior engineers or for the craft itself, those concerns are legitimate and worth discussing. But the economics are already here, quietly rearranging incentives.
The multiplier is no longer a nice bonus.
It is the work.
Top comments (0)