WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=bRnoEpoK5m4 NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/bRnoEpoK5m4.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:00.000 --> 00:00:04.160 As we're online today, you can't raise your hands, but just nod at your screen. s2 00:00:04.160 --> 00:00:12.160 How many of you have spent a significant part of your career making making software move from one computer to another? s3 00:00:12.160 --> 00:00:18.880 CI pipelines, packagers, registries, container images, app store reviews. s4 00:00:18.880 --> 00:00:23.160 That entire stack exists to solve exactly one problem. s5 00:00:23.160 --> 00:00:33.920 Get a frozen artifact, that code, from machine where it was built to the machine where it runs, safely, reproducibly, once. s6 00:00:34.040 --> 00:00:36.200 And here's what I think everyone is missing. s7 00:00:36.200 --> 00:00:42.840 That entire stack is built around one idea that is so old that is so old that we stopped seeing it as a choice. s8 00:00:42.840 --> 00:00:46.200 One version of your software for everyone. s9 00:00:46.200 --> 00:00:51.760 We've shipped it that way for so long that almost nobody asks why anymore. s10 00:00:51.760 --> 00:00:52.760 I'm Iris. s11 00:00:52.760 --> 00:00:54.960 I'm one of the co-founders of Differ. s12 00:00:54.960 --> 00:00:58.200 My co-founder Noam was the first engineer at JFrog. s13 00:00:58.200 --> 00:01:01.840 He helped build the pipeline that I'm about to tell you is dying. s14 00:01:01.840 --> 00:01:04.400 I came at it from the other end. s15 00:01:04.400 --> 00:01:06.040 I spent a decade in fintech. s16 00:01:06.040 --> 00:01:09.880 I was early at a digital bank that we scaled and exited. s17 00:01:09.880 --> 00:01:15.320 Shipping software in the environments least willing to tolerate what I'm about to propose. s18 00:01:15.320 --> 00:01:20.880 So, I totally get any reservations and I've had them myself as well. s19 00:01:20.880 --> 00:01:23.640 However, I'm telling you it's coming anyway. s20 00:01:23.640 --> 00:01:26.480 And that's not a warning. s21 00:01:26.480 --> 00:01:30.480 It's the best thing that's happened to software in a long time. s22 00:01:30.480 --> 00:01:36.200 Every piece of distribution infrastructure that you've touched encodes the same assumption. s23 00:01:36.200 --> 00:01:38.720 Software is produced in one place. s24 00:01:38.720 --> 00:01:40.560 It runs in another. s25 00:01:40.560 --> 00:01:45.320 Anything in the middle, the artifact, is frozen. s26 00:01:45.320 --> 00:01:47.640 And that assumption was correct. s27 00:01:47.640 --> 00:01:50.440 For decades, it was just true. s28 00:01:50.440 --> 00:01:52.040 Why? s29 00:01:52.040 --> 00:01:55.560 Because producing a correct change was expensive. s30 00:01:55.560 --> 00:01:58.520 It took skilled humans hours or days. s31 00:01:58.520 --> 00:01:59.560 So, you did it rarely. s32 00:01:59.560 --> 00:02:00.720 It was a central event. s33 00:02:00.720 --> 00:02:03.640 You verified it and froze it. s34 00:02:03.640 --> 00:02:06.720 And you shipped that frozen thing to everyone. s35 00:02:06.720 --> 00:02:09.119 So, the one-way pipeline is not arbitrary. s36 00:02:09.119 --> 00:02:15.800 It's the direct consequence of production of software being expensive and risky. s37 00:02:15.800 --> 00:02:19.360 And of course, the frozen artifact has some advantages. s38 00:02:19.360 --> 00:02:25.080 You get reproducibility, previewability, rollback. s39 00:02:25.080 --> 00:02:29.720 And every guarantee that we lean on in production flows from one fact. s40 00:02:29.720 --> 00:02:34.840 There is one artifact and it doesn't change after we ship it. s41 00:02:34.840 --> 00:02:35.640 That's the deal. s42 00:02:35.640 --> 00:02:39.280 One version for everyone, frozen. s43 00:02:39.280 --> 00:02:41.400 We call it reliability. s44 00:02:41.400 --> 00:02:47.200 But the price was that the software couldn't really be for anyone in particular. s45 00:02:47.200 --> 00:02:49.800 And nobody ever made that decision. s46 00:02:49.800 --> 00:02:59.239 There was never a meeting where someone put one version for everyone versus a version for each person and picked the first one. s47 00:02:59.239 --> 00:03:04.400 And it wasn't because the second option if a version for each person was worse. s48 00:03:04.400 --> 00:03:06.560 It just wasn't an option. s49 00:03:06.560 --> 00:03:12.800 Giving to users different software meant forking the code base and hand maintaining both. s50 00:03:12.800 --> 00:03:18.560 A version per user at any real scale wasn't really a viable option. s51 00:03:18.560 --> 00:03:21.239 And one version for everyone never had to win an argument. s52 00:03:21.239 --> 00:03:23.000 It was just how it was. s53 00:03:23.000 --> 00:03:25.760 It was the only shape software could take. s54 00:03:25.760 --> 00:03:32.320 And we started treating it as a fact about software like gravity, like something that that is just true. s55 00:03:32.320 --> 00:03:34.239 But it was never really a fact about software. s56 00:03:34.239 --> 00:03:40.320 It was a fact about cost and budget and the economics and that cost just changed. s57 00:03:40.320 --> 00:03:49.000 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. s58 00:03:49.000 --> 00:04:04.840 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 s59 00:04:04.840 --> 00:04:10.120 no longer has to happen in one place up front before anyone runs it. s60 00:04:10.120 --> 00:04:15.920 Part of it can be run on the server, part of it on the client, part in the user's live session. s61 00:04:15.920 --> 00:04:30.160 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 s62 00:04:30.160 --> 00:04:35.040 including right in front of the user in their context. s63 00:04:35.040 --> 00:04:44.480 And so this whole one-way pipeline existed because making software was the expensive, central, and rare event and running it was cheap. s64 00:04:44.919 --> 00:04:48.800 So you separated development from distribution. s65 00:04:48.800 --> 00:04:59.640 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 s66 00:04:59.640 --> 00:05:00.760 is dissolving. s67 00:05:00.760 --> 00:05:04.120 So far I've talked about the supply side. s68 00:05:04.120 --> 00:05:07.400 Producing code has become cheap easy. s69 00:05:07.400 --> 00:05:10.960 We can now make a change on a per user basis. s70 00:05:10.960 --> 00:05:14.360 But I also want to address the demand side. s71 00:05:14.360 --> 00:05:21.360 People have always wanted software that fits them and we have decades of proof for that. s72 00:05:21.360 --> 00:05:26.520 It just wasn't really possible for most types of software because of cost. s73 00:05:26.720 --> 00:05:30.120 To start with one example, the forward deployed engineer. s74 00:05:30.120 --> 00:05:38.400 Enterprise software has always had a line item called professional services and a whole industry exists around that. s75 00:05:38.400 --> 00:05:48.760 If you are a big client of a company like Salesforce, you probably have consultants that are helping you implement custom setups, configurations. s76 00:05:48.760 --> 00:06:00.240 You have an engineer living in your Slack channel, and it's not that smaller customers can't benefit from this type of customization. s77 00:06:00.240 --> 00:06:04.320 It just didn't make sense financially until today. s78 00:06:04.320 --> 00:06:15.000 To give another example that might resonate with you as engineers, think about your dot files, your editor config, key bindings. s79 00:06:15.640 --> 00:06:21.120 You rebuild every tool you touch into your tool by hand on every machine. s80 00:06:21.120 --> 00:06:26.320 It's another example of a demand for personalized software. s81 00:06:26.320 --> 00:06:31.480 And lastly, Excel, the most successful business software ever created. s82 00:06:31.480 --> 00:06:38.320 And Excel isn't really a static program. s83 00:06:38.320 --> 00:06:43.840 It's millions of people that all build their own programs on top of it. s84 00:06:44.560 --> 00:06:45.480 So, that's where. s85 00:06:45.480 --> 00:06:49.760 Give people the power to make software to make their software theirs, and they take it. s86 00:06:49.760 --> 00:06:58.080 Seen in the social feed that per user wins on wins from one size fits all on every metric that mattered. s87 00:06:58.080 --> 00:07:01.520 This is more of an example of content versus software. s88 00:07:01.520 --> 00:07:09.800 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. s89 00:07:09.800 --> 00:07:12.240 So, my point is none of this is really new demand. s90 00:07:12.240 --> 00:07:13.440 We've seen it for decades. s91 00:07:13.440 --> 00:07:19.560 There have been predecessors like feature flags, segmentation, AB testing. s92 00:07:19.560 --> 00:07:29.400 There's an enormous industry around uh uh around this, and we've been trying to make software diverge for many years. s93 00:07:29.400 --> 00:07:39.240 But we go forced into a specific shape, that of creating buckets and segments that you declare in advance. s94 00:07:39.400 --> 00:07:46.160 And now, for the first time, we can make software truly adaptive. s95 00:07:46.160 --> 00:07:58.520 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. s96 00:07:58.520 --> 00:08:01.760 The boundary blurs and it's gone. s97 00:08:02.120 --> 00:08:16.240 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. s98 00:08:16.240 --> 00:08:21.640 Same origin, but individually adapted live. s99 00:08:22.440 --> 00:08:29.000 It's going from the least first version for everyone to the best version for anyone. s100 00:08:31.400 --> 00:08:34.280 Now, if you're any of such a person, you might be a little worried. s101 00:08:34.280 --> 00:08:45.760 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. s102 00:08:45.760 --> 00:08:54.080 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. s103 00:08:54.080 --> 00:09:00.280 What he said roughly was, "I can already barely reason about one AI-generated code base. s104 00:09:00.280 --> 00:09:02.640 And you want me to run millions of these? s105 00:09:02.640 --> 00:09:04.240 You're not describing a capability. s106 00:09:04.240 --> 00:09:07.680 You're describing my worst problem multiplied." s107 00:09:07.680 --> 00:09:10.160 And if that's your reaction, that's not surprising. s108 00:09:10.160 --> 00:09:13.760 It's the right instinct, but perhaps aimed at the wrong target. s109 00:09:13.760 --> 00:09:15.160 Here's the distinction that we make. s110 00:09:15.160 --> 00:09:20.000 The brittleness that you're picturing is a specific type of failure mode. s111 00:09:20.000 --> 00:09:23.680 It's unmanaged divergence inside a single artifact. s112 00:09:23.680 --> 00:09:28.440 Thousand-line files, everything can touch everything else, no boundaries. s113 00:09:28.440 --> 00:09:32.960 And that's not not that's not necessarily brittle because it's AI-generated. s114 00:09:32.960 --> 00:09:38.400 It's brittle because there's no structure separating things. s115 00:09:38.520 --> 00:09:43.240 In our In our vision, we've we're thinking about per-user divergences. s116 00:09:43.240 --> 00:09:45.520 And don't write that is the opposite of that. s117 00:09:45.520 --> 00:09:47.640 You've got a stem plus divergences. s118 00:09:47.640 --> 00:09:52.040 The divergences are bounded, isolated, and individually reversible. s119 00:09:52.040 --> 00:09:56.640 A bad variant can silently corrupt the stem or reach another user. s120 00:09:56.640 --> 00:10:01.640 Which means that the blast radius of a changes in the system is one context. s121 00:10:01.640 --> 00:10:06.920 And any single divergence can roll back life with no deploy. s122 00:10:06.920 --> 00:10:13.760 So, the answer to the previous objection isn't trust us, AI is good at coordination or coding. s123 00:10:13.760 --> 00:10:22.120 The honest answer is you're brittle because there's a tangled artifact with no boundaries. s124 00:10:22.120 --> 00:10:24.880 In our case, we don't ship you a thousand single artifacts. s125 00:10:24.880 --> 00:10:27.640 We ship one stem and bounded divergences. s126 00:10:27.640 --> 00:10:30.720 Each isolated, each reversible. s127 00:10:30.720 --> 00:10:37.200 The thing that you're afraid of is the thing that this architecture exists to prevent. s128 00:10:37.200 --> 00:10:42.400 And as a developer, you can also set controls and boundaries. s129 00:10:42.400 --> 00:10:44.360 What can and cannot be adapted. s130 00:10:44.360 --> 00:10:56.400 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. s131 00:10:56.400 --> 00:11:09.440 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 s132 00:11:09.440 --> 00:11:14.200 uh uh should always be off limits for any sort of adaptation. s133 00:11:14.200 --> 00:11:20.080 So, give another example to make adaptive software a bit more concrete. s134 00:11:20.280 --> 00:11:24.360 Uh think of, for example, um a CRM. s135 00:11:24.440 --> 00:11:28.160 In this case, uh we've got an investor who's using a CRM. s136 00:11:28.160 --> 00:11:31.640 Whereas, the CRM was mostly built with a salesperson in mind. s137 00:11:31.640 --> 00:11:35.960 And as an investor, you might use it slightly differently. s138 00:11:35.960 --> 00:11:45.280 So, this investor, she often logs founder intros, and she's always logging who intro'd her to which deal. s139 00:11:45.280 --> 00:11:53.080 So, the system observes that and creates a um create creates a intro path. s140 00:11:53.080 --> 00:11:57.280 The system can also observe that she's always skipping specific fields. s141 00:11:57.280 --> 00:11:59.000 She never fills them out. s142 00:11:59.000 --> 00:12:08.600 So, over time, the system learns and doesn't surface those fields, but instead it surfaces fields that she that she cares about more. s143 00:12:10.240 --> 00:12:25.640 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 s144 00:12:25.640 --> 00:12:26.280 by default. s145 00:12:26.280 --> 00:12:34.960 So, again, can can we learn and make that smarter so that the information that the user cares about is surfaced first. s146 00:12:34.960 --> 00:12:47.800 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 s147 00:12:47.800 --> 00:12:58.080 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. s148 00:12:58.080 --> 00:13:12.800 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. s149 00:13:13.320 --> 00:13:21.120 Now, of course, there is there are many hard parts when it comes to bringing this to life. s150 00:13:21.120 --> 00:13:31.720 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. s151 00:13:31.720 --> 00:13:40.200 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. s152 00:13:40.200 --> 00:13:44.760 So, what changes when there's no single artifact? s153 00:13:44.920 --> 00:13:48.880 Firstly, the source of truth. s154 00:13:48.880 --> 00:13:54.320 So, what when there's no single artifact, you can wonder what is the software? s155 00:13:54.360 --> 00:14:01.840 In our case, we consider the software to be the stem plus the plus all the mutual immutable divergences. s156 00:14:02.400 --> 00:14:06.240 But of course, that creates a lineage problem. s157 00:14:06.240 --> 00:14:09.160 What is this user running and why? s158 00:14:09.160 --> 00:14:14.080 That now becomes more of a graph query versus a version number. s159 00:14:14.080 --> 00:14:19.920 A bug report describes a program that exists for that specific user. s160 00:14:19.920 --> 00:14:22.320 How do you debug or inspect that? s161 00:14:22.320 --> 00:14:28.120 The answer is every divergence is immutable, inspectable, attributable. s162 00:14:28.120 --> 00:14:39.839 And we also need to trace any version back to the signal that to this specific recommendation and this exact adaptation. s163 00:14:40.000 --> 00:14:44.520 That's one of the parts that we're working on. s164 00:14:44.760 --> 00:14:46.839 Second is correctness. s165 00:14:46.839 --> 00:15:01.160 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 s166 00:15:01.160 --> 00:15:08.080 of users means that you need to reason about the stem and also every possible divergence of it. s167 00:15:09.400 --> 00:15:21.720 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. s168 00:15:21.720 --> 00:15:24.280 Was it actually a good change? s169 00:15:24.280 --> 00:15:36.000 Because anyone can make a code change now, but the hard part is knowing whether you actually found an improvement, an uplift. s170 00:15:36.920 --> 00:15:45.000 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. s171 00:15:45.000 --> 00:15:48.560 And this is not going to be the same for every single piece of software. s172 00:15:48.560 --> 00:15:57.360 In some cases, it might be retention or less churn or lowering the number of support tickets. s173 00:15:57.360 --> 00:16:10.920 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. s174 00:16:11.280 --> 00:16:13.640 Next is autonomy versus control. s175 00:16:13.640 --> 00:16:23.120 And the conservative answer here would be start with just recommendations and don't make any autonomous changes. s176 00:16:23.120 --> 00:16:29.160 And that's not a wrong strategy, but in our case, it's not really our vision. s177 00:16:29.160 --> 00:16:38.120 The vision is a system that understands the user well enough to act without asking the developer for permission every time first. s178 00:16:38.120 --> 00:16:41.240 So, for us, the challenge isn't building more control. s179 00:16:41.240 --> 00:16:45.080 It's winning enough trust that you don't have to. s180 00:16:45.080 --> 00:16:49.760 And it's a hard problem, but also also very interesting one. s181 00:16:49.760 --> 00:17:00.640 And you know, how do you make a system good enough, legible enough, reliable enough that humans in the loop choose to step back. s182 00:17:00.640 --> 00:17:05.360 And that's certainly what we are building towards. s183 00:17:06.720 --> 00:17:08.199 And lastly, coordination. s184 00:17:08.199 --> 00:17:12.760 Everyone on their own version, how do you push new updates? s185 00:17:12.760 --> 00:17:17.160 How do how do changes propagate to like a million different versions? s186 00:17:17.160 --> 00:17:22.839 And this is one of the challenges that we've been thinking hardest about. s187 00:17:22.839 --> 00:17:30.800 Yeah, and the answer that we keep coming back to is don't merge code, merge intent, merge outcome. s188 00:17:30.800 --> 00:17:41.280 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. s189 00:17:41.280 --> 00:17:46.720 And if it wasn't already clear, the challenges that I just addressed are the hard challenges. s190 00:17:46.720 --> 00:17:51.000 Generation has become easy, and I would say that's actually the easy 80%. s191 00:17:51.000 --> 00:17:56.400 Calling a model to write some code is something that everyone can do. s192 00:17:56.400 --> 00:18:04.960 The other part, observability, validation, coordination, that is the entire business. s193 00:18:06.560 --> 00:18:23.520 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. s194 00:18:25.160 --> 00:18:32.240 To close off with, when I started out in fintech, a bank with no branches sounded reckless. s195 00:18:33.120 --> 00:18:38.440 A decade later, the the branch is the weird part. s196 00:18:38.440 --> 00:18:46.240 My co-founder, Noam, used to fight with engineers about why you need builds and CI. s197 00:18:47.080 --> 00:18:54.520 We've seen this We've seen these shifts before, and adaptive software is the same type of shift. s198 00:18:54.520 --> 00:18:58.520 It doesn't feel obvious until it does. s199 00:18:58.520 --> 00:19:09.960 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. s200 00:19:09.960 --> 00:19:15.920 The assumption underlying of that software is expensive, so we need to freeze it and ship it once. s201 00:19:15.920 --> 00:19:19.080 That assumption stopped being true. s202 00:19:19.680 --> 00:19:28.600 And when making software get as cheap as running it, the line between distribution and development isn't a line anymore. s203 00:19:30.160 --> 00:19:34.200 We spent 20 years getting good at shipping one version for everyone. s204 00:19:34.200 --> 00:19:43.840 The next 20 years are about shipping the right version to anyone with the isolation and provenance that makes it safe instead of terrifying. s205 00:19:43.840 --> 00:19:46.680 I'm Iris, this is different and that's what we're building. s206 00:19:46.680 --> 00:19:49.120 Thank you for watching.