What Happens to Software Engineering When Generating Code Is Free? (Part 2)
Rupak Majumdar
In Part 1, Rupak introduced the question: what happens to software engineering when the cost of generating code goes to zero? In Part 2, he picks up that thread through the lens of economics — substitutes, complements, and what becomes valuable when code itself is plentiful. Along the way he draws in Margaret-Anne Storey's recent work on cognitive debt: the slow, often invisible divergence in a team's shared understanding of what they're building.
Transcript
Rupak: For a while now, I have been thinking about the future of software engineering practices. 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 development go?
One of the ways to think about it is through the lens of economics. In economics, there are different goods in the marketplace, and some of these goods are substitutes, and some of these goods are complements. Think of substitutes as Coke or Pepsi. And think of complementary goods as, well, gas and cars — or in the software context, commodity hardware and software.
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: we're developing software, and the price of generating the code goes down. The natural question is, where will the value go? In order to understand this, we have to figure out what are the complementary goods to software. If software is plentiful, where should the value be? It has to be something that's rare, that's differentiated, and that's a complement to the code.
If I take my research hat on, one of the things I would say is: correctness of software is such a complementary good. If the cost of software goes down, then you would prefer to get software — or the demand for software — that is also shown to be correct in a certain way would go up.
But of course, this is not the only complementary good. Very recently, Margaret-Anne Storey had a paper where she defined this notion of cognitive debt. 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 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 slowly diverges about their understanding of what they're building.
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 built 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 bring down our cognitive debt across the team, across the organization, would play a key role.
Drop us a note if you'd like a specific topic covered: feedback@sageox.ai.