Software Needs a Home#
You may have hear the term “Vibe Coding”. It just means writing software with AI assistants. You can ask most assistants to write code for you presently and they’ll do a fair job of it. There’s some serious work to be done, still, in getting them to write good software, but, really it’s already good enough form many types of software.
What everyone is trying to figure out is what to do with it once you write it–how to “plug it in” if you will.
It makes sense to me that people are confused by this. Almost noone has experience in delivering software. Most people just don’t have the mental model anymore to understand what is going on or what it takes.
Pre-internet, people used to give each other “floppy disks” with programs on it. The kids in my neighborhood were early-adopters of Commodore 64 computers and had a little open market of software that was traded like this. You could load software into your computer from a disk, then swap in a new disk and write the software back out. Software was tiny back in those days, so you could write a handful of programs to a single disk so kids had fun curating the set of programs and labeling the disks like little “mix tapes”.
We knew how to write programs and how to make them available to other people.
When we started connecting our computers with modems and phone lines, we used intermediate computers running Bulletin Board System (BBS) software to, essentially, post software on the board instead of a disk, so other people could pick it up (download it). Usually, people knew the other people on the BBS in real life (long-distance phone calls were expensive), or at least through “vouching” for new users. We trusted each other and didn’t require a central party to make sure the software we were sharing was safe.
Something happened with the Web and smart phones, though. People started “browsing” to their apps. They started installing apps from an app store. In both cases, they lost the sense of a “program” or “copying” or “installing” for the most part. People started losing track of where an app was running or what an app even was. Increasingly, apps ran on other people’s machines (data centers). The software on your PC or phone increasingly just became a “front end” that provided a small/thin user interface while pushing all your data to the real software functionality on the “back end”. This, ironically, was reversing the dream of PCs back to the era of massive centralized time-shared computers with webs of connected thin-clients–not because our computers weren’t powerful enough to run software, but because by now, companies had realized centralization was lucrative.
All of that to say, people don’t really know what it means to have software that is running on their own PC or in their own cloud or copied and shared with their own friends anymore.
Perhaps it was this push to re-centralize software that was the reason why around the first decade of the 2000s, I started noticing something on the software development teams I worked on–people began differentiating themselves into “front end” and “back end” engineers. And then a few years later, people started differentiating themselves as “OPS”, short for “operators”. Roughly speaking, the front-end people made the thin-client user interfaces, the back-end people made the actual “business” services (where most the software was), and the OPS people made sure it was up and running for all the users in the data center. So today, it’s not uncommon to find software engineers who have been coding their entire careers and don’t know the first thing about software distribution or keeping software running. In that way, they don’t know as much as the 10 year old kids on my block growing up with their Commodore 64s.
The Home for Software#
Now, everyone with an AI assistant is a coder. Where should all this code live? A non-engineer vibe coder has a few serious problems:
- They don’t know how to run their program when they need it. If their program is a tool meant to be run when needed, they need to remember how to find the program and execute it. If their software is supposed to be running all the time (a service) they need to remember how to start it up and make sure it keeps running, even after they reboot their computer. If they want their program to be run on a schedule, how does that work? (I’ll tell you later in this article)
- They don’t know how to let other people use their software. The simplest thing to do, of course, would be to zip up all the program files and send them to a friend via email or messaging. But then they need to explain to them how to unzip it, install it, and use it–and hope they have the same PC architecture and dependent programs (like Python) installed to be able to do so. The second simplest thing, and yes, this is the second simplest, is to learn to use Github and upload your software there for other people to download. The simplest thing for their friend, though, would be to just be given a URL they could type into a browser to just see what they made, but, how does that work?? (I’ll tell you later in this article)
- They don’t know how to keep it all organized. Writing one program is fun. Writing a few gets complicated–which assistant did I use again? Which folder was that in? If you start writing programs that use other programs you’ve written, well, things just become a little silly. And really, with AI assistants, we’d probably be better off writing software for the assistants than just writing it for us–they can run our software making them more capable and productive–but how does that work?? (I’ll tell you later in this article)
- Their software starts being a bit… Frankensteined. You might have noticed that the user interface that was created by one AI assistant is entirely different than the interface written by another. This is happening under the hood, too. And it’s happening with your dependencies causing a rat’s nest of conflicting versions and approaches.
So, what we need is:
- We need a way for the tools we write to be available when we need them.
- We need a way for the jobs we write to be executed when we want them, even on a schedule.
- We need a way for the services we write to stay up and running, even across reboots.
- We need a way to expose our services to the Internet on a domain and URI we can use (private) and optionally share with our friends (public).
- We need a way to see all the programs we have written and how they connect with one another.
- We need a way for AI assistants to know about and use our programs.
- We need some way to ensure the things we are writing are all compatible with one another and all following the patterns we set.
Wild PC#
… to be continued