What happens to Software Engineering when Generating Code is free? Part 2

0:01 So, for a while now, I have been thinking about uh the future of software engineering practices. And this is mainly prompted by the fact that with these coding agents, the cost of development is kind of going to zero. And one of the natural questions then is where does the value in software uh development go? And one of the ways to think about it is through the lens of economics. So, in economics, there are different goods in the marketplace, and some of these goods are substitutes, and some of these goods are complements. So, think of substitutes as Coke or Pepsi.

0:35 And think of complementary goods as, well, gas and cars, or in the software context, uh commodity hardware and software. So, when the price of a good goes up, you would expect that the demand for its substitutes would go up, because, well, Coke is more expensive, I'll switch to Pepsi. On the other hand, if the price of a good goes down, then you would expect that the demand for its complements would go up. So, now let's imagine. So, we're developing software, and the price of good in the generating the code goes down.

1:09 So, natural question is, where will the value go? And in order to understand this, you we have to kind of figure out what are the complementary goods to software. So, if software is plentiful, where should the value be? And it has to be something that's rare, that's differentiated, and that's a complement to the code. Now, if I take my research hat on, one of the things I would say is, well, correctness of software is such a complementary good. And if this cost of software uh goes down, then you would prefer to get software, or the demand for software that is also uh shown to be correct in a certain way would go up.

1:44 But, of course, this is not the only complementary good. So, very recently, uh Margaret Ann Story had a paper where she uh defined this notion of cognitive debt. So, in software, we say technical debt when we're not really doing the right implementations because we feel that we'll fix it sometime in the future. There's also the intent debt, where we do not really think through exactly what we want to build. And the third kind, cognitive debt, is where a team kind of slowly diverges about their understanding of what they're building.

2:14 And in some sense, cognitive debt is one of those things that is a complementary good to our code. Because in order to build a good product, a good piece of software, you want to ensure that the entire team is aligned to what should be building and how it should be built. So, I think that a very good research area in software engineering today is to understand what kind of tooling and what kind of software development processes we have to introduce in order to focus on the value that you get from the complementary goods to code. And I think tools that essentially uh bring down our uh cognitive debt across the team, across the organization, would play a