Geoffrey Litt, Josh Horowitz, Peter van Hardenberg and Todd Matthews argue that personal computing promised clay and delivered appliances. When software does not fit, you file feedback and wait — you adapt to the tool instead of the tool adapting to you. Their name for the alternative is malleable software: an ecosystem where anyone can reshape their tools with minimal friction, in the moment, without asking permission.

Every existing escape hatch turns out to have a ceiling:

  • Settings only expose knobs a developer anticipated, and decay into long lists of disjoint checkboxes with no shared mental model
  • Plugin APIs authorize specific kinds of extension only, most apps have none because designing one is hard, and there is a wide chasm between installing a plugin and writing one
  • Modding is permissionless but tedious, breaks across upgrades, does not interoperate, and cannot reach server-side behaviour
  • Open source gives you the code without removing the friction — even a button-colour change means a dev environment and a codebase to learn
  • AI coding generates new siloed apps from a prompt, but does not help you tweak the app you already have: “bringing a talented sous chef to a food court”

The essay’s real contribution is three design patterns drawn from decades of prior art:

  • A gentle slope from user to creator. From MacLean et al’s 1990 tailoring work: each step up in customization power should cost only a small step up in skill. Spreadsheets are the exemplar — a full editor in place, a scrappy aesthetic that makes editing feel safe, formulas available when you want them. HyperCard did the same with explicit levels. Slopes get gentler either by lowering the skill needed at the top or by adding power at the bottom.
  • Tools, not apps. An app is an avocado slicer; a knife is a tool. Two sub-problems: sharing data (the filesystem, Smalltalk images where code travels with state, Airtable views over one database, Webstrates) and composing the UI itself (OpenDoc compound documents, entanglers, Dynamicland’s paper programs).
  • Communal creation. Individual customization only scales so far, and teams use computers together. Shirky’s “situated software” and Sloan’s “home-cooked app” point the same way: software for a known local community is easier to build, and only a few people in a group need the top-of-slope skills.

The second half is the lab’s own prototypes, including the dead ends. PushPin put React components over Automerge documents; Cambria translated between read and write schemas live so tools can disagree about data shape; Farm stored tool source code in the sync layer; Patchwork added branching and diffs to any document — and the essay itself was written in it. The section word counter they wanted mid-draft took minutes with AI assistance and synced in like any other document. Honest failures get equal space: hardcoded view contexts, an embedding model too isolated to share hover state, schema translation that wants deep integration with the data engine, a request tracker nobody used.

The AI section is the sharpest part for current purposes, and it is unexcited: code generation alone does not produce malleability, because the generated artifact is still a silo you cannot reach into, compose with your other tools, or tweak by hand for a small change. Pair it with a malleable environment, though, and it becomes the fastest way to edit your own tools. The essay is equally clear about what it has not solved — extension versus security, business models for tools rather than apps, and a culture where people actually want to reshape their software.

If you take one portable idea from it, take the slope: if you cannot describe how a user gets from using a thing to modifying it in small steps, you have a cliff.