Designing the Slope: The Default Is Still the Product

A short video I watched this week makes a wish I recognize. Its speaker, who isn't named, says the future of interfaces is software you can modify yourself. They point to two coding tools released this summer: an AI agent harness where "everything" is "set up as a plugin," and a development environment that bills itself as "the IDE that builds itself." The more they use software, they say, the more they want to customize it, and they know they could do it faster than the team that serves it to them. So they want organizations to serve software "in a container" with an interface they can change by command, from inside the application, built on "primitives for what I can actually do," without rebuilding the whole thing. Then they add a sentence that does more work than anything before it: "I however probably am not the default user."

That last sentence is the subject of this essay. The speaker is right about themself, and the research on who modifies software is unusually consistent on why. What follows from it is a design question more than a technical one. If AI makes it cheap for anyone to ask for their own interface, most people will still live in the interface someone designed for them, a few will change things for everyone else, and the changes that matter most will be the small ones built into the system. The designer's work moves off the screen and onto what I'll call the slope: the default, the building blocks, and the climb between them.

I have a stake in this from both sides. As a designer, I make the defaults that other people live in. As a user, I am the speaker: over the past year I have built several small tools for myself with AI help, and I would happily reshape every app I use if I could. Both positions turn out to point to the same conclusion.

1. What the video gets right

Both products are real, and both say what the video says they say. The garbled "deep sea AI harness" in the captions is DeepSeek Harness, an open-source agent harness released as a developer preview in August 2026. Its tagline is "Everything is a Plugin," and its architecture document says "there is no privileged core to patch": the model adapter, the tool registry and the agent loop are all plugins you can swap (DeepSeek Harness). In early November DeepSeek added a Creator Mode in which users build new tools and interfaces by chatting, including a reskin of the Harness interface itself. The second product is bb, whose homepage headline is literally "The IDE that builds itself": you ask for a feature, it adds the feature, and it writes instructions that teach your AI agents to use it (bb). On Hacker News, commenters argued over whether a chat-centered app counts as an IDE, and two Emacs users noted they have had a self-modifying editor for decades.

That reaction is fair, and so is the speaker's description. For developers, changing your tools by prompt is now ordinary. Anthropic added plugins to its Claude Code agent in October 2025 and reusable "skills" a week later (Anthropic); bb and DeepSeek Harness go one step further and have the agent write the plugin for you.

The speaker's observation that heavier use breeds more customization is also backed by research. In a 1996 study, Stanley Page and colleagues watched 101 WordPerfect users on their own machines for 28 days, without telling them the study was about customization. The only significant predictor of how much people customized was how much they used the software. Experience, job, age and education made no difference (Page et al. 1996).

The claim that does not hold is "I can do it faster than the team who is actually serving me the software." The best controlled evidence is mixed at best. In METR's 2025 randomized trial, 16 experienced open-source developers took 19% longer on real tasks when allowed to use AI tools, while believing afterward that they had been 20% faster (METR 2025). A 2026 follow-up with 57 developers points toward a speedup, with confidence intervals that include zero, and METR calls it "very weak evidence" (METR 2026). When researchers gave AI systems 23 real change requests from social scientists for a 20,000-line web app, the best systems interpreted the requests "semi-correctly," carried them out partially and changed unrelated code (Yang et al. 2025); that test used 2024 models, and current ones would likely do better. The comparison also hides a difference in kind. A vendor's change has to work for everyone, be tested, be accessible, be supported and survive the next update. A personal tweak is faster mostly because it is a smaller job.

2. A fifty-year-old wish

What the video presents as a new desire is one of the oldest arguments in interface design, and nearly every part of it has a date.

In 1977, Alan Kay and Adele Goldberg described the computer they were building at Xerox PARC as a "metamedium" that "any owner could mold and channel its power to his own needs." Trying to anticipate every user's needs in advance, they wrote, "would end in a disastrous feature-laden hodgepodge which would not be really suitable for anyone." Their answer: "The burden of system design and specification is transferred to the user," which works only with "a general medium of communication which will allow ordinary users to casually and easily describe their desires for a specific tool," plus "enough already-written general tools so that a user need not start from scratch" (Kay and Goldberg 1977, pp. 403–404 in the reprint). Read in 2026, that is the video's "contained environment and primitives," with the general medium now spelled "natural language."

Richard Stallman described the same freedom for a text editor in 1981: users "can add new editing commands or change old ones to fit his editing needs, while he is editing," and libraries let them "publish and share their extensions" (Stallman 1981). The Unix authors had already written down the primitives half: "Make each program do one thing well," and "Expect the output of every program to become the input to another, as yet unknown, program" (McIlroy et al. 1978). In 2000, Brad Myers, Scott Hudson and Randy Pausch asked for exactly the architecture the video describes: customization "should not be built into individual applications as is done today," because users would have to learn a new technique for each one; "the facilities should be provided at the system level" (Myers et al. 2000, p. 21).

Apple came closest to shipping it. OpenDoc, developed with IBM and others and released in 1994, built documents out of parts edited in place by small, swappable editors, with no single application owning the document. Apple cancelled it in 1997, after Steve Jobs returned. The accounts I could find blame money, platform politics against Microsoft's competing technology, too few components and slow performance. None show that users rejected the idea. OpenDoc asked platform owners to give up the application as the thing they sell, and that incentive has not changed.

So the wish is old. What is plausibly new in 2026 is the way in. A sentence typed in plain language lowers the threshold further than any earlier system did, and an interface generated for one person on demand has no exact precedent. The rest of this essay asks what fifty years of research on real users says about that threshold, and what it means for the people who design the interface on the other side of it.

3. Who changes things, and how much

The question "do users customize their software?" has two famous answers that seem to contradict each other.

The first is the 1996 WordPerfect study: 92% of participants customized something, with an average of 9.1 changes each, and 77% changed the button bar. The most changed setting was how often the program saved a backup. Fewer than 15% changed anything about the program's visual appearance (Page et al. 1996). The second is the widely repeated claim that fewer than 5% of users ever change a setting. Its source is a 2011 blog post by the usability researcher Jared Spool, describing an experiment from "the early days of PC computing" in which "several hundred" Microsoft Word users emailed in their settings files. The post gives no year, no exact sample and no publication, and it adds that programmers and designers had often changed more than 40% of the options, some as many as 80% (Spool 2011). It is an anecdote from a respected practitioner, and every later use of the figure I could find traces back to it.

The two numbers measure different things, and once they are sorted by cost they agree. A change that is visible and takes one step, like dragging a button onto a toolbar, gets made by a large share of people. A change buried in a settings dialog gets made by a few. A change that requires editing configuration files belongs to a skilled minority. Wendy Mackay's 1991 study of 51 users of MIT's Project Athena found that the people who customized deeply were a small, technically skilled group, and that the most common barriers were lack of time and the difficulty of the change itself (Mackay 1991). The modern equivalent of the toolbar is the phone's text-size setting: Airbnb's engineers reported that up to about 30% of their iOS users had a non-default size, larger or smaller.

The pattern has a name in behavioral economics. Eric Johnson and Daniel Goldstein showed that whether a country asks citizens to opt into organ donation or opt out moves consent rates by close to 60 percentage points, even for a decision people say they care about deeply (Johnson and Goldstein 2003). The harder the switch, the more the default wins. Software has the same law. And the speaker's own line places them precisely: someone who wants to reshape every app by command is in Spool's 40-to-80% group, which in every sample I found is made of programmers and designers.

4. Wanting control, and using it

A second body of research asks what people prefer when the interface can change: a design they adjust themselves, or one that adjusts itself to them. The answer is consistent, and so is the gap between the answer and what people do.

Joanna McGrenere, Ronald Baecker and Kellogg Booth gave 20 people six weeks with two versions of Microsoft Word: the standard Word 2000, whose menus adapted automatically to what you used, and a "Word Personal" that started with a handful of functions and let users add more themselves. Thirteen of the twenty preferred their own version (McGrenere 2002). In a lab study of 27 people, Leah Findlater and McGrenere found that 55% preferred menus they arranged themselves, 30% preferred menus that rearranged themselves, and 15% preferred fixed menus, even though the fixed design was the fastest. Five of the 27 did not customize properly even when customizing was the task, and most believed they were fastest with their own arrangement when they were not (Findlater and McGrenere 2004).

Microsoft ran the adaptive version at scale. Office 2000 shipped menus that hid the commands you rarely used and promoted the ones you used often. Jensen Harris, who led the Office interface team, wrote in 2006 that "Adaptive Menus were not successful," because there was "no way to get the default 'short' menu right" for people who use "an amazingly wide range of functionality," and because "auto-customization, unless it does a perfect job, is usually worse than no customization at all." Most corporate customers switched the feature off (Harris 2006).

Two lessons carry forward. People want control, and they dislike interfaces that move by themselves. And wanting control does not mean using it, or knowing whether it helped. For AI-generated interfaces this draws a clear line. An interface you ask to change sits on the adaptable side, the one users prefer. An interface that reshapes itself from what it guesses you want repeats Office 2000, with better guesses.

5. The gardeners

The most important finding in this literature is social, and it is the one the video leaves out entirely. The speaker imagines a single user modifying their own container. Every study of real workplaces found something else: a few people make the changes, and everyone else adopts them.

Mackay found that Unix customization files at MIT were widely shared, and that a middle group she called translators built setups for less technical colleagues (Mackay 1991; see also her CSCW 1990 paper on sharing). Michelle Gantt and Bonnie Nardi studied CAD users in seven companies and found in every group "at least one local expert who provides support for other users," a person who "is a fellow domain expert, not a professional programmer." Four of the seven end users they followed did no customizing at all, mostly because someone else did it for them. In three of the companies, the role had been made formal, with a job title, time and resources: the companies called these people gardeners, from a corporate campaign to "grow productivity" (Gantt and Nardi 1992, pp. 107–112). Nardi's book A Small Matter of Programming (1993) found that such local developers "seem to spontaneously emerge" in "virtually all the settings we studied," and argued that systems should "take advantage of the naturally occurring division of labor," since "no one is expected to know how to do everything, or to be interested in knowing how to do everything" (pp. 104, 121).

The role keeps being rediscovered. Gerhard Fischer and Elisa Giaccardi wrote in 2006 that being a designer "is not an attribute of a person, but a role assumed in a specific context," and that people want to act as designers "not all of them, not at all times, not in all contexts" (Fischer and Giaccardi 2006). In 2024 Maggie Appleton described "barefoot developers," people "technically savvy and interested in solving problems for themselves and people around them," who hit a "command line wall" (Appleton 2024). Her barefoot developer is Nardi's local developer, renamed thirty-one years later.

AI could change this in two directions. Geoffrey Litt has suggested the model itself can play the local developer, helping users and teaching them as it goes (Litt 2023). Or it could reproduce the failure Mackay already saw in the translators, who "sometimes distributed buggy code throughout the organization" (as reported by Gantt and Nardi, p. 113), at a scale no human translator could reach. The research cannot yet say which. It does say that a design for modifiable software that has no place for the gardener is a design for the 1%.

6. The dials people actually turn

If there is one group with every reason to reshape the interface, it is people whose eyesight makes the default unusable. WebAIM's 2018 survey of 248 people with low vision is the clearest evidence of what they do. Almost half, 48.4%, used screen magnification or system magnification settings. 44% used browser zoom, 30.6% high-contrast settings, and 82.4% used accessibility settings on a phone or tablet. Only 12.5% used custom stylesheets, the original web mechanism for rewriting how a site looks (WebAIM 2018).

That is the strongest real-world case for user-modifiable interfaces, and it points to a specific form. The modifications people use most are a few settings that live at the level of the system and apply everywhere: text size, zoom, contrast, motion. They take one step, they survive every app update, and they work in software whose makers never thought about them, provided the makers built their interfaces to respect them. Web accessibility guidelines have criteria for exactly this, requiring layouts to reflow at high zoom and to tolerate user-changed text spacing without breaking. Myers, Hudson and Pausch asked for customization at the system level in 2000. The users who need it most have been voting for it with their settings ever since.

7. What the slope is made of

Put the findings together and the design problem changes shape. If anyone can ask for their own interface, the screen a designer draws stops being the product for some people and stays the product for most of them. The work that matters is the structure underneath: what nearly everyone gets, what a few can build with, how the two connect, and how changes travel between people. I find it useful to name four parts.

The first is the default. Every number in this essay says the default is the interface almost everyone lives in, and AI does not change that. If anything, it raises the stakes: when the minority who want something different can get it by asking, the default no longer has to compromise for them. It can be designed for the people who will never touch a setting, which is most people.

The second is the primitives. Kay and Goldberg's "already-written general tools," the Unix programs that do one thing, Myers's system-level facilities. For a prompt-driven interface, these are the pieces the AI is allowed to recombine: components, data, actions. Their quality sets the ceiling of what users can make and the floor of what can go wrong. Nardi's observation from CAD users applies directly: less experienced users mostly change parameter values in examples someone else wrote, so the examples should be built so that "much can be accomplished by making such changes" (Gantt and Nardi 1992, p. 113).

The third is the slope itself. Myers called it the gap between threshold and ceiling: most systems are either easy to start with and limited, or powerful and hard to start with (Myers et al. 2000, p. 6). The goal since the 1990s has been a gentle slope, where each small increase in what you can change costs only a small increase in what you have to learn; HyperCard's five user levels, from browsing to scripting, are the standard example. A text box that accepts any request looks like the gentlest slope ever built. It may be a cliff with a friendly sign. Nardi argued in 1993 that "conversation is not the best model for human-computer communication," and Litt and the researchers at Ink & Switch have repeated the point for language models: chat is "an essentially limited interaction mode," and people also need to point, drag and make small precise edits (Litt 2023; Ink & Switch 2025).

The fourth is sharing. The gardener needs somewhere to put what they made and a way for others to adopt it. Stallman built that into Emacs in 1981. A prompt-built change that lives only in one person's account helps one person.

This is also where the video's "container" needs a closer look. Ink & Switch's 2025 essay on malleable software makes the sharpest point: settings "only offer controls that the application developers have thought to expose," and plugins "can only edit an app's behavior in specific authorized ways." Their comparison for AI code generation in today's software is "bringing a talented sous chef to a food court." A container the vendor controls is a better front door to a plugin system. A substrate the user owns, where data and tools are shared across applications, is what OpenDoc tried and what Ink & Switch argue for. The speaker asks for the first and describes the hopes of the second. Designers will mostly be asked to build the first, and should know the difference.

8. My own small software

I am not a programmer. Over the past year, with an AI model writing the code, I have built a handful of small tools that run on a computer at home and that I use every day from my phone: a tea timer, a calculator for the charts I use in my reading work, a dashboard that collects my social media numbers in one place, and a reference library of close to ten thousand images, each indexed by the visual technique it uses. Each one does exactly what I wanted and nothing else. In Robin Sloan's phrase, they are home-cooked meals: no one else will ever use them (Sloan 2020).

Looking at them through this research, two things stand out. The first is that the AI has been my gardener. Everything Gantt and Nardi describe the local developer doing (taking a request from a colleague in the same field, building it, testing it, fixing it when it breaks) is what the model does when I ask for a tool. That part of the video's future has arrived, for people like me.

The second is less flattering to the video's thesis. None of my tools modifies an application I already use. Each one is a new, standalone thing, built because the software I depended on could not be changed. That is Ink & Switch's sous chef in the food court, exactly. The apps I spend most of my working day in, the design tool, the browser, the note-taking app, are as fixed as they were before, and my reference library does not talk to any of them. My experience supports the speaker's wish and also shows how far it is from the container they describe.

9. Against myself

The strongest objection to this essay is that AI changes the economics that produced every finding in it. Mackay's users did not customize mainly for lack of time and because the change was hard. If a request in plain language removes both barriers, the minority could grow into a majority, and fifty years of research on settings dialogs and configuration files would describe a world that no longer exists. There are early signs. Lovable, a company that builds apps from prompts, reported in June 2026 that 80% of its builders described themselves as non-technical, across 50 million projects. In a small CHI 2025 study, all eight participants who customized an interface by chat found it useful and easy (Cao et al. 2025).

I take the objection seriously, and the evidence for it is still thin. The Lovable figures come from a company selling the product, describe people who already chose a tool for building apps, and measure projects made, not tools people kept using. Anthropic's report of "over half a billion artifacts" created by mid-2025 has the same problem. No one has published how many of these become things a person returns to, which is the number that would actually test the speaker's prediction. The controlled studies have eight or a few dozen participants, in supervised sessions, which is where Findlater's participants also liked customizing.

Security pushes the other way. Every route to user-modified software has eventually carried a security cost. A phishing email gave attackers control of the Cyberhaven browser extension, used by about 400,000 people, on Christmas Eve 2024. Code editor extensions are not isolated from the rest of the system, and researchers found working exploits affecting millions of installs. AI adds new failures: code-generating models invent package names in at least 5.2% to 21.7% of cases, depending on the model, names attackers can register (Spracklen et al. 2025), and instructions hidden in an AI tool's description can make an agent send private files elsewhere (Invariant Labs 2025). An interface someone built by asking may contain code and connections they never saw. Companies will fence this in, as they fenced in adaptive menus and browser extensions, and that will slow the slope for exactly the people it was supposed to help.

And my own case is a sample of one, a designer in the group that has always changed more settings than anyone else.

10. At the desk, and how this could be wrong

For my own work, the conclusion becomes a short set of rules. Design the default for the person who will never change it, because that is nearly everyone, and because the people who want something else increasingly have another way to get it. Build interfaces that respect the system-level dials people already use, text size, zoom, contrast, motion, since those are the modifications with the most users. When a product lets people change it, decide what the primitives are on purpose, make the climb from small change to larger change gentle, and give changes a way to travel from the person who made them to the people who could use them. Keep changes the user asks for separate from changes the system makes on its own initiative, because users have rejected the second kind for twenty-five years.

The argument could be wrong in three specific ways. First, a long-term field study could find that most ordinary users, given an AI that changes interfaces on request, keep making and using their own modifications months later. That would break the minority pattern this essay rests on, and I would want to read it. Second, a major platform could ship a substrate the user owns, with shared data and composable tools across applications, and see wide use. That would make the vendor's container, and its limits, a passing stage. Third, if AI models turn out to be reliable gardeners for whole teams, with fewer of Mackay's bugs spreading through the organization rather than more, the social layer might stop needing people at all.

Until one of those happens, I read the video as an accurate portrait of its speaker and an honest wish that I share. The future it describes is already here for people like us. For almost everyone else, the interface will still be the one a designer chose, and the default will still be the product.

References

• Anthropic. (2025, October 9). Claude Code plugins. https://claude.com/blog/claude-code-plugins
• Appleton, M. (2024). Home-cooked software and barefoot developers. Local-First Conference, Berlin. https://maggieappleton.com/home-cooked-software
• bb. (2026). The IDE that builds itself. https://getbb.app/
• Cao, Y., Jiang, P., & Xia, H. (2025). Generative and malleable user interfaces with generative and evolving task-driven data model. CHI '25. https://arxiv.org/abs/2503.04084
• DeepSeek. (2026). DeepSeek Harness: Everything is a Plugin. https://github.com/deepseek-ai/deepseek-harness
• Findlater, L., & McGrenere, J. (2004). A comparison of static, adaptive, and adaptable menus. Proceedings of CHI 2004, 89–96. https://doi.org/10.1145/985692.985704
• Fischer, G., & Giaccardi, E. (2006). Meta-design: A framework for the future of end-user development. In H. Lieberman, F. Paternò, & V. Wulf (Eds.), End User Development (pp. 427–457). Springer. https://doi.org/10.1007/1-4020-5386-X_19
• Gantt, M., & Nardi, B. A. (1992). Gardeners and gurus: Patterns of cooperation among CAD users. Proceedings of CHI '92, 107–117. https://doi.org/10.1145/142750.142767
• Harris, J. (2006, March 31). Combating the perception of bloat (Why the UI, part 3). Microsoft. https://learn.microsoft.com/en-us/archive/blogs/jensenh/combating-the-perception-of-bloat-why-the-ui-part-3
• Invariant Labs. (2025, April 1). MCP security notification: Tool poisoning attacks. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
• Johnson, E. J., & Goldstein, D. G. (2003). Do defaults save lives? Science, 302, 1338–1339. https://doi.org/10.1126/science.1091721
• Kay, A., & Goldberg, A. (1977). Personal dynamic media. Computer, 10(3), 31–41. Reprinted in N. Wardrip-Fruin & N. Montfort (Eds.), The New Media Reader (pp. 393–404). MIT Press, 2003. https://www.newmediareader.com/book_samples/nmr-26-kay.pdf
• Litt, G. (2023, March 25). Malleable software in the age of LLMs. https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming
• Litt, G., Horowitz, J., van Hardenberg, P., & Matthews, T. (2025). Malleable software: Restoring user agency in a world of locked-down apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/
• Mackay, W. E. (1991). Triggers and barriers to customizing software. Proceedings of CHI '91, 153–160. https://doi.org/10.1145/108844.108867
• McGrenere, J. (2002). The design and evaluation of multiple interfaces: A solution for complex software (Doctoral dissertation). University of Toronto. https://www.cs.ubc.ca/~ksbooth/PUB/docs/JMcGrenere2002.pdf
• McIlroy, M. D., Pinson, E. N., & Tague, B. A. (1978). UNIX time-sharing system: Foreword. Bell System Technical Journal, 57(6), 1899–1904. https://archive.org/details/bstj57-6-1899
• METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• METR. (2026, February 24). We are changing our developer productivity experiment design. https://metr.org/blog/2026-02-24-uplift-update/
• Myers, B., Hudson, S. E., & Pausch, R. (2000). Past, present, and future of user interface software tools. ACM Transactions on Computer-Human Interaction, 7(1), 3–28. https://doi.org/10.1145/344949.344959
• Nardi, B. A. (1993). A Small Matter of Programming: Perspectives on End User Computing. MIT Press.
• Page, S. R., Johnsgard, T. J., Albert, U., & Allen, C. D. (1996). User customization of a word processor. Proceedings of CHI '96, 340–346. https://chi1996.acm.org/proceedings/papers/Page/srp_txt.html
• Sloan, R. (2020). An app can be a home-cooked meal. https://www.robinsloan.com/notes/home-cooked-app/
• Spool, J. (2011, September 14). Do users change their settings? UIE Brain Sparks. https://archive.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/
• Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. USENIX Security 2025. https://arxiv.org/abs/2406.10279
• Stallman, R. M. (1981). EMACS: The extensible, customizable, self-documenting display editor. MIT AI Memo 519a. https://www.gnu.org/software/emacs/emacs-paper.html
• WebAIM. (2018). Survey of users with low vision #2. https://webaim.org/projects/lowvisionsurvey2/
• Yang, et al. (2025). No-code modification of the Truman platform with LLMs [TrumanBench]. HEAL workshop, CHI 2025. https://heal-workshop.github.io/chi2025_papers/no_code_truman.pdf

Source note: sources were checked on 6 November 2026. Kay and Goldberg are quoted from the New Media Reader reprint; Page et al., Findlater and McGrenere, McGrenere's dissertation, Gantt and Nardi, Myers et al., Stallman, the Unix foreword, Harris, WebAIM and the Ink & Switch essay were read in their original text. Mackay 1991 is described from secondary accounts (McGrenere 2002; Nardi 1993) and not quoted. Spool 2011 is a blog post describing an unpublished informal study. The Airbnb text-size figure, the OpenDoc history, the Cyberhaven incident and the Lovable and Anthropic adoption figures come from company or secondary reports. The speaker of the video is unidentified, and its claims are quoted from auto-generated captions. Section 8 describes the author's own tools and is observation, not evidence.