softerware (n.) — software that changes while you are using it.
The word comes from a short essay by Nadeesha Cabral, who noticed two things happening at once. People are reverse-engineering tools and rebuilding them to fit their own requirements. And products are wiring feedback boxes to agents that can modify the software in place, collapsing the old prompt → PR → CI → deploy loop into a single conversation.
Cabral's image for it: "We're no longer mass-producing aircraft and then flying them. We're building and changing the aircraft as we fly."
Good name. Real shift. But "softer" describes the interface, and the engineering underneath gets harder, not softer.
How the change happens
The reverse-engineering trend is not new. People have forked and patched software for as long as software has existed. What is new is the cost: rebuilding a tool to your requirements used to take weeks, and now it takes an afternoon plus a review. When the price of a bespoke tool drops by an order of magnitude, "use it as shipped" stops being the default.
The in-app agent is newer. Instead of filing a feature request into the void, you describe the change and the agent makes it. The product becomes a substrate you shape rather than a product you buy.
What gets harder
Reproducibility. If the software differs per user, "it's broken" becomes unreproducible. A bug report has to carry the state of the code, not just the steps to reproduce. Support turns into archaeology.
Trust. A program that rewrites itself at runtime is a security model change. Who reviews the diff? What is the audit trail? If the agent can change the software, the agent is inside the trusted computing base, and most organizations have no idea how to reason about that.
Ownership. Who maintains the bespoke fork when the session ends? The promise is that everyone gets exactly what they need. The bill is that everyone gets a codebase.
The wrong metaphor
Aircraft are regulated, redundant, and designed for failure. Most software is none of those things, and the reason we accepted the write → compile → test cycle was that it made failures cheap and local.
Softerware makes failures expensive and strange: in-session, user-specific, hard to reproduce. That does not mean it will not happen. It will, for the same reason spreadsheets happened — it moves power to the person with the problem.
The interesting question is not whether software gets softer. It is which software should. My answer: the kind whose failure is cheap. Personal tools, internal dashboards, scripts, small games. Not the systems holding money, health records, or other people's data.
A softer interface is a feature. A softer audit trail is a liability, and the two arrive together.
Source: Softerware — Nadeesha Cabral.