Malleable Software: When Code Becomes Clay and LLMs Are the Sculptors

The concept of malleable software represents a fundamental shift in how we think about the relationship between users and their tools. Rather than accepting software as a fixed set of features determined by developers, malleable software treats applications as platforms that can be reshaped, extended, and customized to fit individual workflows and preferences. This isn't about adding plugins or tweaking settings—it's about fundamentally altering the behavior and capabilities of software through code.

The catalyst for this reflection came from observing how tools like Pi and OpenClaw embody malleability, but the real epiphany arrived through a much simpler example: i3blocks. This unassuming status bar utility for the i3 window manager demonstrates the power of malleable software by accepting any script that outputs to stdout. Whether written in bash, node.js, or any other language, these scripts become first-class citizens of the user interface. The implications are profound: instead of searching for the perfect pre-built tool, users can create exactly what they need.

This shift becomes even more significant when viewed through the lens of large language models. What was once a laborious process of writing, debugging, and maintaining custom scripts has become almost trivial. The phrase "I can just do it myself" transforms from a daunting prospect to an accessible reality. LLMs have effectively made code disposable—cheap to generate, easy to modify, and acceptable to abandon if it no longer serves its purpose. This changes the entire economics of software customization.

The current landscape reveals an interesting tension: while generating working code has become remarkably inexpensive, the runtime environment remains a significant barrier. Anyone can prompt an LLM to create an iOS app, a web application, or a browser extension, but actually running that code introduces friction. This disconnect between code generation and execution represents the next frontier for malleable software. The solution isn't simply to provide more settings or configuration options—it's to ship complete runtimes and SDKs that make execution as frictionless as generation.

Consider the practical applications that become possible with truly malleable software. A Mac application that can build any desired app and expose it from the menu bar would eliminate the need for countless single-purpose utilities. Would anyone pay for another pomodoro timer when they could generate exactly the one they want? The question isn't whether users would pay for specific tools, but whether they would pay for the platform that enables them to create those tools themselves.

The author's i3blocks setup provides concrete examples of this philosophy in action. Scripts that toggle CPU power states between performance and power-saver modes, display battery status with custom formatting including percentage, time remaining, and power drain in watts—these aren't features you find in standard operating systems. They're bespoke solutions crafted for individual needs. A screen recorder built from ffmpeg and slop, one-shotted by Claude, demonstrates how complex functionality can emerge from simple components when the platform allows for composition.

Perhaps most interestingly, the author created a time-tracking system that monitors work hours with multiple dimensions: a counter that tracks up to 40 hours per week, a countdown timer that counts down from 8 hours per day, and integration with timewarrior to display active tasks and send notifications when work patterns deviate from expectations. This is software that exists nowhere else in the world except on this user's machine, yet it was created without extensive programming knowledge or significant time investment.

The abandonment of the timewarrior notification system after 20 minutes of generation time reveals another crucial aspect of malleable software: impermanence is acceptable. In a world where code is cheap, the cost-benefit analysis changes. If a script takes 20 minutes to create and serves its purpose for a while before becoming obsolete, that's a win. The sunk cost fallacy that makes us cling to imperfect tools disappears when we can easily create alternatives.

This philosophy extends beyond individual utilities to the very architecture of software. Traditional applications ship with a fixed mental model—the developer's understanding of how the tool should work. Malleable software challenges this by shipping not just the application, but the means to reshape it. An SDK, a runtime, an API that treats user modifications as first-class citizens rather than hacks or workarounds.

The implications ripple outward. Software companies might shift from selling features to selling platforms. The competitive advantage moves from having the best pre-built functionality to having the most accessible and powerful customization capabilities. Users evolve from consumers to co-creators. The line between developer and user blurs as the tools for modification become more accessible.

Yet challenges remain. Security concerns arise when users can execute arbitrary code. Performance considerations emerge when custom scripts interact with core system functionality. The learning curve, while reduced by LLMs, still exists. But these are engineering problems, not fundamental barriers. They can be addressed through thoughtful design, sandboxing, and progressive disclosure of complexity.

The future of malleable software likely involves a spectrum rather than a binary choice. Some users will want complete control and embrace the ability to modify everything. Others will prefer curated experiences with limited customization. The key is making the full power available to those who want it while maintaining accessibility for those who don't.

As we move forward, the question isn't whether software will become more malleable, but how quickly and completely this transformation will occur. The tools are already here: LLMs that can generate code, platforms that can accept it, and users who are ready to shape their digital environments. What's needed now is a philosophical shift in how we think about software—not as finished products but as starting points, not as constraints but as clay waiting to be sculpted into tools that fit our hands perfectly.

The i3blocks example shows us that this future is already possible, at least in certain domains. The challenge is extending this philosophy across the entire software landscape, creating a world where the answer to "Can this software do X?" is rarely "no" but instead "let me show you how." In that world, software becomes truly personal—not just configured to our preferences, but fundamentally shaped by our needs, our workflows, and our imaginations.