What Happens to Software Engineering When Generating Code Is Free? (Part 1)
Rupak Majumdar
Dr. Rupak Majumdar — Scientific Director at the Max Planck Institute for Software Systems and a SageOx Advisor — reflects on how software engineering is evolving. In this short piece, he explores new research directions opened up by the collapsing cost of code generation: the value of proof, trust signals and transparency, and what it means for the future of software development. These are preliminary thoughts as we work our way toward a better understanding.
Transcript
Rupak: Hi. So I'm Rupak Majumdar. I'm a Scientific Director at the Max Planck Institute for Software Systems, and my research topic is something called automated reasoning, or formal methods. The core idea of formal methods is to make sure that software does what it's supposed to do.
Now in the last six months, I have gotten intrigued by a very new development in the world of software. And that is: some of our basic assumptions about the cost of developing software have changed dramatically. In some sense, today the cost of developing software has gone to almost zero, given all these coding agents that we have. And what I have been thinking about in my research now is what this means for the future of software development. Many of the processes that we have around software engineering practice are based on the assumption that generating software is expensive. So what I'm thinking about these days is: what happens to software development when the cost of software generation goes to zero? Where does the value flow in the overall system?
Of course, if software becomes free, there's going to be a lot of it — and in some sense, a complementary good to software will be some kind of signal that this software is something you should be using. This ties into the research in formal methods that I have been working on, which is proof. If your software came with a proof — a mathematical proof of certainty that it will not do something bad — then that's a fairly good signal that you can trust this software, and you can use it.
And recent work in formal methods also seems to suggest that the cost of proof, along with the cost of generation of software, may very likely go to zero as well. This is an astounding statement for me, because throughout the history of software verification research we have struggled with the lack of scalability of formal verification tools. And now suddenly, with these agents, code generation becomes almost free — and there's some initial evidence emerging that shows the cost of proof also becomes free.
So does that mean we now have verified software and everything is good? Well, not quite. Because when we talk about verified software, we have the software as an artifact, but we also have a mathematical statement — a precise formulation of what it means for the software to be correct. And you can do proof when you have both: the software, and a precise statement of what it means for that software to be correct. This works in a bunch of applications. For example, if I'm developing a storage system, I may want to say, "prove to me that this storage system does not lose my data" — maybe under some assumptions about the environment. But when I'm developing something else — when I'm developing a system that tries to capture intent when teams of developers are working together — I really do not know of a way I can mathematically, precisely state what the specification, what the intent of this software, is.
This just means that proof is one of many signals we can give to show that software is of high quality. There may be other signals that are equally important when we do not have the ability to say precisely, mathematically, what it means for a piece of software to be correct.
This is where there are alternate ways — for example, transparency, or provenance. Imagine that you see a piece of software, and along with the software you also see a transcript of how exactly the software was developed. What was going through the minds of the developers as they were developing the software? For each piece of code, what is the origin of the decision? Now software comes with a transcript of its provenance.
So for each part of the software, you get to see how these decisions were made in order to develop the software. This is not proof in a mathematical sense, but it is also something that gives you a signal of trust in the software — you know exactly why certain decisions were made and how the decisions were embodied into code. So this is actually a very exciting time for software development research, and I think just understanding the various mechanisms that signal trust in new agent-driven software systems will be one of the core directions in software engineering research.
Drop us a note if you'd like a specific topic covered: feedback@sageox.ai.