The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing

This talk fundamentally challenges the long-standing 'frozen artifact' model of software distribution, arguing it's obsolete due to the collapsing cost of software changes (driven by AI) and persistent demand for personalization. Iris ten Teije introduces Differ's vision of 'adaptive software' using a 'stem and divergences' architecture, where each user runs a unique, live-adapted version. The presentation delves into the complex architectural, testing, and coordination challenges of this new paradigm, emphasizing the need for robust infrastructure to manage user-specific, mutable software safely.

July 7, 2026 6 min read

The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing — source: https://www.youtube.com/watch?v=bRnoEpoK5m4

Iris ten Teije, co-founder of Differ, presents a compelling argument that the long-standing paradigm of “one version of your software for everyone,” built on the concept of a frozen artifact, is becoming obsolete. This foundational shift is driven by the dramatically falling cost of producing software changes and an inherent, long-standing demand for personalized digital experiences.

The Legacy of the Frozen Artifact

For decades, the entire software distribution stack, encompassing CI pipelines, packagers, registries, container images, and app store reviews, has been designed to solve a singular problem: moving a frozen, verifiable code artifact from where it was built to where it runs, safely and reproducibly. This model, while deeply ingrained, was a direct consequence of the historical expense and risk involved in producing correct software changes. Such changes were rare, central events that necessitated thorough verification, freezing, and identical distribution to all users.

While this “one-way pipeline” offered crucial advantages like reproducibility, previewability, and rollback, it inherently prevented software from truly catering to individual needs. The idea of a “version per user” was economically unfeasible, requiring prohibitive code forking and manual maintenance. Consequently, “one version for everyone” became an unchallenged norm, perceived as an immutable law of software rather than an economic constraint.

The Erosion of Old Constraints

This core assumption is now breaking down. The cost of producing accurate and scoped software changes is “collapsing towards zero,” primarily fueled by advancements in AI and coding agents. Significantly, software production is no longer confined to a centralized, upfront build process; it can now occur dynamically on the server, client, or even within a user’s live session.

As the cost of making a change approaches that of running it, and changes can occur in the same context as execution, the traditional boundary between development and distribution is dissolving. The historical justification for this separation—expensive development versus cheap runtime—no longer holds.

The Inevitable Demand for Personalized Software

Demand for personalized software is not new, but its widespread realization was previously constrained by cost. Historical examples illustrating this demand include:

Forward-deployed engineers and professional services: Large enterprises routinely customize software implementations, often with dedicated consultants.
Engineers’ dot files and editor configurations: Developers manually configure their tools for highly personalized workflows.
Excel: Arguably the most successful business software, Excel thrives because it enables millions of users to build their own custom applications on top of it.

Prior attempts at personalization, such as feature flags, segmentation, and A/B testing, were limited by forcing variations into predefined, declared-in-advance buckets. Today, however, the new economics of software production finally make truly “adaptive software” a reality.

Differ’s Architectural Vision: Stem and Divergences

Differ proposes an architecture that transcends the conventional model of a single codebase managed by flags. Instead, it advocates deploying a “canonical stem,” from which “every user runs her own divergence.” This means maintaining a “same origin, but individually adapted live” system, fundamentally shifting from delivering “the least worst version for everyone to the best version for anyone.”

Addressing developer skepticism regarding increased brittleness, Iris clarifies that the perceived fragility stems from “unmanaged divergence inside a single artifact”—tangled codebases lacking clear boundaries. Differ’s model, in contrast, utilizes bounded, isolated, and individually reversible divergences. This architectural choice ensures that the “blast radius” of any change is contained to a single user’s context, and individual divergences can be rolled back live without requiring a full redeploy. Furthermore, developers retain critical control by explicitly defining which parts of the application (e.g., authentication, payments) are off-limits for adaptation.

A Concrete Example: Adaptive CRM

Consider a CRM system. While typically designed for salespeople, an investor user might have unique workflows. The adaptive system observes her behavior—such as consistently logging founder intros, skipping irrelevant fields, or prioritizing specific deal types. Over time, the system learns and automatically adapts the user interface and information surfacing to better align with her needs. Users can also proactively request changes, which, if within developer-defined boundaries and the software’s original purpose, can be implemented without direct developer intervention. This capability allows horizontal SaaS products to serve a vastly wider range of customer personas without a proportional increase in R&D spend.

The Hard Problems of Adaptive Software

While the generation of code, particularly with AI, is becoming “the easy 80%,” the real challenges lie in the “substrate” required to make adaptive software safe, reliable, and effective at scale. Differ is actively tackling several complex problems:

Source of Truth: In the absence of a single artifact, the “software” is defined by the stem plus all mutual, immutable divergences. Determining what a user is running and why transforms into a graph query rather than a version number. This necessitates immutable, inspectable, and attributable divergences with clear lineage, traceable back to the specific signals that triggered adaptation.
Correctness: Traditional testing methodologies are insufficient. Testing must now encompass the canonical stem and all possible divergences, a significant increase in complexity.
Desirability: Beyond mere correctness, it’s crucial to measure whether adaptations are genuinely beneficial. This requires defining and tracking relevant metrics (e.g., improved retention, reduced churn, lower support tickets) to ensure adaptations achieve desired business outcomes.
Autonomy vs. Control: Differ’s vision is a system capable of understanding users well enough to act autonomously, minimizing the need for constant developer approval. The challenge lies in building systems trustworthy, legible, and reliable enough for humans in the loop to confidently step back.
Coordination: Managing updates across potentially millions of per-user versions is complex. Differ’s answer: “Don’t merge code, merge intent, merge outcome.” This allows users to converge on a shared goal through their unique adaptive paths, rather than requiring identical codebases.

Conclusion: A Fundamental Paradigm Shift

This shift towards adaptive software represents a fundamental paradigm change, comparable to the rise of digital banks or the widespread adoption of CI/CD. The constraint that necessitated “one version for everyone”—the high cost of producing software changes—has effectively vanished. As the cost of making software becomes as cheap as running it, the distinction between development and distribution disappears. The next two decades of software will focus on shipping “the right version to anyone with the isolation and provenance that makes it safe instead of terrifying.” Differ is dedicated to building the infrastructure for this adaptive future.