Software as Virtual Beings
Navigating the Evolution of Software & Software Engineering in the Age of AI.
The jobs of people working in tech are tough these days. Not only do we need to get things done, but we Tech professionals’ jobs are tough these days. Not only do we need to get things done, but we are also constantly asking ourselves, and being asked, whether we have gotten things done in the right way. New ideas, new tools come out every week. It is exciting, but it is also daunting to keep up with.
I have been searching for my north star as I navigate the influx of new buzzwords. There were concepts that I genuinely embraced at the beginning; however, as I practiced and experienced them in the real world, I realized they are pushing software and software engineering in the wrong direction. But they led me to reflect, what indeed is software, and what is our relationship with it? It turns out, seeking answers to these questions leads me closer to finding my north star.
Durable Software, Ephemeral Code
One such concept is “software as ephemeral objects”. The idea is that, since AI coding is getting so good and so cheap, we don’t need to learn and adapt to existing software anymore. Instead, we can (and we should) just create a workflow or a tool on demand that fits our preferences and the needs of the current task, and that will be much more efficient and enjoyable to work with.
I remember the excitement in the engineering teams when vibe coding started to produce “correct” web apps reliably. Ideas started to get demonstrated through prototypes instead of mocks. Human labels (for training/evaluating AI systems) that used to be collected through spreadsheets began to be collected through web apps that engineers vibe-coded.
But as I used these vibe coded tools and built some myself, I realized usability issues often turned out to undermine its usefulness. And the time that I spent improving the usability defeated the purpose of a one-off tool.
Just like writing a good article, writing a piece of useful software requires taste, effort and caring. Producing code is cheap; producing software is not.
I experienced engineering environments where software was treated as ephemeral objects. I saw messy code that no one else was involved in and thus took other people lots of pain to pick up. I saw slow, buggy and hard-to-use tools. I saw diversion of tools across teams, which created an invisible wall that blocked cross team collaboration. Such chaos is the consequence of using AI to single-mindedly push for individuals’ short-term speed, when AI could have been used to improve all dimensions of software engineering - speed, quality of outcome, and quality of engineering itself.
The reality is that most software is not, should not be one-time or for one-person usage. Our brain prefers consistency and predictability to minimize energy consumption and reduce the risk of exhaustion. We are born social animals and we need the common context to connect, to collaborate. Instead of using AI to overwhelm ourselves with ephemeral software, we should use it to create more durable software that utilizes ephemeral code. The durable software provides the consistent, intuitive experience and common language for humans, while the ephemeral code behind the scene allows it to deal with the versatility of real world scenarios, which traditional software was unable to.
Spec Is Not the Code
“Spec as the new code” is another plausible sounding, and yet flawed concept. The idea is that, while humans won’t have time to understand the full AI generated codebase, what we really care about is whether the generated code follows our specified intent - the spec - or not. In fact, no matter how well the piece of code is written, it is a lossy projection of user intent, and that user intent is best captured by the spec. The reason that we had to save the code was because the translation from spec to code was expensive; now that the translation is so cheap, we should treat specs as the source of truth and code as the ephemeral output of the spec.
The idea of “spec as new code” makes two mistakes.
First, there is a big gap between our intent and reality. A spec risks either being too vague to be implementable in reality, or too specific not to contradict reality. The reason most software works the way it does is not because of well written specs, but because of iterations - testing, checking metrics and getting user feedback. Those learnings get reflected in the code, and are subject to change based on reality - not just the change of intent.
Second, a piece of software doesn’t exist in isolation. It interacts with external users like humans and other software. An unspecified implementation detail - the location of a button, the format of logs, the latency profile, the libraries and RPCs that it depends on, etc - might be arbitrary, but once the software is deployed, external users begin to depend on these unspecified behaviors, and a change of these unspecified behaviors will break the social contract with them.
If the problem with “software as ephemeral objects” is that it is too “tactical” that it creates chaos, then the problem with “spec as the new code” is that it is too “strategic” that it detaches from reality.
Software As Virtual Beings
The two concepts above also share a fundamental flaw. By treating software as implementation or reflection of ideas, they don’t give software the respect they deserve.
We might want to think of software as virtual beings and ideas or spec as their DNA. Ideas set the foundation for the software, but as they are born, they are shaped by the interaction of the DNA and its environment, which give them their body - the code, the configuration, and the model weights.
Just like physical beings, they consume energy (human energy is a big factor) to create, to maintain and to interact with. They evolve and die and they have their lineage. They have evolved to form a complex ecosystem to facilitate effective flow of information among the physical world and human beings.
Physical beings are powered by the massive scale of nature and have evolved over a long period of time. Virtual beings are powered by the tiny scale of human infrastructure and have just evolved for a few decades. They need our insights and oversights for effective evolution to fulfill their mission. People in the software industry — software engineers, product managers, UX designers, etc — sit in a unique position to guide the evolution. No matter what concepts there are, we need to ask ourselves, are they helping the evolution of these virtual beings to facilitate more effective flow of information, or are they hindering it?
If we ask this question, we will get closer to knowing what is just a hype, and what is going to sustain.are also constantly asking ourselves, or being asked, whether we have gotten things done in the right way. New ideas, new tools come out every week. It is exciting, but it is also daunting to keep up with.
I have been searching for my north star as I navigate in this ocean of new buzzwords. There were concepts that I genuinely embraced at the beginning; however, as I practiced and experienced them in the real world, I realized they are pushing software and software engineering in the wrong direction. But they led me to reflect, what indeed is software, and what is our relationship with them? It turns out, seeking answers to these questions leads me closer to finding my north star.
Durable Software, Ephemeral Code
One such concept is “software as ephemeral objects”. The idea is that, since AI coding is getting so good and so cheap, we don’t need to learn and adapt to existing software anymore. Instead, we can (and we should) just create a workflow or a tool on demand that fits our preferences and the needs of the current task, and that will be much more efficient and enjoyable to work with.
I remember the excitement in the engineering teams when vibe coding started to produce “correct” web apps reliably. Ideas started to get demonstrated through prototypes instead of mocks. Human labels (for training/evaluating AI systems) that used to be collected through spreadsheets began to be collected through web apps that engineers vibe-coded.
But as I used these vibe coded tools and built some myself, I realized usability often turned out to be a big problem that hindered its usefulness. And the time that I spent improving the usability defeated the purpose of a one-off tool.
Just like writing a good article, writing a piece of useful software requires taste, effort and caring. Producing code is cheap; producing software is not.
I experienced engineering environments where software was treated as ephemeral objects. I saw messy code that no one else was involved in and thus took other people lots of pain to pick up. I saw slow, buggy and hard-to-use tools. I saw diversion of tools across teams, which created an invisible wall that blocked cross team collaboration. Such chaos is the consequence of using AI to single-mindedly push for individuals’ short-term speed, when AI could have been used to improve all dimensions of software engineering - speed, quality of outcome, and quality of engineering itself.
The reality is that, most software is not, should not be one-time or for one-person usage. Our brain prefers consistency and predictability to minimize energy consumption and reduce the risk of exhaustion. We are born social animals and we need the common context to connect, to collaborate. Instead of using AI to overwhelm ourselves with ephemeral software, we should use it to create more durable software that utilizes ephemeral code. The durable software provides the consistent, intuitive experience and common language for humans, while the ephemeral code behind the scene allows it to deal with the versatility of real world scenarios, which traditional software was unable to.
Spec Is Not the Code
“Spec as the new code” is another plausible sounding, and yet fraudulent concept. The idea is that, while humans won’t have time to understand the full AI generated codebase, what we really care about is whether the generated code follows our specified intent - the spec - or not. In fact, no matter how well the piece of code is written, it is a lossy projection of user intent, and that user intent is best captured by the spec. The reason that we had to save the code was because the translation from spec to code was expensive; now that the translation is so cheap, we should treat specs as the source of truth and code as the ephemeral output of the spec.
The idea of “spec as new code” makes two mistakes.
First, there is a big gap between our intent and reality. A spec risks either being too vague to be implementable in reality, or too specific that it contradicts reality. The reason most software works the way it does is not because of well written specs, but because of iterations - testing, checking metrics and getting user feedback. Those learnings get reflected in the code, and are subject to change based on reality - not just the change of intent.
Second, a piece of software doesn’t exist in isolation. It interacts with external users like humans and other software. An unspecified implementation detail - the location of a button, the format of logs, the latency profile, the libraries and RPCs that it depends on, etc - might be arbitrary, but once the software is deployed, external users begin to depend on these unspecified behavior, and a change of these unspecified behavior will break the social contract with them.
If the problem with “software as ephemeral objects” is that it is too “tactical” that it creates chaos, then the problem with “spec as the new code” is that it is too “strategic” that it detaches from reality.
Software Are Virtual Beings
The two concepts above also share a common problem. By treating software as implementation or reflection of ideas, they don’t give software the respect they deserve.
We might want to think of software as virtual beings and ideas or spec as their DNA. Ideas set the foundation for the software, but as they are born, they are shaped by the interaction of the DNA and its environment, which give them their body - the code, the configuration, and the model weights.
Just like physical beings, they consume energy (human energy is a big factor) to create, to maintain and to interact with. They evolve and die and they have their lineage. They have evolved to form a complex ecosystem to facilitate effective flow of information among the physical world and human beings.
Physical beings are powered by the massive scale of nature and have evolved over a long period of time. Virtual beings are powered by the tiny scale of human infrastructure and have just evolved for just a few decades. They need our insights and oversights for effective evolution to fulfill their mission. People in the software industry - software engineers, product managers, UX designers, etc - sit in a unique position to guide the evolution. No matter what concepts there are, we need to ask ourselves, are they helping the evolution of these virtual beings to facilitate more effective flow of information, or are they hindering it?
If we ask this question, we will get closer to know what is just a hype, and what is going to sustain.