NOTE: The Growth Economics Blog has moved sites. Click here to find this post at the new site.
Let me start by saying that all future arguments about robots should use the word “droids” instead so that we can use more Star Wars references.
Benzell, Kotlikoff, LaGarda, and Sachs (BKLS) have a new NBER working paper out on robots (sorry, I don’t see an ungated version). They are attempting to do what needs to be done: provide a baseline model of economic growth that explicitly accounts for the ability of software in the form of robots to replace human workers. With such a baseline model we could then see under what conditions we get what they call “immiserating growth” where we are actually made worse off by inventing robots. Perhaps we could then use the model to test out different policies and see how to alleviate or prevent such immiserating growth.
Thus I am totally on board with the goals of the paper. But I don’t know that this particular model is the right way to think about how robots will affect us in the future. There are several reasons:
Wealth Distribution. The model has skilled workers and unskilled workers, yes, but does not distinguish between those with high initial wealth (capable of saving a lot in the form of robots) from those with little or none. This eliminates the possibility of having wealthy robot owners run the wage down so far that no human is employable anymore. While I don’t think that is going to happen, the model should allow for it so we can see under what conditions that might be right or wrong.
Modeling Code. The actual model of how capital (robots) and code work together seems too crude. Essentially, robots and code work together in a production function. Code today is equal to some fraction of the code from yesterday (the rest presumably becomes incompatible) plus whatever new code we hire skilled workers to write. The “shock” that BKLS study is a dramatic increase in the fraction of code that lasts from one period to the next. In their baseline, zero percent of the code lasts, meaning that to work with capital we have to continually reprogram them. Robotics, or AI, or whatever it is that they are intending to capture then shocks this percent up to 70%.
Is this how we should think about code? Perhaps it is a stock variable we could think about, sure. But is the coming of robots really a positive shock to the persistence of that code? I feel like I can tell an equally valid story about how robots and AI will mean that code becomes less persistent over time, and that we will continually be reprogramming them to suit our needs. Robots, by operating as general purpose machines, can easily be re-programmed every day with new tasks. A hammer, on the other hand, is “programmed” once into a heavy object useful for hitting things and then is stuck doing that forever. The code embedded in our current non-robot tools is very, very persistent because they are built for single tasks. Hammers don’t even have USB ports, for crying out loud.
Treating Code as a Rival Good. Leaving aside the issue of code’s persistence, their choice of production function for goods does not seem to make sense for how code operates. The production function depends on robots/capital (K) and code (A). Given their assumed parameters, the production function is
and code is treated like any other rival, exclusive factor of production. Their production function assumes that if I hold the amount of code constant, but increase the number of robots, then code-per-robot falls. Each new robot means existing ones will have less code to work with? That seems obviously wrong, doesn’t it? Every time Apple sells an iPhone I don’t have to sacrifice an app so that someone else can use it.
The beauty of code is precisely that it is non-rival and non-exclusive. If one robot uses code, all the other robots can use it too. This isn’t a problem with treating code as a “stock variable”. That’s fine. We can easily think of the stock of code depreciating (people get tired of apps, it isn’t compatible with new software) and accumulating (coders write new code). But to treat it like a rival, exclusive, physical input seems wrong.
You’re going to think this looks trivial, but the production function should look like the following
I ditched the exponent. So what? But this makes all the difference. This modified production function has increasing returns to scale. If I double both robots and the amount of code, output more than doubles. Why? Because the code can be shared across all robots equally, and they don’t degrade each other’s capabilities.
This is going to change a lot in their model, because now even if I have a long-run decline in the stock of robots , the increase in can more than make up for it. I can have fewer robots, but with all that code they are all super-capable of producing goods for us. The original BKLS model assumes that won’t happen because if one robot is using the code, another one cannot.
But I’m unlikely to have a long-run decline in robots (or code) because with IRS the marginal return to robots is rising with the number of robots, and the marginal return to code is rising with the amount of code. The incentives to build more robots and produce more code are rising. Even if code persists over time, adding new code will always be worth it because of the IRS. More robots and more code mean more goods produced in the long-run, not fewer as BKLS find.
Of course, this means we’ll have produced so many robots that they become sentient and enslave us to serve as human batteries. But that is a different kind of problem entirely.
Valuing Consumption. Leave aside all the issues with production and how to model code. Does their baseline simulation actually indicate immiseration? Their measure of “national income” isn’t defined clearly, so I’m not sure what to do with that number. But they do report the changes in consumption of goods and services. We can back out a measure of consumption per person from that. They index the initial values of service and good consumption to 100. Then, in the “immiserating growth” scenario, service consumption rises to 127, but good consumption falls to 72.
Is this good or bad? Well, to value both initial and long-run total consumption, we need to pick a relative price for the two goods. BKLS index the relative price of services to 100 in the initial period, and the relative price falls to 43 in the long-run.
But we don’t want the indexed price, we want the actual relative price. This matters a lot. If the relative price of services is 1 in the initial period, then initial real consumption is
In the long-run we need to use the same relative price so that we can compare real consumption over time. In the long-run, with a relative price of services of 1, real consumption is
Essentially identical, and my guess is that the difference is purely due to rounding error.
Note what this means. With a relative price of services of 1, real consumption is unchanged after the introduction of robots in their model. This is not immiserating growth.
But wait, who said that the relative price of services had to be 1? What if the initial price of services was 10? Then initial real consumption would be , and long-run real consumption would be , and real consumption has risen by 22% thanks to the robots!
Or, if you feel like being pessimistic, assume the initial relative price of services is 0.1. Then initial real consumption is , and long-run consumption is , a drop of 23%. Now we’ve got immiserating growth.
The point is that the conclusion depends entirely on the choice of the actual relative price of services. What is the actual relative price of services in their simulation? They don’t say anywhere that I can find, they only report the indexed value is 100 in the initial period. So I don’t know how to evaluate their simulation. I do know that their having service consumption rise by 27% and good consumption fall by 28% does not necessarily imply that we are worse off.
Their model is too disconnected from reality (as are most models, this isn’t a BKLS failing) that we cannot simply look at a series from the BLS on service prices to get the right answer here. But we do know that the relative price of services to goods rose a bunch from 1950 to 2010 (see here). From an arbitrary baseline of 1 in 1950, the price of services relative to manufacturing was about 4.33 in 2010. You can’t just plug in 4.33 to the above calculation, but it gives you a good idea of how expensive services are compared to manufacturing goods. On the basis of this, I would lean towards assuming that the relative price of services is bigger than 1, and probably significantly bigger, and that the effect of the BKLS robots is an increase in real consumption in the long-run.
Valuing Welfare. BKLS provide some compensating differential measurements for their immiserating scenario, which are negative. This implies that people would be willing to pay to avoid robots. They are worse off.
This valuation depends entirely on the weights in the utility function, and those weights seem wrong. The utility function they use is , or equal weights on the consumption of both services and goods. With their set-up, people in the BKLS model will spend exactly 50% of their income on services, and 50% on goods.
But that isn’t what expenditure data look like. In the US, services take up about 70-80% of expenditure, and goods only the remaining 20-30%. So the utility function should probably look like . And this changes the welfare impact of the arrival of robots.
Let and both equal 1 in the baseline, pre-robots. Then for BKLS baseline utility is 0, and in my alternative utility is also 0. So we start at the same value.
With robots, goods consumption falls to 0.72 and service consumption rises to 1.27. For BKLS this gives utility of . Welfare goes down with the robots. With my weights, utility is . Welfare goes up with the robots.
Which is right? It depends again on assumptions about how to value services versus goods. If you overweight goods versus services, then yes, the reduction of goods production in the BKLS scenario will make things look bad. But if you flip that around and overweight services, things look great. I’ll argue that overweighting services seems more plausible given the expenditure data, but I can’t know for sure. I am wary, though, of the BKLS conclusions because their assumptions are not inconsequential to their findings.
What Do We Know. If it seems like I’m picking on this paper, it is because the question they are trying to answer is so interesting and important, and I spent a lot of time going through their model. As I said above, we need some kind of baseline model of how future hyper-automated production influences the economy. BKLS should get a lot of credit for taking a swing at this. I disagree with some of the choices they made, but they are doing what needs to be done. I do think that you have to allow for IRS in production involving code, though. It just doesn’t make sense to me to do it any other way. And if you do that goods production is going to go up, not down, as they find.
The thing that keeps bugging me is that I have this suspicion that you can’t eliminate the measurement problem with real consumption or welfare entirely. This isn’t a failure of BKLS in particular, but probably an issue with any model of this kind. We don’t know the “true” utility function, so there is no way we’ll ever be able to say for sure whether robots will or will not raise welfare. In the end it will always rest on assumptions regarding utility weights.
Pingback: 10 Friday AM Reads | The Big Picture
Pingback: 02/20/15 - Friday AM Interest-ing Reads -Compound Interest Rocks
I was manager for the first successful plant-wide factory automation system at a car manufacturer in north America. That included roping in the robots. This was 1985, the era of articles on lights-out manufacturing plants. By 2000, Apple had one of the most advanced, state-of-the-art plants full of robots in the world. Why did Steve Jobs shutter that and ship all those jobs to Asia?
In a word, flexibility. Software has turned out to be the least malleable, longest lead-time item in manufacturing. The information theory reason is that what is going on in manufacturing is the exact opposite of what is going on in data processing. In DP, information is abstracted and condensed into symbols. In manufacturing, every nuance has to be added or the product isn’t right.
In the auto business, the average number of engineering changes to the car on the assembly line each day was 110 back then. It is higher now. The way we solved that issue was making the system a utility that could be easily configured by plant personnel. Software development could never, in a million years, meet those needs. Today’s software is not much better in terms of development time.
You might think that the marginally faster methods used in some software products today could be used. But in the plant I was automating, a man got cut in half by a large robot. So you have to make them essentially, extensions of people who run that section. They have to be able to make them do what they want quickly. And they can’t be wrong. If Uber software screws up, all that happens is someone doesn’t get a ride. Nobody is going to die. A windshield isn’t going to be slammed down off kilter and broken, the window gasket isn’t going to be damaged and require repair. Nor is a 20 ton crane going to run right through the wall of a warehouse. Molten slag isn’t going to splash onto someone. Pipes aren’t going to break a leg. But all those things and more have happened with manufacturing robots.
In manufacturing in general, product cycle times are compressed. There just isn’t time for software. That’s why iPhones are mostly made by hand. Yes, Virginia, the single most lucrative product in the world today, the symbol of modernity, is made by the oldest method we know because people are the most flexible. We aren’t hurtling toward a robotic future as advertised. Certainly not in the form that is implicit here in this article.
Great example of why I was skeptical of the paper’s way of modeling “software” and its persistence. A model that really captures how software works has to involve talking about the massive planning, coding, and testing (and testing and testing and testing and testing) phases. I think they are too crude in how software and labor interact, for sure.
For what it’s worth (and I’m seriously not sure), if we look at actual consumption patterns, and at both nominal and real expenditures, we get this:
Nominal Expenditures: Goods
Q1 1947: 61.2%
Q1 1999 36.0%
Q4 2014: 33.1%
(Obviously, the rest is services)
For real expenditures, the current series on FRED goes back only to 1999
Real Expenditures: Goods
Q1 1999: 32.1%
Q4 2014: 34.7%
(Again, the rest is services.)
If real goods spending as a % of total PCE was comparable to nominal spending in 1947, then there has already been a long-term trend away from goods consumption. Wouldn’t any consideration of the effect of robots on consumption have to take this into account?
(What I’m not sure how all this would play out in their model, I mean it; I have not worked through the math. And, frankly, I’m not going to.)
Right – I think that is something that they do not account for. As we’ve gotten richer, consumptions *goods* are far less important to economic activity than services. So the fact that robots an build microwaves faster or better or cheaper is great, but doesn’t mean mass unemployment. There are *already* very few people working producing goods. In their model, this would show up as a change in the weight you put on goods (push it down) versus services (push it up). Which would mean that the outcome of their model would be more likely to indicate a positive shock from robots to living standards, and not a negative one.
As a software guy, one of the things that has always impressed me about code is that it tends to have a very long life time. In fact, the software often outlasts the hardware it runs on by several generations. The general rule is that if it isn’t broken, don’t fix it. Through the 1960s and well into the 1970s, the primary use of the IBM 360, supposedly, was to emulate the IBM 1401, a computer no longer being manufactured. When I did some consulting for a major airline in the early 90s, I learned that their flight planning system was running on an emulator for a machine last manufactured in the early 1970s. Consider the sheer number of PCs still running XP.
The simple fact is that updating software is expensive and problematic. In the industry, the general rule for improving your ability to price software projects is to multiply your initial estimate by your age. There are immense risks involved as anyone booking a flight during an airline merger discovers, and that’s just a reconfiguration, not even a major change. Whenever someone complains about lousy government software, like the recent healthcare.gov roll out, one can counter with endless stories of private sector debacles.
Then, once the new software is released, there is the problem of workflow. I don’t think anthropologists have even recognized this as a growth area for their field. People come up with all sorts of short cuts, cheats, and efficiencies, and even fixing a bug can grind production to a halt. XKCD parodied this with the tale of a new system release that fixed a bug in which holding down the space key caused the CPU to overheat. An irate user complained that he was using a rapidly heating processor in lieu of the control key.
In other words, software development has to be extremely conservative. Everything that has ever worked has to keep working, even as new features are added. If you look inside the actual code delivered, you’ll find that it is even more conservative than that. Apple, a company noted for being willing to discomfit its users by forcing them to upgrade to the latest software release probably changes less than 10% of its software base when it does a major new system release. Darwin understood the principle when he described evolution as descent with modification.
I don’t think robots are an exception. Their software will change just as slowly. Old systems will be moved to new hardware. New robots will be required to be able to emulate old robots. Huge chunks of code will exist unchanged for decades, just as modern humans share genetic code and metabolic mechanisms with archaea. Of course, the Red Queen hypothesis will hold as it does for biologicals. There will always be new security threats, unpredictable interactions and latent bugs emerging, so there will be a choice between regular maintenance and increasing decrepitude. Forbidden Planet got that right, and quite possibly might have been right about the “monsters from our id” as well.
Before I was a world-famous growth economics blogger (ha!) I did software work, also at a major airline in the mid-1990s. Which meant I was decoding stuff written in the 1970s to try and mildly update it to work in the mid-1990s (fun with COBOL!). So I absolutely believe the “high-persistence” story for software. What I don’t buy is that software persistence only recently fundamentally shifted up because of the coming of the internet or robots or whatever. So the thought experiment in the paper I was talking about already occurred in the 60’s/70’s. Robots aren’t going to change that, as you say.