Malleable Software

Table of content

Personal computing promised clay. We got appliances.

The original vision was a material users could reshape at will. What shipped was sealed boxes built by distant corporations. You adapt to the software instead of the software adapting to you.

The Problem with Applications

The “app” model assumes passive consumption:

Software ships as finished products
Customization means choosing from preset options
When tools don’t fit, you submit feedback and hope
Each app is a silo with its own data format

Plugin systems don’t solve this. They only allow changes the developer anticipated and authorized. No plugin surface for your specific need? Out of luck.

Clay vs Appliance

From the Ink & Switch Malleable Software essay (June 2025):

“The original promise of personal computing was a new kind of clay — a malleable material that users could reshape at will. Instead, we got appliances: built far away, sealed, unchangeable.”

A guitar maker arranges their workshop with tools positioned just so. They build new tools as needed — a wooden block for support, pliers sanded into the right shape. Physical reality is malleable. Software should be too.

The Home Kitchen Metaphor

Malleable does not mean disposable.

From Geoffrey Litt’s interview:

“When I say malleable software, I do not mean only disposable software. The main thing I think about… is actually much closer to designing my interior space in my house. When I come home I don’t want everything to be rearranged. I want it to be the way it was. And if I want to move the furniture or put things on the wall, I want to have the right to do that.”

The goal is crafting an environment over time:

Disposable	Malleable
Generate and throw away	Build and refine
No continuity	Persistent customizations
Start fresh each time	Environment compounds
Tools don’t learn you	Tools fit your patterns

Chef Knife vs Avocado Slicer

General tools beat specialized gadgets.

An avocado slicer does one thing. A chef’s knife handles everything. Most kitchen gadgets end up in a drawer. The knife stays on the counter.

Software has the same pattern:

Specialized Tool	General Tool
Single-purpose app	Composable building blocks
Works for one workflow	Adapts to many
Obsolete when needs change	Evolves with you
Vendor lock-in	User control

AI Coding: Potential and Limits

LLMs give everyone the ability to author small bits of code. This matters for malleable software because:

Non-programmers can now make tools
Modifications happen at point of use
Customization doesn’t require engineering teams

But AI alone is insufficient:

AI-generated code still requires understanding to maintain
Disposable one-off tools don’t compound into personalized environments
The infrastructure for persistent customization doesn’t exist

The problem isn’t generating code. The problem is the architecture of our computing systems. Every layer — programming languages, operating systems, app stores — assumes users are passive recipients.

Using AI to Build Tools for Yourself

A promising pattern: don’t have AI write your code. Have AI build tools that help you code.

From Litt’s debugger experiment:

“What’s unusual here is: the AI didn’t write a single line of my code. Instead, I used AI to build a custom debugger UI… which made it more fun for me to do the coding myself.”

Working on a Prolog interpreter, Litt encountered tricky unification bugs. Instead of having AI fix them, he had it build a visualization tool. The debugging became enjoyable rather than frustrating.

This is the chef knife approach to AI:

AI builds general-purpose tools
You use those tools to do the real work
The tools persist and improve
Your environment becomes personalized

Local-First Principles

Malleable software needs a technical foundation. Local-first software provides it:

No spinners — Work is local, apps are fast
Your work is not hostage — Data lives on your devices
Network optional — Full functionality offline
Seamless collaboration — Real-time sync when online
Long-term preservation — Data outlives applications
Security and privacy — End-to-end encryption
User control — You own your data

Without local-first principles, malleable software remains dependent on corporations. Your customizations live on someone else’s server.

Key technologies:

Automerge — CRDT library for collaborative editing
Yjs — CRDT framework
Electric SQL — Local-first sync

Examples

Wildcard — Browser extension that lets you customize any web app using a spreadsheet. Augment sites with a synchronized data view. Sort, filter, compute formulas, pull in related data from APIs. No traditional programming required.

Potluck — Gradual enrichment from docs to apps. Start with plain text notes. Add live searches that extract structured information. Write formulas. Display results as dynamic annotations. Your document becomes personal software.

Both work the same way: start from something familiar (spreadsheets, documents) and let people add computation gradually.

What This Means for Personal OS

Building a personal operating system requires malleable software:

Your tools should fit you — Not the other way around
Customizations should compound — Not disappear when you restart
General tools over specialized — Build capabilities, not features
Own your data — Local-first by default
AI as tool-builder — Not just code-generator

A personal OS isn’t an app you download. It’s an environment you build, break, and rebuild over years.