The Pipeline Is Dead

How much of a software career goes into moving software from one computer to another? CI pipelines, package registries, container images and app-store reviews all help move a frozen artifact from the machine where it was built to the machine where it runs—safely and reproducibly.

Underneath that infrastructure sits a familiar assumption: one version of the software for everyone. Iris ten Teije introduces herself as a co-founder of Differ, the adaptive-software product of Sky Valley Ambient Computing. She describes her co-founder, Noam Tenne, as JFrog’s first engineer, someone who helped build the pipeline infrastructure she now proposes moving beyond. Her own perspective comes from a decade in fintech, including an early role at a digital bank that scaled and exited. Reliability concerns are familiar territory, even as she argues for changing the delivery model.

The traditional separation between production and execution made economic sense. Producing a correct change required skilled humans working for hours or days. Changes therefore became relatively rare, centralized events: make the change, verify it, freeze it and distribute the result. A one-way pipeline followed naturally from work that was expensive and risky.

A frozen artifact also gives engineers a stable object to reason about. Review examines something that will remain unchanged; reproduction can use the same artifact; rollback can restore an earlier one. Those guarantees explain why immutability became such a valuable foundation for production systems.

The trade-off was limited individual fit. Giving two users genuinely different software meant forking the codebase and maintaining both versions by hand. Extending that approach to every user was economically impractical. One version for everyone did not have to defeat personalized software in a design debate: personalized software was usually outside the budget. Uniformity came to look like an intrinsic property of software because the alternative was so difficult to sustain.

Ten Teije’s economic premise is that the cost of producing a correct, scoped change is approaching zero. This is a forecast about the direction of software production, not a measured cost or correctness benchmark. The architectural consequence depends on where that production happens: some work can occur on a server, some on a client, and some inside a user’s live session.

A decision previously fixed at build time can instead be made in context, while the user is working. Each piece of the production process can move to the location where it makes sense, including directly in front of the user. If making a change becomes comparable in cost to running software—and both can happen in the same place—the economic reason to keep development and distribution separate weakens.

Cheaper production addresses supply. The demand for software that fits a particular person or organization already exists, and several familiar practices reveal it:

• Professional services: Forward-deployed engineers and consultants customize enterprise software for large customers. A major Salesforce customer can pay for specialized configurations and an engineer embedded in its working channels. Smaller customers can benefit from that attention too; the expense has been the obstacle.
• Developer configuration: Dotfiles, editor settings and key bindings turn general-purpose tools into personal tools, often through repeated manual work on each machine.
• Excel: A common application becomes a platform on which users build their own programs and business workflows.

These are different ways of paying for individual fit—with consulting budgets, engineering effort or end-user programming.

Personalized social feeds provide another analogy, although they adapt content rather than software behavior. Ten Teije points to their success as evidence of appetite for personalization; the talk supplies no experiment or measurements for the broader performance claim. Coding agents, in her account, could extend that personalization into the software layer itself.

Feature flags, segmentation and A/B testing already let products diverge. Their usual constraint is that developers define the alternatives and user buckets in advance. The proposed next step is adaptation that responds to an individual’s context without requiring every possible variation to have been designed beforehand.

When an agent runtime can both execute software and modify it, development and distribution begin to occupy the same process. Differ’s architectural bet is to deploy a canonical stem: a shared origin from which each user runs an individually adapted divergence. The stem supplies the common foundation; the divergences supply personal fit.

The proposed change is therefore more substantial than adding another configuration screen. Users retain a common origin while the software they run can evolve differently. This is Differ’s intended architecture, rather than a deployment procedure demonstrated in the recording.

Removing the single frozen artifact creates an immediate objection. Ten Teije recounts a CTO’s concern: if one AI-generated codebase is already difficult to reason about, running vast numbers of them seems to multiply the problem. That objection identifies a real failure mode—unmanaged divergence inside tangled software, where large files and unrestricted dependencies allow changes to affect unrelated behavior. The structural problem is the absence of boundaries, regardless of who generated the code.

Differ’s proposed answer is bounded, isolated and individually reversible divergences. A bad variant must not silently corrupt the stem or affect another user. Under that design, a change’s blast radius is one context, and that divergence can roll back live without requiring a new deployment. These are architectural requirements; the talk does not specify their enforcement mechanisms.

The safety argument rests on those boundaries, rather than confidence that a model will always coordinate changes correctly. Developers must also define what adaptation is allowed to touch. A form might adapt to improve conversion, while particular fields remain mandatory and cannot be dropped. Authentication and payments can be entirely off-limits. Personalization then operates inside an explicit permitted scope.

Consider the talk’s illustrative investor using a CRM built primarily for salespeople. She repeatedly logs founder introductions and records who introduced her to each deal. An adaptive system could recognize that recurring activity and create an introduction path, giving an important relationship its own place in the product.

Next, the system notices fields she consistently skips. It could stop surfacing those fields and give more prominence to information she actually uses. Her browsing behavior provides another signal: if she repeatedly checks particular kinds of deals or founders, the CRM could prioritize that information instead of continuing to use its default sales-oriented ranking. These are proposed adaptations in a scenario, not measured outcomes from a deployed CRM.

Observation is only one input. The investor could also request a change directly. The intended system would implement requests without sending each one back to the developer, provided they respect both developer-defined boundaries and the application’s original purpose. For a horizontal SaaS product, the proposed benefit is serving more customer personas without a corresponding increase in R&D spending.

Making that architecture work introduces several problems that ten Teije explicitly says the team has not fully solved. The first is identifying the software itself. With no single artifact representing every user’s experience, the source of truth becomes the stem plus all its immutable divergences. Determining what a user runs—and why—becomes a graph query rather than a version-number lookup.

A bug report now describes a program specific to the reporting user. Debugging requires each divergence to be immutable, inspectable and attributable, with a trace through the decisions that produced it:

1. Identify the originating signal.
2. Inspect the recommendation that followed from that signal.
3. Recover the exact adaptation made from that recommendation.

That lineage connects a user-visible behavior to its cause. A collection of generated code variants alone cannot answer why a particular user received a particular change.

Correctness becomes a broader validation problem. Engineers must check whether a code change works and whether the resulting UI is correct, while reasoning about both the shared stem and its possible divergences across users. Testing only the common foundation leaves the adapted experiences outside the validation scope.

A change can pass those checks and still make the product worse. Desirability requires a separate evaluation: did the adaptation produce an improvement that matters to the product and its users? Depending on the application, relevant goals might include higher retention, lower churn or fewer support tickets. The success criterion must be chosen for the software in question, then used to assess its adaptations; generating valid code does not establish uplift.

Recommendation-only operation is a valid conservative starting point: the system proposes changes without making them autonomously. Differ’s intended destination goes further. The system should understand a user well enough to act without obtaining fresh developer permission for every adaptation.

That ambition makes trust an engineering requirement. The system must become reliable and legible enough that people choose to step back from individual decisions. Existing adaptation boundaries still matter, but adding more approval steps is not the desired endpoint. The goal is to earn autonomy through behavior people can understand and depend on.

Individual versions create a coordination problem when the shared product changes. How should an update propagate across potentially millions of different user experiences? That scale is a design scenario, not a reported deployment count. Ten Teije’s guiding principle is: “Don't merge code, merge intent, merge outcome”. Users need not run the same commit or identical code if their versions can converge on the same goal through different paths. The talk offers this as a direction for reconciliation, without supplying an algorithm.

Code generation is consequently only one part of the work. Ten Teije calls it the “easy eighty percent,” a rhetorical estimate rather than a measured workload split. Calling a model to produce code is accessible; making its adaptations observable, validating them and coordinating their evolution is the harder infrastructure business. The required foundation includes the stem and divergences, provenance and validation—not merely a generation endpoint.

Ten Teije closes with two shifts in expectations. Early in her fintech career, a bank without branches could sound reckless; later, the physical branch could seem like the unusual part. Her co-founder once had to persuade engineers that builds and CI were necessary. Practices that eventually feel obvious can begin as contested departures from familiar infrastructure.

On this account, the pipeline loses its central role because its governing constraint changes, even while it continues to function. Expensive software production encouraged teams to freeze a version and ship it broadly. If making software becomes as cheap as running it, development and distribution no longer need the same separation.

The closing forecast contrasts the effort spent learning to ship one version for everyone with the work ahead: delivering the right version for an individual. The safety requirements remain central to that future. Individual adaptation needs isolation and provenance so that engineers can contain a change, understand its origin and reason about the software a particular person actually runs.