Notes: Max Schoening on Malleable Software, Agency, and Building Products in the AI Era

Four questions [Adler frame]

Q1 — What is this about? A design philosophy for AI-era products centred on three related claims: (1) software should serve users’ interests over corporate interests (malleable software); (2) with AI providing skill on demand, the scarce resource is now agency — knowing what you want and acting on it; (3) building great products requires identifying and perfecting the single interaction that is the product’s core superpower, not expanding surface area.

Q2 — How is it argued? Through concrete examples and analogies. The tiny-core claim is illustrated with a canonical set: GitHub PR, Heroku git push, Notion slash command, Figma live cursors, Dropbox menu bar icon. The agency claim is illustrated with the Notion “drive it like it’s stolen” provocation. The taste claim is illustrated with the virtual machine metaphor and the Bret Victor “Stop Drawing Dead Fish” reference. The argument is architectural and product-design oriented rather than data-driven.

Q3 — Is it true? The tiny-core observation is strongly supported by case studies in product history (each example given is verifiable). The agency claim is directionally right — as code generation becomes cheap, the limiting factor does shift to judgment about what to build — but the claim that agency “is not evenly distributed” is asserted rather than analysed; Schoening does not examine why or what could be done about it. The malleable software definition is aspirational and somewhat circular (software is good when it serves users) but the framing clarifies the design ambition.

Q4 — What of it? The design implication is clear: identify the one interaction in your product that is so unexpectedly good it could define the product’s identity — the “tiny core” — and invest in it disproportionately relative to surrounding features. The playground method (deliberately rough everything except the core) operationalises this. The taste-as-virtual-machine frame is useful for evaluating candidate ideas: would your target in-group find this excellent, or merely adequate?

Glossary

Malleable software — Software that adapts to the user’s intent rather than locking the user into the designer’s mental model. The contrast is between software as rigid tool and software as responsive medium.

Agency — The capacity to act decisively on a clear intent. Schoening’s claim is that AI provides skill on demand, so agency (knowing what you want) is now the differentiating human input.

Tiny core / superpower — The single interaction in a product that is so unexpectedly good it defines the product’s identity. The design priority is to make this interaction as exceptional as possible, not to expand the surrounding feature set.

Playground — Schoening’s prototyping method: deliberately keep everything in a prototype as rough as possible except the one interaction that matters most. This forces clarity about what the core actually is.

Taste as virtual machine — A metaphor for the predictive function of taste: given an idea, a person with calibrated taste can simulate how a specific in-group will respond to it. This is not universal aesthetic preference but domain-specific prediction.

LLM-friendly codebase — A codebase structured to be maximally interpretable and editable by a language model (clearly named variables, consistent patterns, minimal magic). Schoening treats this as a design constraint for the AI era, analogous to how mobile-first design was a constraint for the smartphone era.

Malleable software: the argument

Schoening’s definition: software that works closer to the interests of the people who use it than the interests of the corporation that made it.

The typical failure mode: software locked into the mental model of its designers. Users learn the tool’s vocabulary and adapt their intent to fit the interface. The tool does not adapt to the user.

The AI inflection: language models can interpret intent expressed in natural language without forcing the user to learn a fixed vocabulary. This removes one of the historically binding constraints on malleability. A user does not need to know that a feature is called “conditional formatting” to use it; they can say “highlight cells where sales dropped year-over-year.”

The implication: the design challenge shifts from “how do we surface the feature?” to “how do we understand what the user actually wants?” Understanding intent is now the hard problem; implementing intent is not.

Agency: the new scarce resource

Pre-AI: the bottleneck was skill — could you write the code, design the interface, run the analysis? AI makes skill broadly accessible.

Post-AI: the bottleneck is agency — do you know what you want and do you act decisively toward it? “Do you drive Notion like it’s stolen?” is not a Notion-specific question; it is a question about whether you exploit the full latitude of any tool or remain in a cautious narrow lane.

Schoening’s observation: agency is unevenly distributed. People with high agency produce most of the value in an AI-augmented environment; people with low agency produce roughly the same value as before, because they do not act on the capabilities the tool provides.

The design implication: products should be designed to expand user agency, not just expose features. The question is not “what can users do with this?” but “what do users want to do, and are we removing every obstacle between wanting and doing?”

The tiny core: five examples

Schoening’s canonical set of products whose identity is defined by a single interaction:

GitHub — the pull request. Not version control, not code hosting: the pull request as a unit of collaboration.
Heroku — git push heroku main. One command that deploys an application. The entire product philosophy crystallised in a single operation.
Notion — the slash command. Type / on any line to access any content type. The interaction that makes the tool feel malleable rather than fixed.
Figma — real-time collaborative cursors. Not the design tool: the moment you see a colleague’s cursor moving in your file. This defined Figma as a collaboration product rather than a design tool.
Dropbox — the menu bar icon. Not file sync: the persistent ambient indicator that your files are backed up and accessible everywhere. The whole trust proposition in a single icon.

The pattern: in each case the company could have invested in broader feature coverage. Instead, one interaction was made so good that it created the product’s identity.

Playground method

Schoening’s AI-era prototyping approach:

The setup: take the “worst possible playground” — a minimal codebase, deliberately kept rough. Keep it rough everywhere except the one interaction you are trying to validate.

The purpose: force clarity about what matters. If you polish everything equally, you never discover whether the core interaction is worth investing in. If you polish only the core and keep everything else minimal, you get a direct answer.

The structural benefit: LLM-friendly codebases (clear names, consistent patterns) are easier to modify, iterate on, and hand to an AI for the next step. The playground approach naturally produces an LLM-friendly codebase because minimalism and clarity are the same constraint.

Taste as virtual machine

Schoening’s metaphor: taste is a simulation capability. Given an idea, a person with calibrated taste can run a simulation: for this specific in-group, in this specific context, will this idea resonate?

This is not the same as saying “I like this.” Universal aesthetic preference is a very different faculty from calibrated domain prediction. The latter is learnable and trackable; the former is harder to train.

How to build it: deliberate exposure. Study world-class work in the domain. Attempt to replicate it. Examine the gap between your attempt and the original. The gap is the instruction.

The Bret Victor reference is important here. Victor’s “Stop Drawing Dead Fish” critique of animation software argues that tools should allow the creation of live, reactive, interactive things — not dead representations. The principle extends to any design domain: the best work is not a beautiful representation of a concept but a thing that does something. Taste, for Schoening, includes the ability to recognise that difference.

The first 10% is free

The claim: with AI-assisted development, the cost of building the first version of almost anything has collapsed to near zero. The implication is not just faster prototyping but a restructuring of what questions are worth asking.

Previously: “Can we build this?” was load-bearing. Validation was expensive. You front-loaded research and design because implementation was the costly step.

Now: “Can we build this?” is almost always yes. “What should we build?” is now the load-bearing question. The constraint has moved from implementation to judgment.

The skill whose value has increased: taste and strategy — knowing which of the many now-buildable things is worth building. This is directly related to Schoening’s account of taste-as-virtual-machine: the ability to simulate in-group response is now one of the primary bottlenecks in the product development process.