I've noticed an interesting pattern start to emerge as I've made my way deeper into the claude fever dream rabbit hole. There's a certain fluidity in my more deranged projects between "hard" software and "soft" software. In this case, "hard" software means scripts, programs, what we often think of as "software" - deterministic (or not, but usually) execution of code. And "soft" software makes up the parts of the codebase being executed by agents directly.
Both forms achieve similar outcomes. "Soft" software is doing the same thing as "hard" software. I can tell an agent to execute a series of actions and it'll do it with increasing accuracy. It won't do it particularly quickly, and sometimes it'll do it wrong, but most of the time it'll just do it. Because the terms "hard" and "soft" applied to software get confusing and redundant, I've started to just call this latter category "promptware".
Promptware, concretely, is the parts of my projects that could be software but are instead written as prompts+agents. I would probably distinguish promptware from more complex LLM applications where traditional software simply doesn't function. For example, I don't think I'd use the word to refer to the parts of my codebase calling out to LLMs for intelligent analysis of something or another.
Why write promptware then? Lots of reasons!
Flexibility is probably the biggest of these reasons. Promptware is far more flexible than traditional software, it's easy to write, and it's self-healing! An agent that runs into an issue executing a prompt will simply work around it. Complex APIs? No problem, it'll just... figure it out. Software hits errors that need to be handled by more software. It's very hard to write promptware that doesn't work, but you pay for this flexibility in efficiency.
That said, agents do tend to stumble on the most efficient ways of doing things after enough runs. They don't know that they've done this because they have the memory of a goldfish, but combined with separate agents that analyze agent transcripts after the fact, you can actually create a very nice feedback loop that optimizes the promptware over time.
This leads into my earlier comment about the "fluidity" between software and promptware. I write promptware because I want to see things working, quickly. I want to test out complex flows. I just want to see it all work together, to get the big picture, and then I start solidifying promptware into software.
Most of the time, when I talk about this, people ask me why I'm not just writing software directly. What's the point of promptware when software is cheap? I'd argue that for the cases where I'm using promptware, software is premature optimization. When I'm writing promptware, I often don't know exactly what it is that I want the whole thing to be, or care to figure out all the dependencies required to make it actually work. Yes, Claude can write a bunch of software, but that software needs tests and it needs to handle errors and it might run into network issues and...
There are plenty of things for which this doesn't work at all. I'm not going to be processing thousands of events in real time with promptware. Fine! Who cares. The robot can make dozens of SQL queries that change all the time when my data changes. Once my data stops changing, I write the software. Or the robot writes the software. Either way, I am happy.