Software distribution was built around one frozen artifact because producing correct changes used to be expensive and risky.
2
Adaptive software gives each user a bounded, reversible divergence from a shared canonical stem.
3
The hard infrastructure problems are provenance, validation, observability, desirability, trust, and coordination across divergent versions.
Summary
Iris ten Teije argues that software distribution still assumes one frozen version for everyone because changing software used to require expensive, central work. That constraint is weakening as coding becomes cheaper and software can change inside a user's live session. Differ's proposed architecture has one canonical stem and an isolated divergence for each user. These divergences can adapt to observed behavior or user requests within developer-defined boundaries. The architecture creates difficult infrastructure questions: what counts as the source of truth, how to inspect a user's exact program, how to test every possible divergence, and how to measure whether a change is desirable. Ten Teije is direct that code generation is the easy part. The harder work is provenance, validation, observability, trust, and coordination. Updates should merge intent or outcome rather than force every user onto the same commit.
The frozen artifact came from the economics of software production
CI pipelines, package registries, container images, and app store reviews all solve the same problem: moving a frozen artifact from the machine where it was built to the machine where it runs. Ten Teije says this stack assumes one version for everyone. That choice made sense when producing a correct change took skilled humans hours or days, so changes happened rarely, centrally, and with careful verification. A frozen artifact gave teams reproducibility, previewability, and rollback. The important point is that one version was never selected after comparing it with a version per user. Different versions meant manually forking and maintaining the codebase, which was too expensive.
Cheap runtime changes dissolve the boundary between development and distribution
Ten Teije says the cost of producing a correct, scoped change is collapsing, and software no longer has to be produced in one place before anyone runs it. Some parts can run on the server, some on the client, and some in the user's live session. When making a change becomes close to as cheap as running one, the reason to keep development and distribution as separate phases weakens. The demand for personal software is also old. Enterprise customers pay for professional services, engineers customize dot files and editor settings, and Excel lets millions of people build their own programs. Coding agents can now move this personalization into the software layer.
Adaptive software starts from one stem and gives each user a bounded divergence
Feature flags, segmentation, and A/B testing already let software diverge, but they require teams to declare buckets and segments in advance. Differ's proposed shape is one canonical stem with an individually adapted live divergence for every user. The divergence is bounded, isolated, and reversible. Ten Teije argues that this can contain failures more tightly than a tangled artifact in which everything can touch everything else. A bad change should not silently corrupt the stem or reach another user. Its blast radius is one context, and that divergence can be rolled back without a deployment. Developers can also define what may change, such as allowing form adaptations while keeping payments or authentication off limits.
User behavior can adapt a product within developer-defined boundaries
Ten Teije uses a CRM to make the model concrete. An investor may repeatedly record founder introductions and who made each introduction, so the system can create an intro path for that person. If she always skips certain fields, the CRM can stop surfacing them and show fields she uses more often. If she repeatedly checks particular deal or founder types, the system can change what it prioritizes. Users can also request changes directly, provided those changes stay within the developer's boundaries and the software's purpose. A horizontal CRM could then serve more customer personas without increasing research and development spending.
Without one artifact, source of truth and debugging become lineage problems
When there is no single shipped artifact, Ten Teije defines the software as the stem plus all the immutable divergences. That creates a lineage problem. The question is no longer answered by a version number alone. Engineers need to know what a particular user is running and why, which becomes a graph query. A bug report describes a program that exists for one user, so each divergence needs to be immutable, inspectable, and attributable. The system must trace a version back to the specific signal, recommendation, and adaptation that produced it. Ten Teije presents this as an active area of work rather than a solved problem.
Correctness is only one test; teams must also measure desirability
Adaptive software has to be tested across the stem and the possible divergences. Teams need to check whether a code change works and whether the user interface remains correct. They also need to ask whether a correct change was desirable. A working adaptation may still be a bad product decision. The metric depends on the software and the company's goals. Ten Teije names retention, lower churn, and fewer support tickets as possible goals. Adaptations therefore need to be measured against the outcomes the company actually cares about, rather than being accepted simply because the generated code runs.
The difficult part is trust and coordination, not code generation
A conservative approach would begin with recommendations and require approval before autonomous changes. Differ's stated direction is a system that understands a user well enough to act without asking the developer every time. That requires enough trust, legibility, and reliability for people to choose to step back. Coordination is another hard problem: updates must reach many divergent versions without forcing every user onto the same commit. Ten Teije's answer is to merge intent or outcome rather than code. The easy part is calling a language model to write code. The business is the substrate around it, including provenance, validation, observability, and coordination.
"The honest answer is you're brittle because there's a tangled artifact with no boundaries."09:11
Who should watch
You maintain CI, registries, packages, containers, or app releases and want to understand which assumptions those systems encode.
Your product has many customer-specific workflows, but manual professional services and custom forks are too expensive to maintain.
You are evaluating runtime adaptation and need concrete questions about isolation, provenance, testing, trust, and updates before adopting it.
