Software Is Starting to Feel Like Liquid—One Sentence and It Can Change Itself

Patrick Collison says in the original post that he is adding an improvements feature to his personal vibe coding app. The interface is simple: a free-text input box backed by an agent. After submission, the agent directly changes the app according to the description. There are no requirements documents, no tickets, and no PR reviews.

He calls this experience an early form of “liquid software.” The startup cost of fixing any rough edge or adding any new feature becomes extremely low. Another person using his app has already submitted and implemented 150 improvements within a few days. According to him, any app without this feature now feels a bit rigid and a bit outdated. Why can’t you just tell it how you want it to be different?

The problems follow. How does this model scale? After changes accumulate, will it become impossible to maintain? When multiple people collaborate, whose needs take priority? Can software still be secure and reliable? Patrick doesn't have the answers. He confirms only one thing: in personal app scenarios, it works very well. This brings to mind traditions like Lisp machines, Smalltalk, and HyperCard that let users customize systems themselves. Most of those visions never truly became widespread, and most software today still cannot be effectively modified by end users. But this small “liquid” entry point does change the relationship between a person and their software, with a slight sense of overstepping and a slight sense of empowerment, in the direction of Licklider and Engelbart. Ali Diab's colleague was reminded of the PARC history in Dealers of Lightning.

There are already plenty of similar experiments in the replies. Andrew McCalip says he built one last week too; it worked better than expected, and the key was that there was no friction at all. Ideally it is a 15-second voice note, with no additional interaction before submission—just wait for it to become the result directly. David Noel Romas has tried giving each user their own fork and then absorbing some changes back upstream. It is technically feasible, but not necessarily optimal for ordinary users, and there are still many new practices to figure out.

Austin's first reaction was prompt injection: if users can change software with one sentence, can they also give themselves sudo permissions along the way? He also mentioned another dream: letting software change based on usage, such as popular buttons automatically floating up. Danny Postma proposed a more productized version: add voting to feedback like Canny, have the agent ask back “Is this what you want?”, triage requests weekly, and turn them into sprints for implementation—it could be called Community Driven Development. Kevin Sangster compared it to Kaizen for all software at all times.

Juan Sanchez applied similar capabilities to his home TV. Anyone can send a web game to the TV from the couch, create new games, remix, and edit. You can also describe a game by email, take a photo of a pet, a child's drawing, or a family member, and turn it into a game. After scanning a QR code, a phone becomes a fishing rod, a slingshot, a musical instrument, or even a custom controller.

Steve Clarke built a tool called Luh: point at the place you want to change, type one sentence, and it attaches a screenshot; you can draw annotations, and private data is blurred first. Notes go straight into the agent. In a shared app, other people's feedback gets triaged first. The project is still in development, isn't on npm yet, and the code is on GitHub.

Michal Takac's team turned similar functionality into an internal annotation tool. During brainstorming, they annotate directly on the product and prototypes; annotations are connected to a papercliping agent, and before the meeting ends the agent may already have started processing the first batch of annotations. This feature is currently open only to the internal team.

Back in 2024, Pliny the Liberator wrote “Code is liquid now.” At the time it may have been just a slogan; now it looks more like a description. Software is shifting from “finished at delivery” to “negotiable in use.” In personal tools this change feels like a toy; in team products it becomes a question of permissions, auditing, collaboration, and maintenance costs. Patrick's input box is small, but it asks a big question: if the barrier to modifying software approaches zero, who exactly should define software?