What Managerial Economics can tell us about AI and Software Development
Charlie Munger used to analyze investments by having a latticework of interdisciplinary mental models of how the world worked.
And I love the idea.
I don’t have as many as he did (I believe he had 80-90 mental models), and many of mine come from my Economics background. So, perhaps they’re not very “well rounded”. But they sure are useful!
The mental model I’ve been thinking about lately comes from Managerial Economics. It’s a framework for analyzing how a firm can trade off capital and labor to produce goods. And I think it’s helpful for Software Developers in this new age of AI.
It can help us think about questions like these:
- What happens if the cost of LLMs drops dramatically?
- What happens if AI is a great replacement for Software Developers?
- What happens if AI is merely a tool for Software Developers?
Now, hold on to your hat. To fully understand the framework, we have to have the basics down. So, we have to take a detour into isoquant and isocost lines. I promise it won’t be too painful.
And in each section, we’ll see how we can apply it to our analysis of Software Developers and AI:
- Isoquant curves and Isocost Lines
- Perfect substitutes
- Perfect complements
- Are AI and Software Developers substitutes or complements?
Isoquant curves and Isocost Lines
Isoquant curves
Isoquants are the lines along which one input can be substituted for another while maintaining the same level of output.
And they’re typically drawn something like this:
That graph has two inputs (X and Y) and it shows 3 isoquants (Q1, Q2, Q3). The further up and to the right the isoquant, the higher the output (so, Q3 > Q2 > Q1). And the Marginal Rate of Technical Substitution (MRTS) is the slope at a given point on one of those curves.
At its core, MRTS compares 2 inputs to each other, and it tells you how much of one input you need to reduce to get one more unit of the other while keeping output constant.
That “while keeping output constant” is important.
In our analysis, we’ll consider the two inputs to be capital and labor – those are both very generic, but they also map somewhat neatly to LLMs/AI and Software Developers. And you can consider output to be anything the business owner is interested in – number of features, a stable, bug-free product, number of stories done, etc.
The isoquant curves tend to have a curvature like that (convex to the origin) because along the curve you have diminishing MRTS. That is, typically, you cannot simply go all capital and no labor (or vice versa) and still have the same output. You need both.
It’s helpful to think about it in the extremes to see how it works: if you have zero capital and all labor, adding one unit of capital might be very beneficial. And it would allow the business to reduce labor by a lot (while keeping output constant).
For just a second, let’s forget AIs and Software Devs. Think instead of 10 people digging a hole with spoons, and then you introduce a shovel. You might only need 2 people with 2 shovels to dig the same number of holes.
But at some point, the value of adding more capital doesn’t help your output. A single person with 3 shovels won’t dig any more holes. So the rate at which you trade-off labor for capital diminishes the further you go to the extremes.
It’s worth noting, all things being equal, a business owner would typically like to be in higher isoquant (to make more holes, produce more, and make more money). But given a fixed output, they can only move within a given isoquant. So, the business owner has to choose how much labor and capital to have.
But how do they choose?
For that, we want to look at cost.
Isocost Lines
We assume the business has a budget constraint. That is, we assume that they want to make more money, and if they produced more “output” (however we define that), they would make more of it.
But they have costs – and in our particular case, they have capital and labor costs.
So, we would have something like this:
C = C_labor * Q_labor + C_capital * Q_capital
Or in typical Economics notation:
C = rK + wL
That is cost is equal to the wage w, times the quantity of labor L, plus the
cost of renting capital r times the quantity of capital K.
An isocost line shows all combinations of capital and labor that cost the same C.
We can neatly graph an isocost line (notice the constant negative slope):
How to choose optimum capital-labor combination
So, as with much of modern economics, the question becomes one of optimization.
What’s the optimal use of capital and labor (to minimize cost) for a given level of output?
The solution to that is the point at which MRTS is equal to the slope of the isoquant line. In other words, the point at which the isoquant curve touches the isocost line in the graph above (at that point, the slopes are the same).
At that point, the business owner is keeping their cost C, and they have the best combination of capital and labor to get that level of output.
Capital (AI) and Labor (Software Developers)
So, how do we apply this to AI and Software Devs?
Well, remember this is just a model. So we’re making many simplifications and assumptions.
If we treat Software Developers in the pre LLM world as labor, and AI as a new capital (think of a new shovel), we have to realize that businesses are going to start making a trade-off between the amount of capital and labor they use.
In particular, they’ll likely grow the amount they spend on AI while decreasing the amount they spend on Software Developers (all other things being equal).
That doesn’t mean that software developers will get paid less (it might, but that’s not the implication here). It means that for a given software product (keeping output constant), a business owner will likely spend more of their “software” budget on AI and less on Software Developers than they were doing previously. And they will do so until we reach a new equilibrium point where the MRTS between labor and capital is equal to the slope of the isocost line.
I’ve actually seen that already happening in companies. Their budgets planned for 2026 include fewer developers than originally anticipated and larger AI budgets. So, they’re actively moving money previously allocated for new hires into paying for LLMs.
Now, there are more implications and further analysis we can do here. For example, we can use the model to understand what happens if the cost of LLMs drops radically.
But first, I think it’s helpful to think of the extremes in order to develop more intuition around the framework.
To that end, we’ll look at two scenarios:
- What happens if LLMs and Software Developers are perfect substitutes (the dreaded dark factory)
- What happens if they are perfect complements (they just make us devs more productive).
Perfect substitutes
Let’s first see a scenario where AI is a perfect substitute for Software Developers.
That’s the dreaded dark factory where developers are completely replaced by AI. You can imagine several versions of this, but one would be a completely automated system where a PM just writes stories and AI pulls them, implements them, reviews them, and ships them.
When that’s the case, an isoquant looks like this:
That isn’t an isocost line that we just drew. It is an isoquant “curve” (and recall they used to be curved).
That isoquant has a perfect 1-1 relationship between the two inputs (or the MRTS is constant). So, you can replace one developer with a fixed unit of AI “stuff” and you’ll still get the same output. (what exactly is a unit of AI, I don’t know.)
So, if that is an isoquant, where does it intersect the isocost line?
As you can see, the isocost line intersects the isoquant at all capital (K), no labor.
Why is that?
Remember that a business will always like to be on the highest isoquant (furthest up and to the right) possible (assuming making more stuff makes more money). So, they minimize cost subject to being on the highest isoquant possible.
We can see how much more they would have to spend to reach the same level of output if they spent it all on labor.
As you can see, the company would have to spend far more money to keep the same level of output if they wanted to spend it all on labor.
So, yes, in the perfect substitutes case, it’s a sad day for Software Developers. The businesses need to adapt to the changing cost landscape (they’re competing with other businesses doing the same), so they would ultimately fully replace labor.
Now, is that what’s happening with AI? I don’t know.
But let’s take a look at what happens if AI and Software Developers are perfect complements instead. It paints a very different picture.
Perfect complements
Let’s go back to isoquants. The shape of isoquants for perfect complements looks like this:
That is, the perfect complements isoquant curve has an L shape. That’s because a business always needs both labor and capital in the same proportions.
When we combine that with an isocost line (assume the business has fixed budget), we get the following:
In other words, given a fixed cost, the highest isoquant (output) a business can reach is at the bottom-left corner of the isoquant L-curve.
Or put the other way around, given a fixed level of output, the lowest isocost line (i.e. minimizing cost) that reaches such output is that corner.
So, in a world of perfect complements, the prices of labor and capital are somewhat irrelevant when allocating resources. The business is simply constrained by their budget and the need to have capital and labor in an exact ratio. They cannot trade-off more capital for less labor (or vice versa) because both are needed in exact proportions.
Maybe one more graph will make it super clear. Let’s say the business wants to produce more output. It cannot simply add more capital or more labor. It needs to add both! And since they’re perfect complements, they have to be added in the same proportions.
That looks something like this:
As you can see, in order to reach a higher level of output (isoquant 2), the business has to spend more money (isocost 2). And it does so in the same ratio of capital to labor.
AI and Software Developers
Let’s now jump back to AI and Software Developers.
If AI and Software Developers are perfect complements, AI is a tool (+ machines, compute, etc.) for Software Developers.
But you cannot simply “deploy” AI without Software Developers. So, companies that want to produce more (e.g. ship more software) will need to increase their budgets to hire more developers and pay for more AI for those developers.
They can’t wholesale replace one with the other.
A decent example of complements are Software Developers and laptops. When you hire a new developer, you probably need to buy them a new laptop. 10 developers with 2 laptops doesn’t help you a lot. And 2 developers with 10 laptops seems like a waste of money. You want roughly one laptop per developer.
Are AI and Software Developers substitutes or complements?
Now that we’ve seen how isoquant curves and isocost lines behave at the extremes (when capital and labor are perfect substitutes and perfect complements), we can ask the question: are AI and Software Developers closer to substitutes or complements?
My guess (but it’s just a guess) is that it’ll be somewhere in between the two. At first, they’ll be more like substitutes. But in the long-run, they’ll be more like complements.
I have other reasons for that belief (this mental model doesn’t tell us about that). But that’s still my guess.
So, I would probably model it like a “normal” isoquant curve (convex to the origin):
In that case, what is happening is that LLMs are a new type of technology that will shift the relative balance between capital and labor.
But that doesn’t mean that less developers will be needed.
In the short-run, that might be the case. Like I mentioned, I’ve seen some companies reallocate some of their hiring budget towards buying tokens for their existing team.
But it’s typical for people to think of the world as a fixed “pie”. So, when new technologies are introduced, they’re worried their share of the pie will be taken.
When, in fact, technologies tend to increase the pie. So, it’s possible more (not less) developers will be needed (and that can be a bit surprising). Perhaps the job will change (it is seemingly already changing), but developers would still be needed, and in higher quantities.
We can actually see that with isoquant curves and isocost lines by considering what happens as LLMs get cheaper (assuming they get cheaper).
As you can see in that graph, LLMs getting cheaper means that the isocost line changes. That allows the business to reach a higher isoquant but only by also increasing the quantity of labor.
You see that the lower cost allows the business to move from Kq1 to Kq2 and Lq1 to Lq2. In other words, the business will employ more developers and use more AI with the same cost!
Of course, by now you might have noticed that how much those quantities change (i.e. the relative values of Kq2-Kq1 and Lq2-Lq1) depends on the shape of the isoquant curve. Based on how I drew the isoquant curves in the graph, the increase in the quantity of AI used (change in Kq) is greater than the increase in the quantity of developers (change in Lq). Both increase, but capital increases more (which is intuitive since that’s what got cheaper).
But that’s where the model stops and real world begins.
Those isoquant curves are nice and smooth and convex to the origin. Real-world companies don’t have a perfect mathematical equation that they minimize to figure out where MRTS is equal to the slope of the isoquant curve.
Instead, businesses try different combinations, producing different levels of output, and adjusting as revenues and costs change. But, as a rule, businesses will adjust because they have incentives to do so. They want to stay around and (hopefully) be profitable. So, I think changes are inevitable.
I think there’s more analysis that we could do. But I imagine you’ve had enough of isoquant curves, isocost lines, and MRTS for now. Still, I hope it’s a helpful mental model you can use now and in the future.
I’d love to hear what you think about the current state of AI and Software Developers. What’s the reality you are seeing now and the future you think is coming? Shoot me an email.
And thanks for sticking around!