The Scale Is Tipping: Human Hours vs. Machine Tokens

We are in the early stages of a technological transition that is being misunderstood regarding two key aspects: the evolution of software development in the era of generative AI and the way in which the cost of programming is beginning to shift from developers’ paychecks to tokens.

The idea stems from a Gartner prediction that struck me as particularly significant: by 2028, the monthly cost of AI-powered programming tools could exceed the global average developer’s salary — something InfoWorld also highlighted in an article about how a company’s token costs in programming are on track to rival the payroll. The issue isn’t, as so many simplistic headlines claim, that programmers are going to disappear, but rather that the economic balance of software development is shifting in a much more profound way: a growing portion of what was previously accounted for as human labor hours is now expressed in terms of computational consumption, iterations, context, agents, and tool calls.

I’ve been mulling this topic over for some time, which is why this piece ties in with several previous posts I’ve published on the transformation of the developer’s role. In “Code is becoming cheap, judgment is becoming expensive” I discussed that growing divide between those who view AI as a threat and those who turn it into an extension of their capabilities. In “AI was supposed to replace developers, so how come there are so many?” , I analyzed this shift in the labor market: less typing code and more designing, reviewing, interpreting, deciding, and taking responsibility for systems that generate code. In “AI in coding and education, from ‘cheating’ to ‘requisite’”, I argued for the need to stop treating these tools as a form of cheating and start understanding them as a basic skill. And in “What a $500 million Claude bill means”, I addressed the problem of the hidden cost of that supposed magic — or the folly of unconditionally incentivizing the consumption of tokens.

This shift is interesting because it forces us to rethink how we define productivity. For years, companies have measured software development productivity using metrics that are as convenient as they are misleading: lines of code, completed user stories, resolved tickets or delivery speed. With AI, these metrics become even more dangerous. Generating code is becoming increasingly cheaper, faster, and more abundant. The problem is that generating more code does not necessarily equate to generating more value. In fact, it can amount to creating more technical debt, a larger attack surface, greater dependence on vendors, and more complexity that someone will have to understand, audit, and maintain.

Therein lies, in my opinion, the fundamental shift: the bottleneck is no longer in writing code but in validating it. A valuable developer is no longer simply someone who knows how to produce correct code, but someone who knows how to formulate the problem well, choose what should and shouldn’t be automated, limit the scope, evaluate the result, detect plausible errors, and decide when a seemingly brilliant solution is actually a ticking time bomb. As said, code is becoming cheaper, while judgment is becoming more valuable.

This idea also appears in other recent studies. The Stack Overflow survey on AI shows how developers are adopting these tools, and also how they maintain significant reservations about their accuracy and reliability. The Google Cloud DORA report argues that software productivity cannot be understood simply as speed, but rather as a balance between delivery, quality, reliability, and organizational culture. McKinsey has analyzed the potential of generative AI to increase developer productivity, but its own findings point to something worth keeping in mind: the impact depends heavily on the type of task, the context, and the organization’s ability to redesign processes — not simply on plugging in a tool and expecting miracles.

I also found a Gitlab study on organizations that generate code with AI faster than they can control it useful: companies delighted with the speed of code generation, but unable to build the review, security, governance, and traceability mechanisms that such speed demands. AI can turn a good team into an extraordinarily productive one, but it can also turn a mediocre organization into a factory of hidden liabilities.

The comparison with managers seems inevitable to me. Microsoft has discussed the rise of agents and organizations will have to redesign the relationship between people and autonomous systems, while McKinsey has highlighted the role of middle managers in the adoption of generative AI. Ultimately, developers and managers face a similar evolution: both are shifting from performing specific tasks directly to managing systems that perform them. The difference between the two will not lie in who uses more AI, but in who knows how to manage it better.

That’s why I’m so interested in this transition. We’re not dealing with a simple replacement of humans with machines, but rather a redistribution of costs, responsibilities, and competencies. Anyone who thinks it’s enough to lay off developers and pay tokens hasn’t understood a thing, and is going to fail miserably. The same goes for thinking it’s enough to keep all developers doing exactly the same thing they’ve always done. The company that understands this transition will learn to manage tokens as a scarce resource, to measure value rather than activity, to train its teams to work with agents and to distinguish between sensible automation and irresponsible enthusiasm.

Programming isn’t going away. It becomes more abstract, more strategic, and — paradoxically — more human about what really matters: judgment, responsibility, architecture, understanding the problem, and the ability to say no. What’s probably coming to an end is a certain idea of the programmer as a mere producer of lines of code. And what’s beginning is a far more interesting phase, in which the real differentiator won’t be who creates the most software, but who knows which software is worth creating in the first place.

(En español, aquí)

—

This post was previously published on MEDIUM.COM.

—