Talk by Iris ten Teije (Sky Valley Ambient Computing) arguing that the traditional software distribution pipeline, which assumes a single version shipped to all users, is becoming obsolete. As producing changes becomes nearly free, modifications can happen at runtime, on the client, within a user's session, dissolving the line between distribution and development. The talk examines the infrastructure that must catch up: where source-of-truth lives when every user runs a different version, how to debug a program that exists for only one person, and why per-user versions could be more contained than a single shared codebase. It covers architectural decisions, unresolved tradeoffs, and frontier lessons, drawing on the speaker's work on Differ, infrastructure for adaptive software. # Channel Identity Observations — "The Pipeline Is Dead" (Iris ten Teije, Sky Valley Ambient Computing) ## Explicit Self-Description Evidence - **Speaker identifies herself as a startup co-founder:** > "I'm Iris. I'm one of the co-founders of Differ." - **Founder team credentials are stated directly:** > "My co-founder Noam was the first engineer at JFrog." > "I spent a decade in fintech. I was early at a digital bank that we scaled and exited." - **The talk explicitly describes the company's core thesis:** > "The shape that we bet on at Differ is that instead of one code base gated by flags and shipped to everyone, you deploy one canonical stem and every user runs her own divergence of it." - **Closing framing reinforces the company mission:** > "I'm Iris, this is Differ and that's what we're building." ## Intended Audience - **Software engineers and technical practitioners**, established by the opening rhetorical device: > "How many of you have spent a significant part of your career making software move from one computer to another? CI pipelines, packagers, registries, container images, app store reviews." - **Audience assumed to be skeptical of the pitch** — the speaker preempts objections: > "So, I totally get any reservations and I've had them myself as well." > A quoted CTO objection is addressed at length: "I can already barely reason about one AI-generated code base. And you want me to run millions of these?" - **Decision-makers / engineering leaders** are addressed as a segment (the CTO anecdote; references to R&D spend and company metrics like churn and support tickets). ## Claimed Scope - The talk claims an industry-level thesis: **CI/CD pipelines as a paradigm are ending** ("The Pipeline Is Dead", "the pipeline that I'm about to tell you is dying"). - The company claims to be working on open problems, not finished products: > "We haven't solved all of them, but we have a point of view on each of them." > "Coordination… is one of the challenges that we've been thinking hardest about." - Claims of present-day work in progress: > "That is really the hard part, and something that we're working on every single day." ## Observable Presentation Patterns - **Format:** a recorded conference-style talk (implied by "As we're online today, you can't raise your hands"), not a tutorial or product demo. - **Rhetorical style:** thesis-driven argumentation with historical framing (fintech branchless banks, JFrog CI history), concrete examples (CRM adaptation, form conversion, dotfiles, Excel), and structured enumeration of open challenges. - **Positioning strategy:** positions skepticism as valid but misdirected — > "That's not surprising. It's the right instinct, but perhaps aimed at the wrong target." - **Differentiation claim from commodity AI tooling:** > "Anyone can call an LLM, but the substrate is stem plus divergences, provenance, validation, that is really the hard part." ## Claims vs. Demonstrated Content - **Creator claims:** company vision, founder background, architecture concept ("stem plus divergences"), ongoing work on unsolved problems. - **Demonstrated:** conceptual/evangelistic content only — no product demo, code, or live system appears in the transcript; all examples ("we can have a scenario where we've got a form…") are hypothetical illustrations rather than demonstrated product behavior. # Delivery Observation: "The Pipeline Is Dead" — Iris ten Teije ## Tone & Register - **Confident but conciliatory**: projects certainty about the thesis while acknowledging skepticism. > "So, I totally get any reservations and I've had them myself as well. However, I'm telling you it's coming anyway." - **Conversational, spoken-style phrasing** rather than polished written prose: > "And yeah, that that is something that is extremely important to to keep track of..." ## Recurring Phrases & Verbal Patterns - **Repeated word restarts / stutters** appear throughout (transcript artifact of live or lightly-edited delivery): - > "so old that is so old" - > "each each each piece" - > "the entire the the entire building" - > "improve improve improve the metrics" - **Filler clusters** ("um", "uh") especially dense in example sections: > "In this case, uh we've got an investor who's using a CRM." - **Signposting transitions**: - > "So, to get back to the title of this talk..." - > "To close off with..." - > "To give another example to make adaptive software a bit more concrete." ## Teaching Habits - **Opens with audience interaction**, adapted to the medium: > "As we're online today, you can't raise your hands, but just nod at your screen." - **Concrete triads of examples**: CI pipelines, packagers, registries, container images, app store reviews; then forward-deployed engineers, dot files, Excel; then the CRM investor persona walked through in narrative detail. - **Voice-of-the-skeptic device**: stages an objection in quotation, then answers it: - > "What he said roughly was, 'I can already barely reason about one AI-generated code base. And you want me to run millions of these?'" - Response framing: > "It's the right instinct, but perhaps aimed at the wrong target." - **Reframing/key-phrase construction**, often with parallel structure: - > "from the least first version for everyone to the best version for anyone" - > "don't merge code, merge intent, merge outcome" - > "Generation has become easy... that's actually the easy 80%." - **Enumerated structure** for the hard problems (source of truth, correctness, desirability, autonomy vs. control, coordination), each introduced with a short label. ## Rhetorical Structure - **Historical-causal argumentation**: explains why the pipeline existed ("production of software being expensive and risky") before arguing it's obsolete. - **Counterfactual device** — "no one ever chose this": > "There was never a meeting where someone put one version for everyone versus a version for each person and picked the first one." - **Circular closure**: returns to the opening hand-raise premise at the end: > "To go back to the start of the talk, the pipeline didn't fail because it didn't work anymore." ## Communication Patterns - **Personal credibility woven in**, twice — co-founder bios early and reused as analogy late: > "My co-founder, Noam, used to fight with engineers about why you need builds and CI." - **Reassurance through architectural guarantees**, stated as compact triads: > "bounded, isolated, and individually reversible"; > "immutable, inspectable, attributable." - **Brand-name sign-off**: > "I'm Iris, this is different and that's what we're building." ## Uncertainty Notes - Filler and stutter density is higher in the mid-talk example sections and lower in the opening/closing; this suggests variable rehearsal, but sample size is one talk, so treat as a single-delivery observation. - No nonverbal delivery (gestures, pacing, visuals) is observable from the transcript alone. # Position Record: "The Pipeline Is Dead" — Iris ten Teije ## Speaker - **Iris ten Teije**, co-founder of **Differ** (talk identifies her as "Iris"). Her co-founder **Noam** is referenced (first engineer at JFrog) but does not speak. ## Core Thesis - The entire CI/CD stack (pipelines, packagers, registries, container images, app store reviews) solves one problem: moving a **frozen artifact** from build machine to runtime, safely, reproducibly, once. - That stack rests on an unexamined assumption: **one version of software for everyone** — never chosen deliberately, but forced by economics. - > "The pipeline didn't fail because it didn't work anymore, but the constraint it was built for went away." ## Reasoning: Why the Pipeline Existed - Producing a correct change was **expensive** (skilled humans, hours or days), so it was rare, central, verified, and frozen. - The one-way pipeline is "the direct consequence of production of software being expensive and risky." - The frozen artifact delivers **reproducibility, previewability, rollback** — but the price was that software "couldn't really be for anyone in particular." - The single-version model "never had to win an argument"; a version per user was not viable (forking, hand-maintaining code bases). - **Key claim:** this was "never really a fact about software. It was a fact about cost... and that cost just changed." ## What Changed - Cost of producing a correct, in-scope change is "collapsing towards zero." - Production no longer has to happen in one place up front — it can be split across server, client, and the user's live session. - Explicitly **downplays** AI code generation as the interesting part ("everyone has already said it"). - When the agent is the runtime and can modify software, "development and distribution stop being two phases." ## Demand-Side Evidence (for personalization) - **Forward-deployed engineers** / professional services at enterprise vendors (e.g., Salesforce consultants). - **Dot files / editor configs** — engineers rebuild tools by hand on every machine. - **Excel** — "millions of people that all build their own programs on top of it." - Social feeds as a per-user-wins example (content layer); coding agents can move this to the software layer. - Predecessors: feature flags, segmentation, A/B testing — "we've been trying to make software diverge for many years," but forced into pre-declared buckets/segments. ## Differ's Proposed Architecture - Deploy **one canonical stem**; every user runs her own **divergence** of it — same origin, individually adapted live. - Framing: "from the worst first version for everyone to the best version for anyone." - Divergences are **bounded, isolated, individually reversible**; blast radius of a change is one context; rollback needs no deploy. - Developers set **controls and boundaries** — e.g., form fields that can never be dropped; auth/payments always off-limits for adaptation. - **CRM example:** system observes an investor logging founder intros (creates an "intro path"), skipping fields (stops surfacing them), reordering deal priorities; user can also request changes, implemented without developer involvement if within boundaries and "the spirit of the software." ## Acknowledged Objections & Responses - **CTO objection (quoted roughly):** "I can already barely reason about one AI-generated code base. And you want me to run millions of these? You're not describing a capability. You're describing my worst problem multiplied." - Iris's response: the brittleness imagined is **unmanaged divergence inside a single artifact** (no boundaries, everything touching everything), not AI-generation per se. The stem-plus-bounded-divergences architecture is "the thing that this architecture exists to prevent." - She concedes the skepticism is "the right instinct, but perhaps aimed at the wrong target" — and does **not** claim it's solved via trusting AI coordination. ## Open Hard Problems (explicitly unsolved; "we have a point of view on each") 1. **Source of truth:** software = stem + all immutable divergences; lineage becomes "a graph query versus a version number"; debugging requires every divergence to be immutable, inspectable, attributable, traceable to the originating signal. 2. **Correctness:** testing must reason about the stem *and* every possible divergence. 3. **Desirability:** a change can be correct but undesirable; must measure uplift against goals (retention, churn, support tickets) — goals differ per software. 4. **Autonomy vs. control:** conservative answer (recommendations only, no autonomous changes) is "not a wrong strategy," but not Differ's vision — the vision is a system trusted enough to act without permission; "the challenge isn't building more control. It's winning enough trust that you don't have to." 5. **Coordination:** propagating updates to a million versions; tentative answer: **"don't merge code, merge intent, merge outcome"** — converge on the same goal through different paths. - Explicit concession: code generation is "the easy 80%"; observability, validation, coordination, provenance "is the entire business." ## Historical Analogy (Closing) - Fintech: "a bank with no branches sounded reckless. A decade later, the branch is the weird part." - Noam "used to fight with engineers about why you need builds and CI." - Framing of the shift: "It doesn't feel obvious until it does." - Final claim: next 20 years are about "shipping the right version to anyone with the isolation and provenance that makes it safe instead of terrifying." ## Qualifications Preserved - Iris acknowledges her fintech background makes her sympathetic to reservations ("I've had them myself as well"). - Multiple challenges are stated as **unsolved works-in-progress**, not settled capabilities. - The autonomy-vs-control answer is framed as a *vision*, with the conservative alternative acknowledged as valid. # Video Attribution & Provenance Record ## Video - **Title:** The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing - **ID:** `01a15ca8-d450-771e-82ee-38630eb80531` ## Speakers & Roles - **Iris ten Teije** — **Primary speaker / presenter** (identified in transcript: "I'm Iris. I'm one of the co-founders of Differ"). Role: **creator/co-founder** of Differ, presenting a talk on adaptive software. - Self-described background: decade in fintech; early at a digital bank that "we scaled and exited." - **Noam** — **Referenced third party (not speaking).** Identified in transcript as co-founder of Differ and "the first engineer at JFrog." Claims about him come from Iris. - **Unnamed CTO** — **Referenced third party (not speaking).** Quoted from a call Iris had; quoted objection about AI-generated code bases. Attribution: Iris's account. - **Audience** — Addressed non-speaking ("nod at your screen"), indicating an online talk format. ## Referenced Sources & Claims - **Salesforce** — cited as an example of enterprise professional services / consultant customization. - **Excel** — cited as "the most successful business software ever created" (speaker's characterization). - **Social feed personalization** — cited as an example where per-user beats one-size-fits-all (speaker's claim, "content versus software"). - **Predecessor practices cited:** feature flags, segmentation, A/B testing, dotfiles/editor configs. - **Fintech / digital bank** — Iris's personal career history; no company named. - **JFrog** — prior employer of Noam, per Iris. ## Promotional Segments - **Flagged as promotional:** Significant portions of the talk present **Differ's product vision and architecture** ("the shape that we bet on at Differ," stem-plus-divergences, examples of adaptive CRM/forms, "this is Differ and that's what we're building"). These are founder claims about their own company's approach, not neutral analysis. ## Availability & Metadata Limits - **Curated metadata:** None supplied beyond title and transcript. - **Comment availability:** Not stated; unknown. - **Channel/publisher, date, duration:** Not present in source material. - **No timestamps** available in transcript. ## Uncertainty Notes - Speaker's full surname appears only in the title ("Iris ten Teije"); transcript itself says only "Iris." - All claims about Noam, the CTO quote, and company history are **secondhand via the presenter** and could not be independently verified from the source material. As we're online today, you can't raise your hands, but just nod at your screen. How many of you have spent a significant part of your career making making software move from one computer to another? CI pipelines, packagers, registries, container images, app store reviews. That entire stack exists to solve exactly one problem. Get a frozen artifact, that code, from machine where it was built to the machine where it runs, safely, reproducibly, once. And here's what I think everyone is missing. That entire stack is built around one idea that is so old that is so old that we stopped seeing it as a choice. One version of your software for everyone. We've shipped it that way for so long that almost nobody asks why anymore. I'm Iris. I'm one of the co-founders of Differ. My co-founder Noam was the first engineer at JFrog. He helped build the pipeline that I'm about to tell you is dying. I came at it from the other end. I spent a decade in fintech. I was early at a digital bank that we scaled and exited. Shipping software in the environments least willing to tolerate what I'm about to propose. So, I totally get any reservations and I've had them myself as well. However, I'm telling you it's coming anyway. And that's not a warning. It's the best thing that's happened to software in a long time. Every piece of distribution infrastructure that you've touched encodes the same assumption. Software is produced in one place. It runs in another. Anything in the middle, the artifact, is frozen. And that assumption was correct. For decades, it was just true. Why? Because producing a correct change was expensive. It took skilled humans hours or days. So, you did it rarely. It was a central event. You verified it and froze it. And you shipped that frozen thing to everyone. So, the one-way pipeline is not arbitrary. It's the direct consequence of production of software being expensive and risky. And of course, the frozen artifact has some advantages. You get reproducibility, previewability, rollback. And every guarantee that we lean on in production flows from one fact. There is one artifact and it doesn't change after we ship it. That's the deal. One version for everyone, frozen. We call it reliability. But the price was that the software couldn't really be for anyone in particular. And nobody ever made that decision. There was never a meeting where someone put one version for everyone versus a version for each person and picked the first one. And it wasn't because the second option if a version for each person was worse. It just wasn't an option. Giving to users different software meant forking the code base and hand maintaining both. A version per user at any real scale wasn't really a viable option. And one version for everyone never had to win an argument. It was just how it was. It was the only shape software could take. And we started treating it as a fact about software like gravity, like something that that is just true. But it was never really a fact about software. It was a fact about cost and budget and the economics and that cost just changed. Now, you might you might expect me to go into AI 10 code, but everyone has already said it and that's stable stakes and to me that's not really the interesting part. The interesting part is where and how cheap The cost of producing a correct and scope change is collapsing towards zero and just as importantly the production of the software no longer has to happen in one place up front before anyone runs it. Part of it can be run on the server, part of it on the client, part in the user's live session. And as each step stops being a decision you freeze at build time and and now starts becoming more of a real-time one that also means that each each each piece can be placed wherever it makes most sense including right in front of the user in their context. And so this whole one-way pipeline existed because making software was the expensive, central, and rare event and running it was cheap. So you separated development from distribution. But now as making a change becomes as cheap as running one and it can happen in the same place as um as where you run it, the reason to separate them is dissolving. So far I've talked about the supply side. Producing code has become cheap easy. We can now make a change on a per user basis. But I also want to address the demand side. People have always wanted software that fits them and we have decades of proof for that. It just wasn't really possible for most types of software because of cost. To start with one example, the forward deployed engineer. Enterprise software has always had a line item called professional services and a whole industry exists around that. If you are a big client of a company like Salesforce, you probably have consultants that are helping you implement custom setups, configurations. You have an engineer living in your Slack channel, and it's not that smaller customers can't benefit from this type of customization. It just didn't make sense financially until today. To give another example that might resonate with you as engineers, think about your dot files, your editor config, key bindings. You rebuild every tool you touch into your tool by hand on every machine. It's another example of a demand for personalized software. And lastly, Excel, the most successful business software ever created. And Excel isn't really a static program. It's millions of people that all build their own programs on top of it. So, that's where. Give people the power to make software to make their software theirs, and they take it. Seen in the social feed that per user wins on wins from one size fits all on every metric that mattered. This is more of an example of content versus software. But now that we have uh better coding again now we have coding agents and better coding agents, we can move this also to the software layer. So, my point is none of this is really new demand. We've seen it for decades. There have been predecessors like feature flags, segmentation, AB testing. There's an enormous industry around uh uh around this, and we've been trying to make software diverge for many years. But we go forced into a specific shape, that of creating buckets and segments that you declare in advance. And now, for the first time, we can make software truly adaptive. So, to get back to the title of this talk, when the agent is the runtime, when the thing that runs your software can also modify it, development and distribution stop being two phases. The boundary blurs and it's gone. And the shape that we bet on at Differ is that instead of one code base gated by flags and shipped to everyone, you deploy one canonical stem and every user runs her own divergence of it. Same origin, but individually adapted live. It's going from the least first version for everyone to the best version for anyone. Now, if you're any of such a person, you might be a little worried. Your stomach might be turning because I have just deleted the frozen artifact and the frozen artifact was what was holding up the entire the the entire building. And I do we do get these objections, for example, from a call that I had with a CTO recently who is right to be skeptical. What he said roughly was, "I can already barely reason about one AI-generated code base. And you want me to run millions of these? You're not describing a capability. You're describing my worst problem multiplied." And if that's your reaction, that's not surprising. It's the right instinct, but perhaps aimed at the wrong target. Here's the distinction that we make. The brittleness that you're picturing is a specific type of failure mode. It's unmanaged divergence inside a single artifact. Thousand-line files, everything can touch everything else, no boundaries. And that's not not that's not necessarily brittle because it's AI-generated. It's brittle because there's no structure separating things. In our In our vision, we've we're thinking about per-user divergences. And don't write that is the opposite of that. You've got a stem plus divergences. The divergences are bounded, isolated, and individually reversible. A bad variant can silently corrupt the stem or reach another user. Which means that the blast radius of a changes in the system is one context. And any single divergence can roll back life with no deploy. So, the answer to the previous objection isn't trust us, AI is good at coordination or coding. The honest answer is you're brittle because there's a tangled artifact with no boundaries. In our case, we don't ship you a thousand single artifacts. We ship one stem and bounded divergences. Each isolated, each reversible. The thing that you're afraid of is the thing that this architecture exists to prevent. And as a developer, you can also set controls and boundaries. What can and cannot be adapted. To give a small example, um we can have a scenario where we've got a form and the form can be adapted in order to improve conversion rate, for example. However, as a developer, you can always indicate that specific fields can never be dropped or parts of your app, like off or payments, should always be out of um uh uh should always be off limits for any sort of adaptation. So, give another example to make adaptive software a bit more concrete. Uh think of, for example, um a CRM. In this case, uh we've got an investor who's using a CRM. Whereas, the CRM was mostly built with a salesperson in mind. And as an investor, you might use it slightly differently. So, this investor, she often logs founder intros, and she's always logging who intro'd her to which deal. So, the system observes that and creates a um create creates a intro path. The system can also observe that she's always skipping specific fields. She never fills them out. So, over time, the system learns and doesn't surface those fields, but instead it surfaces fields that she that she cares about more. Another example can be the fact that she is always um always checking specific types of deals or founders, and it doesn't exactly follow the prioritization that the system sets by default. So, again, can can we learn and make that smarter so that the information that the user cares about is surfaced first. Not only can a system observe, but there is also that the user can proactively request changes, and as long as these changes are within the boundaries that the developer sets, and as long as they are within the spirit of the software, within the purpose of what the software was originally made for, it can be implemented without having to go back to the developer. So, you can imagine for a for a horizontal SaaS like a CRM, you can address a much wider number of customer personas without increasing your R&D spend. Now, of course, there is there are many hard parts when it comes to bringing this to life. And I'm going to discuss a couple of hard challenges and problem and problems that we're uh that we're working on as we're making adaptive software real at scale. We haven't solved all of them, but we have a we have a point of view on each of them, and it's that it's exactly what we're working on day in, day out. So, what changes when there's no single artifact? Firstly, the source of truth. So, what when there's no single artifact, you can wonder what is the software? In our case, we consider the software to be the stem plus the plus all the mutual immutable divergences. But of course, that creates a lineage problem. What is this user running and why? That now becomes more of a graph query versus a version number. A bug report describes a program that exists for that specific user. How do you debug or inspect that? The answer is every divergence is immutable, inspectable, attributable. And we also need to trace any version back to the signal that to this specific recommendation and this exact adaptation. That's one of the parts that we're working on. Second is correctness. Like how do you test that's the um how do you test that the code change that you've just implemented works, that UI is correct, and yeah, testing at a much larger scale of users means that you need to reason about the stem and also every possible divergence of it. And then there's desirability because perhaps you made a code change, it's perfectly correct and working, but you also need to know that whether whether this was desirable. Was it actually a good change? Because anyone can make a code change now, but the hard part is knowing whether you actually found an improvement, an uplift. And yeah, that that is something that is extremely important to to keep track of and to measure and to consider what the goals for the company are. And this is not going to be the same for every single piece of software. In some cases, it might be retention or less churn or lowering the number of support tickets. So, it's extremely important to keep track of what are what are the goals that we're chasing with adaptive software and do the adaptations reach to improve improve improve the metrics that matter. Next is autonomy versus control. And the conservative answer here would be start with just recommendations and don't make any autonomous changes. And that's not a wrong strategy, but in our case, it's not really our vision. The vision is a system that understands the user well enough to act without asking the developer for permission every time first. So, for us, the challenge isn't building more control. It's winning enough trust that you don't have to. And it's a hard problem, but also also very interesting one. And you know, how do you make a system good enough, legible enough, reliable enough that humans in the loop choose to step back. And that's certainly what we are building towards. And lastly, coordination. Everyone on their own version, how do you push new updates? How do how do changes propagate to like a million different versions? And this is one of the challenges that we've been thinking hardest about. Yeah, and the answer that we keep coming back to is don't merge code, merge intent, merge outcome. Which means not everyone has to run the same commit or this exact same piece of code, but everyone converges on the same goal through their own path. And if it wasn't already clear, the challenges that I just addressed are the hard challenges. Generation has become easy, and I would say that's actually the easy 80%. Calling a model to write some code is something that everyone can do. The other part, observability, validation, coordination, that is the entire business. Anyone can call an LM, but the substrate is stem plus diver plus divergences, provenance, validation, that is really the hard part, and something that we're working on every single day. To close off with, when I started out in fintech, a bank with no branches sounded reckless. A decade later, the the branch is the weird part. My co-founder, Noam, used to fight with engineers about why you need builds and CI. We've seen this We've seen these shifts before, and adaptive software is the same type of shift. It doesn't feel obvious until it does. To go back to the start of the talk, the pipeline didn't fail because it didn't work anymore, but the constraint it was built for went away. The assumption underlying of that software is expensive, so we need to freeze it and ship it once. That assumption stopped being true. And when making software get as cheap as running it, the line between distribution and development isn't a line anymore. We spent 20 years getting good at shipping one version for everyone. The next 20 years are about shipping the right version to anyone with the isolation and provenance that makes it safe instead of terrifying. I'm Iris, this is different and that's what we're building. Thank you for watching.