A challenge that organisations face is “Tokens can be stored, but coders gotta code.”. Tokens are liquid, you can buy them when you need them. That means you can store your token budget until you need to consume the tokens. Coders are not liquid, you pay for them when they are in attendance, regardless of whether they have work to do. To put it another way, a coder sitting around doing nothing costs the same as the same developer creating or maintaining valuable code.

Furthermore, when coders are in attendance, they will be using tokens. Developers with Agents might be 4x developers. The same developers without Agents will probably be 1/4x developers as they will no longer be able to work in the way they used to. Its the same as taking away a modern laptop from a developers and asking them to go back to punch cards.

Many product managers see their role as “feeding the beast”, feeding their development team with a constant stream of stories to keep them busy. This means product managers will often create stories that keep developers busy rather than stories that deliver business value by satisfying the needs of a customer segment. Product Managers who “fail to feed the beast” will be punished, whereas those that “fail to deliver business value” can easily explain why their experiments did not work.

This option to choose when to invest in tokens, rather than a commitment to consume a developers time continuously has impact on the value of tokens versus developers. The ability to choose “when” an investment is made will drive organisations’ development strategy. Companies will favour higher token cost and lower developer cost rather than higher developer cost and lower token cost. In effect minimise the committed costs (developers) and maximise the optional costs (tokens).

To illustrate this, consider a traditional developer team of six, consisting of two senior devs, two developers and two junior devs costing $100k, $70K and $50K each respectively, at a total cost of $440K

Now consider the “Feed the beast” ratio of the team of 0%, 50% and 75% busy work, and finally AI capacity uplift of 10%, 100% and 400%. How much would an organisation be prepared to spend on token versus developers? What is the break even point for a team of a one Senior Dev, one Dev, and one Junior Dev?

In teams with high “feed the beast” ratio, and a high capacity uplift, the tokens are worth four times the cost of the three developers…. simply because they can be stored and only applied when needed.

This is a very basic way of looking at the value of the tokens. A more sophisticated approach would be to use real options and real liquidity… The detail would get in the way of the message.

The ability to store tokens is very valuable, compared to the committed costs of developers. Perhaps we will start to see zero hour contracts for developers?

Now lets be clear, the value and the cost very rarely have anything to do with each other, especially in competitive markets.

What are the practitioners out there seeing? Are executives starting to consider a new economics of development?

Before AI, Technology costs were easy to control. Executives via the finance department would control costs through the hiring process and procurement process. Cost were controlled by limiting the number of developers. In actual fact, most organisations do not control costs, they control the day rate or the amount paid per day (week, month or year). Each year (or quarter), the executives would decide how much they want to spend on technology for the rest of the year and adjust head count accordingly. The main benefit of this approach is that the maximum cost for a time period (e.g. a month or a year) was controlled.

Very few organisations have effective control of the costs of investments. There are too many sources of uncertainty and variability. Finance can control the maximum cost of a team per month but they cannot control the number of months that the team will be required to deliver an investment. A widely used industry heuristic (but not in finance) is that the cost of the investment will always cost twice what you think it will cost. Todd Little’s research showed the actual versus estimate follows a log normal (Wiebel) distribution with a mean of x2 and in ten percent of cases x4.

This approach of controlling head count meant that technology projects never unexpectedly spend more than budget in a month or year, even if the cost of the investments themselves resemble a bus crash in slow motion. The source of bankruptcy is not going to be unexpected cost overspend for a period, even though an investment may eventually drag an organisation down in a tragically visible manner.

AI token usage will lead to a loss of control due to unplanned spending. Unlike headcount, maximum cost of token usage cannot be controlled. A developer (AI or human) fires off an agentic job to generate code (or some other task). For the past few months, the cost of an agentic job has been $100, however for some reason this task is different and the cost is $50,000. As with human developers, the actuals versus estimates of jobs follows a distribution which has a long tail.

The obvious answer is to provide a limited number of tokens for each developer. Now the developers keep hitting the limit half way though jobs and both time and tokens are lost… which drive down speed and efficiency. The manager handing out extra tokens soon gets fed up with the approval process and automates it. If you think you can control costs using spending limits, think how comfortable you are going to feel about telling your boss the following…

• “We sent all the developers home because we ran out of tokens.”
• “The developers wanted the day off so they created an agent to burn through all the tokens generating images of cats doing cool things.”
• “We hit the monthly token limit for this project, so we are switching to a project with tokens left.”

Although controlling token usage will be a nightmare, a bigger nightmare will be the transparency that token usage will bring. Investments will be assigned a token budget. It is well known that development teams often need to switch developer time between budgets…. A few days of support that gets booked as time spent on the strategic initiative. Development teams get away with it because there is no way to track what a developer is actually working on. Token usage will be tracked against the investment being worked on. At the end of the month, the business investor will look at the tokens charged to their investment and demand to know what has been done. “Jazz hands explanation” that the Agent was just doing some thinking or working on some technical debt wont be a justification.

The solution? I do not know. I’d be keen to hear from practitioners who have cracked this one.

It is clear that Technology Departments will need to be better at providing transparency into the money they spend and which investments or operational activity it gets spent on. ( I do have a solution for this. 😉 )