Patrick Collison 提出向个人应用内置 agent 改进入口的 liquid software 模式

Highly recommended read. I've been bullish on the idea of personal malleable software. Patrick cal...

Highly recommended read. I've been bullish on the idea of personal malleable software. Patrick calls this pattern “liquid software”. This is a new way to build software, especially personalized software. I have been building my own harness this way, but this also has implications in a world of recursive self-improvement (RSI). In simple terms, every request in the improvements flow could go to an agent, and the agent changes the application. In some sense, the user and the application can co-evolve as needs change. This is working for me. I use the same co-evolution pattern at @dair_ai to build our internal custom agent harness, which we have been developing for over a year. We implement, experiment with, and evaluate research ideas and our own ideas, so the harness keeps evolving. In my experience, this lets us build novel agent interfaces and functionality, and scale with agents much faster than more rigid harnesses allow. I agree that scaling and security are the main challenges. Maintainability and collaboration are the open questions once this pattern moves beyond personal tools. For builders, this means you can ship a foundation and let real usage shape the product. Small improvements could come directly from what users need. Experimentation also gets easier, because you can try new workflows and behaviors without a big release cycle. I believe some version of this will be important for RSI to deliver significant business value. That is why I have been pushing to build evals that measure economic outcomes in the real world. This idea also connects to Jack’s earlier “From Hierarchy to Intelligence” x.com/jack/status/20… , which describes rebuilding Block as a mini-AGI. Customers and people inside the company interact directly with the company's intelligence layer, and the software changes in response. As agents improve, you should start designing applications that have that adaptiveness built in. Today, this works well in personal software, but I expect organizations to slowly start adopting the idea to build production-grade software that serves real-world users. Patrick Collison @patrickc I'm now building an "improvements" feature into all of my personal vibecoded applications: a freeform text input that's hooked up to an agent that yolo implements whatever is submitted. It's an interesting experience -- the activation energy barrier to sanding any rough edge or implementing any new feature becomes extremely low. Someone else who uses one of the applications I created has already implemented 150 improvements over the course of a few days. This pattern feels like a new kind of tool -- liquid software? -- and every application that doesn't have this feature now has a slightly rigid and anachronistic flavor. Why can't I just tell it how I want it to be different? Now, it's not obvious to me how this pattern can or should scale. Does it become unmaintainable after a while? (Maybe model intelligence improvement outstrips my feature appetite such that it's fine?) How does collaborative software work in this model? Can software designed this way be secure and reliable? Whatever the larger questions about broader deployment, it definitely works great in a personal context. It reminds me a little of the visions of Lisp/Lisp machines, Smalltalk, and HyperCard -- systems that the user can take control of and modify. Those visions never quite worked, though: the vast majority of software today is not end-user modifiable in any useful way. So, while this "liquid" affordance is a very small touch, the way it changes one's relation to the software feels a bit transgressive and empowering in a Lickliderian and Engelbartian way. 🔗 View Quoted Tweet 💬 35 🔄 7 ❤️ 141 👀 17303 📊 59 ⚡