Most software you use today is configurable, not changeable. You can flip settings, pick a theme, or toggle features, but the underlying workflow stays fixed until an engineer ships an update. That gap between what you need right now and what the software was built to do is where a new idea is starting to surface: mutable software.
The term is not an established industry standard, and no major vendor has announced it as a formal product category. But it points to a real shift in how AI tools might let people shape applications around their own work instead of adapting their work around the application. If that shift happens, it will change how teams think about internal tools, support workflows, and software built in-house.
Why the Term Is Surfacing Now
In a September 2026 interview with Latent Space, Anthropic's Thariq Shihipar described Claude Code Mods as an early preview of software that can be customized safely, with AI doing some of the work of generating that customization [1]. He pointed to plugins that compose with each other, different operating modes, model routing, subagents, and interface changes that adjust based on context. He framed this as a forward-looking direction, not a finished definition of a new market.
That distinction matters. It is tempting to read "mutable software" and assume a company has declared a new product category. That is not what is happening. A practitioner at an AI lab is describing a pattern he sees emerging: software whose behavior and interface can be altered with AI assistance, inside boundaries someone has set. Treat it as an idea under discussion, not a settled term.
Why should teams getting up to speed with AI care about an unsettled term? Because the question behind it is concrete and already relevant: when you give an AI system the ability to change how a tool works, who decides what it can change, and what happens when it gets that wrong? Understanding the shape of the idea now means you won't be caught flat-footed if it becomes a real design pattern in the tools your team adopts.
The Line Between Configurable and Mutable
Ordinary configurable software lets a user pick from a menu of prebuilt options. Mutable software, as described in this emerging discussion, lets AI help generate or alter an application's behavior, workflow, interface, integrations, or rules for a specific context, within constraints set in advance.
That last phrase, within constraints, separates a promising idea from a risky one. Anthropic's own Claude Code documentation gives a concrete, current example of bounded adaptability. Hooks can fire at defined points in a tool's lifecycle, and one type, PreToolUse hooks, can block a tool call before it runs [2]. That is a working example of a system that can adapt its behavior while still enforcing a rule a human defined ahead of time. It is not unrestricted self-modification; it is customization with a guardrail built into the architecture.
This is the model worth holding onto: mutability paired with constraint, not mutability instead of constraint.
Two Hypothetical Examples
Example 1: Customer support workflow. Picture a support team that handles returns, billing questions, and shipping delays through one ticketing tool. Today, a supervisor configures routing rules by hand, and any new rule requires a change request to engineering. In a mutable software scenario, a team lead could describe a new situation, such as a shipping delay tied to a specific vendor, and an AI assistant could draft a new routing rule, a response template, and an escalation path for it, all operating inside existing permission boundaries and approval steps. The workflow adapts without the team waiting on a backlog, but it does not bypass the review or guardrails already in place.
Example 2: Internal reporting tool. Picture an operations team relying on a dashboard with a fixed set of charts. A new question comes up, such as tracking a seasonal pattern in a particular region, and the dashboard has no view for it. In a mutable software scenario, someone could ask an AI assistant to build a new report view, pulling from the same approved data sources and respecting the same access controls, without an engineer hand-building a new page. The interface changes to fit the question; the data governance and permissions around it do not.
Both examples are hypothetical. Neither describes a shipped product. They illustrate the distinction this idea points to: AI-assisted change within a defined boundary, not an application quietly rewriting itself.
What It Is Not
Mutable software is easy to confuse with things that already exist.
It is not ordinary settings. Choosing a dark theme or toggling a notification preference is configuration, not mutation. Nothing is being generated or altered; you are selecting from options someone already built.
It is not simple automation. A rule that says "if X happens, do Y" is useful, but static. Mutable software implies the rule itself, or the workflow around it, can be generated or reshaped for a new context, not just triggered.
It is not software that changes itself in production without oversight. This is the most important distinction. A system that silently alters its own behavior in a live environment, without review, approval, or a way to roll back, is not what this discussion describes. The "within constraints" condition exists specifically to rule this out, drawing the same line between bounded adaptation and unrestricted self-modification described above.
A Checklist for Teams Considering Mutable Software
If your team is evaluating AI tools that advertise this kind of adaptability, a few questions help separate a thoughtful implementation from a risky one:
- Can you see exactly what changed, when, and who or what triggered it?
- Is there a defined boundary, like a hook that can block an action, between the AI's suggestion and the production system?
- Can a human review or approve changes before they take effect in a live workflow?
- Is there a straightforward way to revert a change if it produces an unwanted result?
- Does the tool separate "AI drafted this" from "a person or policy approved this" in its audit trail?
General frameworks for managing generative AI risk, such as NIST's Generative AI Profile, a companion resource to the AI Risk Management Framework, reinforce the same basic point: governance, oversight, and risk management deserve attention wherever generative AI touches a consequential workflow [3]. Adaptability is only as trustworthy as the oversight built around it.
If this post has you thinking about where AI-assisted changes need human guardrails, the AI Governance course is a practical next step. It covers governance, oversight, and responsible-use foundations that help teams set sensible limits around AI systems.*
Closing Thoughts
Mutable software is not an official category yet, and treating it as one would get ahead of the evidence. What it does represent is a useful way to think about where AI-assisted customization is heading: software that can adapt its workflows, interfaces, and rules to a specific context, while staying anchored to constraints a person set in advance. For teams charting a course through new AI tools, the practical question is not whether a tool calls itself mutable. It is whether you can see what changed, who approved it, and how to steer back if it goes wrong.