Dieser Blogpost ist auch auf Deutsch verfügbar
TL;DR
- 75 dollars in token costs replaced several days of work. The return is real, but the actual question is why these 75 dollars could create so much value at all.
- The agent is the technology, system understanding is the complementary asset (Teece). Remove the people who hold that knowledge and you keep the technology but lose the ability to use it correctly.
- Experienced developers' salaries buy options (Taleb): coding agents suddenly make those options valuable, provided the system understanding is still there and handling the agent is practiced.
- Layoffs and a freeze on junior hiring destroy exactly this optionality, and unnoticed at that: token costs are an easily measurable flow, system understanding an invisible stock (Daly).
Recently, within two working days, I generated about 75 dollars in token costs. The result was a major overhaul of a codebase that, without agentic development, I would easily have estimated at five to six full-time days of focused deep work. Those two days, by contrast, were very fragmented, with meetings and other interruptions. That is a pretty good return on investment. The interesting question, though, is why these 75 dollars were able to create so much value in the first place. What conditions have to be met for what you buy with 75 dollars to be worth that much?
The case
In my specific case, it was a Java project with a hexagonal architecture that implements a data processing pipeline. The overhaul affected 449 changed, new, or deleted files. An archiving step that stores data in CSV format in cloud storage had to be removed. This also required a change elsewhere, where these CSV files were used, in order to read the data from the internal database instead. In the end, it was several thousand lines fewer than before the overhaul.
My own role in this was narrow. I formulated a clear goal and then made small, but sometimes also critical, corrections to what the agent proposed and implemented. This division of labor is reminiscent of military mission command: leadership defines the why and delegates the how.
It did not work entirely without oversight, though. The implementation contained a critical bug in determining the sequence-number boundary of the data to be exported. Undetected, it would have left the export permanently running empty.
What the 75-dollar figure conceals
In The Principles of Product Development Flow, Donald Reinertsen named a mistake that many organizations make: they optimize what is easy to measure and overlook the overall economics, which cannot be captured in the same unit. Token costs are such an easily measurable quantity. Thanks to tools like LiteLLM, you can pin down exactly what this refactoring cost. Companies that obtain AI via flat-rate subscriptions instead of usage-based billing do not even see this side in granular detail.
The return, on the other hand, remains an estimate, not a measurement. My five-to-six-day figure is an assumption, not a measured value. If you trust the estimate, the question of whether the use of AI was worth the money can then be answered trivially with yes. And precisely because this figure looks so convincing, the second question often follows seamlessly: can we now reduce headcount accordingly?
In 1986, David Teece showed why this second question falls short: a technology only creates value in interplay with complementary assets that are not part of the technology. The agent is the technology. The system understanding is the complementary asset. Whoever keeps the technology but removes the people with the system understanding does not lose the technology, but the ability to use it correctly. What this system understanding is worth can even be quantified: as an option value.
The salary buys options
In Antifragile, Nassim Taleb writes about optionality. It is about turning a positive shock disproportionately into your own gain, in other words a positive asymmetry. A developer’s annual salary does not only pay for the output they deliver in that year. If an organization employs developers over many years, during which they have built up technical and domain expertise as well as a deep system understanding, then for part of the annual salary it acquires options.
The positive shock was the emergence of coding agents. Organizations can now benefit asymmetrically from the options they have acquired. This asymmetric payoff draws on two capital stocks: on the one hand, there is system understanding as well as the technological and domain expertise that has been built up. But these alone are not enough. Necessarily added to this is the practiced handling of the agent itself. Unfortunately, in many companies there is currently a tendency to destroy this optionality in the medium to long term.
On the one hand, there is the reflex to lay off developers, because for token costs that are significantly lower than the salary you apparently get the same value in return, while overlooking that this value was tied to the person, not to the technology. On the other hand, we observe in our industry a strong reluctance to hire juniors. If no more juniors are hired because AI takes over the supposed entry-level work, then no new options for the future are acquired either. This does not feel like a loss. It is merely an investment that does not happen, and investments not made show up in no cost accounting.
So AI does not lower the value of expertise. It lowers the strike price of an option that already exists. Provided you have learned how to exercise it. And provided you do not destroy it at exactly the moment when it proves valuable.
Is expertise really like coal?
Apart from destroying your options through layoffs or by not hiring juniors, there is also the question of whether the repeated, permanent use of this ability does not itself have a negative effect on the asymmetric payoff function, that is, whether you gradually erode your optionality in the process. Loss of competence through delegation and automation can have exactly this effect and cause system understanding to decline. The 75 dollars in token costs then no longer buy the value they were able to create at the outset.
The obvious metaphor: expertise is like coal. Built up over years, quickly burned, not quickly regrown. But that only captures it partly.
In my case, architectural judgment was not shut down but constantly used, since I proceeded in a fairly tight loop in the sense of the Omega Programming paradigm. This judgment is thus trained through active recall, even without typing anything yourself. Mechanical execution skill, by contrast, is surely lost (a colleague recently told me he can no longer remember certain keyboard shortcuts that you need when typing code), but it was never the scarce resource.
What remains open is: how much doing of your own does it take to preserve, in the long run, an adequate mental model of the system’s reality? Peter Naur showed that the theory of a program has to be continuously renewed against the codebase, otherwise it drifts unnoticed.