WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=AMiyLItEtLA NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/AMiyLItEtLA.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:13.520 --> 00:00:16.680 Fighting slop with slop. s3 00:00:16.880 --> 00:00:23.280 My name is Vaibhav and I'm going to talk about something that is a little I would say maybe a little silly at first. s4 00:00:23.280 --> 00:00:26.960 I'm going to show you our team's engineering practices really quickly. s5 00:00:26.960 --> 00:00:28.720 We do no code reviews. s6 00:00:28.720 --> 00:00:31.960 We require every engineer to work on things in parallel. s7 00:00:31.960 --> 00:00:35.720 And we have no standardization on how people do AI. s8 00:00:35.720 --> 00:00:38.920 And I know immediately what almost all of you are thinking. s9 00:00:38.920 --> 00:00:41.440 We're probably a Zoomer YC startup. s10 00:00:41.440 --> 00:00:44.560 And I can guarantee you I'm clearly a millennial. s11 00:00:44.560 --> 00:00:47.960 So what do we actually do at our company without code reviews? s12 00:00:47.960 --> 00:00:52.840 Well, we built about 3 years ago we decided to build a programming language. s13 00:00:52.840 --> 00:00:55.360 That's something that has absolutely no room for slop. s14 00:00:55.360 --> 00:01:00.040 It's something that has to work every single time exactly the same way. s15 00:01:00.040 --> 00:01:05.000 It's something that you can't just change a year later or a month later because you made a bad design decision. s16 00:01:05.000 --> 00:01:06.680 You have to be correct. s17 00:01:06.680 --> 00:01:11.960 And for last 3 years we've been in an onslaught of war against slop. s18 00:01:11.960 --> 00:01:16.160 And when I first met this enemy, I went to my great mentor. s19 00:01:16.160 --> 00:01:17.520 Slop Sue. s20 00:01:17.520 --> 00:01:19.440 And he taught me something. s21 00:01:19.440 --> 00:01:23.360 To to defeat the slop, we must become the slop. s22 00:01:23.360 --> 00:01:27.760 So we began and we prepared and then we started winning. s23 00:01:27.760 --> 00:01:30.280 So when we think about it, what is slop? s24 00:01:30.280 --> 00:01:32.560 Slop is just any code you don't read. s25 00:01:32.560 --> 00:01:39.120 And whether any of you admit it or not, this is the least amount of slop that your code base will ever have. s26 00:01:39.120 --> 00:01:41.080 Cherish it. s27 00:01:41.080 --> 00:01:46.320 So we started fighting back against the slop and we started fighting back with slop. s28 00:01:46.320 --> 00:01:51.240 So how do we go ship a stable programming language with these engineering practices? s29 00:01:51.240 --> 00:01:55.000 Well, the first skirmish we ever had was a skirmish of standards. s30 00:01:55.000 --> 00:01:58.920 The hard part about hiring great engineers is you sadly can't tell them what to do. s31 00:01:58.920 --> 00:02:04.920 Some of them want to use Claude, some of them want to use Codex, some of them want want to use the latest thing that they just found on Hacker News. s32 00:02:04.920 --> 00:02:10.479 So, instead of trying to hold standards in our codebase, we did something that is an invariant. s33 00:02:10.479 --> 00:02:12.959 We built an architecture.md file. s34 00:02:12.959 --> 00:02:17.200 Instead of using Claude.md, just pick something that every model can just understand. s35 00:02:17.200 --> 00:02:24.120 This file has to be incredibly small, and it can only have things that will not change for months or for years. s36 00:02:24.120 --> 00:02:26.560 In our case, it's the layers of the compiler. s37 00:02:26.560 --> 00:02:31.120 You go deeper into the compiler, tell the agent to just talk to at least one other person. s38 00:02:31.120 --> 00:02:33.160 That slows it down a little bit. s39 00:02:33.160 --> 00:02:36.400 So, now we have standards, so anyone can use whatever they want. s40 00:02:36.400 --> 00:02:40.160 But, the real foe we faced was actually the battle of design. s41 00:02:40.160 --> 00:02:43.360 Everyone here knows that you have to write perfect design docs. s42 00:02:43.360 --> 00:02:46.120 And we have a very simple rule in our team. s43 00:02:46.120 --> 00:02:48.360 Code can be slop, writing cannot. s44 00:02:48.360 --> 00:02:52.840 And of course, if I tell every engineer this, they write beautiful writing, and they handwrite everything, they don't use AI. s45 00:02:52.840 --> 00:02:54.360 Well, sadly not. s46 00:02:54.360 --> 00:02:56.720 So, we built a design tool design doc tool. s47 00:02:56.720 --> 00:03:01.480 What this design doc tool does, it's a replacement for both Notion and GitHub effectively for design docs. s48 00:03:01.480 --> 00:03:03.920 It will have versioning, commenting, all the stuff you want. s49 00:03:03.920 --> 00:03:05.480 And obviously, we do this, people use this. s50 00:03:05.480 --> 00:03:06.800 Well, sadly not. s51 00:03:06.800 --> 00:03:09.040 We built another tool on top of that. s52 00:03:09.040 --> 00:03:11.239 And this tool was a Slack integration for that tool. s53 00:03:11.239 --> 00:03:15.080 Every time a design doc got updated, this channel got notifications. s54 00:03:15.080 --> 00:03:18.600 And what ended up happening is this channel became the most popular channel in our company really fast. s55 00:03:18.600 --> 00:03:23.200 At 2:00 a.m., someone shipped a new design doc, three people started reading it right away cuz it's just interesting. s56 00:03:23.200 --> 00:03:27.120 Then, most interesting stuff is design docs that are not going to change. s57 00:03:27.120 --> 00:03:28.640 But, this wasn't enough. s58 00:03:28.640 --> 00:03:35.000 All of this is actually backed by Markdown files and simple CLI scripts that make it treat like GitHub without being GitHub itself. s59 00:03:35.000 --> 00:03:37.239 So, now agents can go do this. s60 00:03:37.239 --> 00:03:48.000 But, the real problem with all this is I built this, and I hit a little bit of AI psychosis, and I started shipping 10 design docs a day, and soon the team was fighting my slop. s61 00:03:48.000 --> 00:03:49.880 So, we had to go and back at the last rule. s62 00:03:49.880 --> 00:03:54.560 This last rule was, if you're going to ship a design doc, you require people to actually go read it. s63 00:03:54.560 --> 00:04:00.080 And with this last standard, we suddenly had design docs that were incredibly high quality. s64 00:04:00.480 --> 00:04:02.440 But what about the battle of architecture? s65 00:04:02.440 --> 00:04:04.120 You how do you have your code base converge? s66 00:04:04.120 --> 00:04:05.000 We built another tool. s67 00:04:05.000 --> 00:04:11.880 This tool basically visualizes our dependency graph internally with some external dependencies as well, and allows us to watch the code base change. s68 00:04:11.880 --> 00:04:20.880 It has semantic boundaries, individual packages, but what's more interesting is we can go build CLI tools that guarantee that certain invariants can't be broken. s69 00:04:20.880 --> 00:04:31.280 And what this does is when Claude builds a new package or adds a dependency that's leaky, we now have CI/CD changing or a simple Git commit history that tells us exactly where things break. s70 00:04:31.280 --> 00:04:33.800 And by this, we're actually able to make our architecture change. s71 00:04:33.800 --> 00:04:37.680 We haven't changed our architecture in the last three or four months. s72 00:04:38.440 --> 00:04:45.200 But as much as we might do design docs, and as much as we might have stable code, would you genuinely ship code without reading it? s73 00:04:45.200 --> 00:04:47.480 Would you trust your team to go do that? s74 00:04:47.480 --> 00:04:49.320 And think about a programming language. s75 00:04:49.320 --> 00:04:51.880 A programming language just so many invariants. s76 00:04:51.880 --> 00:04:57.120 You have generics, you have closures, you have memory allocation, you have FFI boundaries. s77 00:04:57.120 --> 00:04:58.880 Could you trust that system? s78 00:04:58.880 --> 00:05:01.880 Python has bugs 25 years later. s79 00:05:01.880 --> 00:05:05.480 Well, here's where we did something slightly different. s80 00:05:05.480 --> 00:05:12.720 What we did was we built a system that actually has agents constantly running and creating BAML programs. s81 00:05:12.720 --> 00:05:15.320 We take these BAML programs. s82 00:05:15.320 --> 00:05:17.280 1 second. s83 00:05:17.280 --> 00:05:19.880 And we have agents try and spin something up from scratch. s84 00:05:19.880 --> 00:05:25.919 We then look at the entire Claude transcript, see what tools it used, see what happened, and obviously we as humans can inspect them. s85 00:05:25.919 --> 00:05:29.080 But more importantly, we can have agents go inspect them. s86 00:05:29.080 --> 00:05:31.919 And agents find what was good, what was bad. s87 00:05:31.919 --> 00:05:39.040 And not just what was bad in terms of what was incorrect in the language, but what took three tool calls when it should have only taken one. s88 00:05:39.040 --> 00:05:48.880 And then we can go ahead and find issues, and we can have humans collaborate with these issues to figure out which ones are real, which ones are hallucinations, which ones aren't don't have taste, as much as I hate to use that word. s89 00:05:48.880 --> 00:05:54.360 And then we can have agents go ahead and create fixes to these problems and go to address them. s90 00:05:54.360 --> 00:06:00.440 And most importantly, instead of trying to just detect these issues, we can go one step further. s91 00:06:00.440 --> 00:06:06.440 What if you could find language features and instead of guessing what was good, guessing what skill was good, you could go and AB test it. s92 00:06:06.440 --> 00:06:17.440 You could figure out which ones took less tool calls, which one took uh which one made less errors, which one produced the correct outcome and deterministically know what's going on. s93 00:06:17.440 --> 00:06:22.480 The point is you can start building data-driven systems without ever writing a single line of code. s94 00:06:22.480 --> 00:06:30.720 And the thing that really I care about the most over here is not that any one of these tools is specifically what you should go build. s95 00:06:30.720 --> 00:06:35.000 But the fact of the matter is in order to build a programming language, it wouldn't have taken eight people. s96 00:06:35.000 --> 00:06:37.760 It wouldn't have taken less than two years. s97 00:06:37.760 --> 00:06:43.880 It would have taken hundreds and thousands and tens of thousands of man-hours and then you would still have a broken system. s98 00:06:43.880 --> 00:06:46.520 And today we can just spend millions of tokens and make it work. s99 00:06:46.520 --> 00:06:48.280 And we can make it stable. s100 00:06:48.280 --> 00:06:58.760 And you could you two can go home and build these internal tools and these sloppy tools to make sure that your code bases can ship without really having to read necessarily every single line of code. s101 00:06:58.760 --> 00:07:01.880 Cuz your engineers aren't going to. s102 00:07:01.880 --> 00:07:04.400 And I think we can start winning this battle against slop. s103 00:07:04.400 --> 00:07:07.600 And as we win this battle, slop can be defeated. s104 00:07:07.600 --> 00:07:10.720 But sadly, I have a sad thing to say. s105 00:07:10.720 --> 00:07:13.200 I think we're still going to lose the war. s106 00:07:13.200 --> 00:07:22.560 I think the reason that we're going to lose this war is because some of the foundational stuff that we try and go use itself is broken. s107 00:07:22.560 --> 00:07:25.280 How many of you have used TypeScript? s108 00:07:25.760 --> 00:07:30.400 Probably most of you hopefully at this point or at least your agents have, so something around there. s109 00:07:30.400 --> 00:07:36.960 Um did you know that TypeScript's main design goal is to strike a balance between correctness and productivity? s110 00:07:36.960 --> 00:07:41.560 And there's an asterisk here because what they really mean is human productivity. s111 00:07:41.560 --> 00:07:50.840 And if you think about it, there are things you would never do in a programming language at the very core layer if you were designing for in a world where humans never wrote a single line of code. s112 00:07:50.840 --> 00:07:53.920 Let me show you what that really means. s113 00:07:56.280 --> 00:08:00.480 I'm going to write something and try and guess what this code does. s114 00:08:01.240 --> 00:08:03.440 Pretty safe. s115 00:08:05.200 --> 00:08:07.680 What about this one? s116 00:08:08.400 --> 00:08:11.200 Or even more so, this one. s117 00:08:11.200 --> 00:08:14.400 Why do we turn things to strings when we sort them? s118 00:08:14.400 --> 00:08:19.800 This is just slop baked into the language, whether you like it or not. s119 00:08:19.800 --> 00:08:21.800 What about this? s120 00:08:21.800 --> 00:08:24.080 I love this part of TypeScript. s121 00:08:24.080 --> 00:08:26.240 And you know what my agent loves? s122 00:08:26.240 --> 00:08:28.800 This part of TypeScript. s123 00:08:30.400 --> 00:08:33.400 This is slop baked into the language. s124 00:08:33.400 --> 00:08:39.919 And whether you like it or not, the systems will have slop if you build using these tools. s125 00:08:39.919 --> 00:08:42.320 Oh, I'm sorry, wrong talk. s126 00:08:42.320 --> 00:08:54.680 But, if you think about what JavaScript does, JavaScript exists, and then after JavaScript existed, we started building systems to layer it on. s127 00:08:54.680 --> 00:08:58.680 We built CoffeeScript, then TypeScript, and now we're trying to build a fact. s128 00:08:58.680 --> 00:09:01.760 But thing is, the thing underneath is already broken. s129 00:09:01.760 --> 00:09:06.480 And more so, the way we write code is also different now. s130 00:09:06.480 --> 00:09:08.160 So, why are we trying to patch something like this? s131 00:09:08.160 --> 00:09:10.839 Why don't we just try and do something a little different? s132 00:09:10.839 --> 00:09:16.720 And I think what we might need if we try and go do that is basically going to be a made-up language. s133 00:09:16.720 --> 00:09:19.200 So, let me show you what BAML really can do. s134 00:09:19.200 --> 00:09:26.800 And when you start thinking from first principles, how you can try and combat slop from the very foundational layer itself. s135 00:09:26.800 --> 00:09:29.480 I keep talking about not reading code. s136 00:09:29.480 --> 00:09:31.440 Does it even matter? s137 00:09:31.440 --> 00:09:33.800 Well, let me show you a new way to think about code. s138 00:09:33.800 --> 00:09:37.200 And this isn't to say we all have to go do this right away. s139 00:09:37.200 --> 00:09:42.680 But, what if every single time I look at code, whoops. s140 00:09:47.160 --> 00:09:58.160 What if every single time I look at code, what I really saw was not the code itself, but a quick little thing that could actually visualize all the code for me. s141 00:09:58.160 --> 00:10:01.840 As I clicked around, it took me to exact lines of code that was linked to. s142 00:10:01.840 --> 00:10:07.240 If I wanted to have a slightly broader view, I could zoom in and click around and have it expand. s143 00:10:07.240 --> 00:10:10.040 I could navigate my code bases more interestingly. s144 00:10:10.040 --> 00:10:14.800 I'm going to let this run really quickly, but while it runs, I'll show you a different pipeline. s145 00:10:14.800 --> 00:10:19.680 Without any of you ever reading the code, you know I'm setting up stuff and I have an agent loop because the semantic boundaries in there. s146 00:10:19.680 --> 00:10:21.320 I can expand this. s147 00:10:21.320 --> 00:10:23.880 I can keep expanding this and I can say, "Nope, that's too much slop. s148 00:10:23.880 --> 00:10:25.160 Let's let that be slop." s149 00:10:25.160 --> 00:10:26.840 And walk away. s150 00:10:26.840 --> 00:10:34.600 So, instead of having to understand all the code, I can opt into what parts of the code I want to read and understand and go to the exact lines when I really care about them. s151 00:10:34.600 --> 00:10:40.960 But, if we go back to the previous pipeline that was running, what if while it's running, I can actually get a full execution trace? s152 00:10:40.960 --> 00:10:46.920 In a world where we don't read all the code, the only way to understand the code is actually by the execution trace. s153 00:10:46.920 --> 00:10:52.560 And actually by seeing exactly how much time was spent on what parts of my program at any given time. s154 00:10:52.560 --> 00:10:59.600 If you want to go and actually track your program through, think about how slow your program would be if you have to go trace everything in Python or TypeScript. s155 00:10:59.600 --> 00:11:01.720 It's untenable. s156 00:11:01.720 --> 00:11:07.920 And the best part here is if you start from first principles, you can make this effectively zero performance cost. s157 00:11:07.920 --> 00:11:17.520 Not only can we make it great for humans, but because it's all built for agents anyway, you can go ahead and make it so that every single file has a tracing system that Claude can navigate through. s158 00:11:17.520 --> 00:11:25.200 So, Claude can find what were bugs, what were errors, and what were inefficiencies and start optimizing your code without you having to do it yourself. s159 00:11:25.200 --> 00:11:34.320 And I think if we go start thinking about it from this way, it's not so much about reading all all code, but it's more so about us human understanding the system that you're working with. s160 00:11:34.320 --> 00:11:39.800 And the tools that you can build can give you information about the system that you're working with. s161 00:11:39.800 --> 00:11:43.400 But, I think there's another layer to it. s162 00:11:43.400 --> 00:11:46.080 We've spent decades building IDE tooling. s163 00:11:46.080 --> 00:11:54.600 And that Think about how long it took before someone like me who does not know how to escape Vim to this day can finally start using VS Code. s164 00:11:54.600 --> 00:11:56.200 It was a beautiful day when that happened. s165 00:11:56.200 --> 00:11:58.240 I became a real programmer. s166 00:11:58.240 --> 00:12:02.040 Well, according to some people, I'm still not cuz I can't write Vim code. s167 00:12:02.040 --> 00:12:06.680 But, what does agent-first tooling look like? s168 00:12:07.440 --> 00:12:12.440 I think we're all familiar with grep, so I'm not going to go and talk about it. s169 00:12:12.440 --> 00:12:16.440 But, I will talk about Ripgrep cuz grep should not be used anywhere. s170 00:12:16.440 --> 00:12:25.960 If I want to grep through my code base and understand what it was, I would Ripgrep say something like calculate, and it'd give me a bunch of code where everything was being used. s171 00:12:25.960 --> 00:12:28.040 And maybe it'd be somewhat useful. s172 00:12:28.040 --> 00:12:35.120 But, what if you could instead start describing code and say, "Can you describe calculate for me?" s173 00:12:35.200 --> 00:12:37.200 What if it came with all the docstrings? s174 00:12:37.200 --> 00:12:39.560 What if it came with the actual source code? s175 00:12:39.560 --> 00:12:43.080 And what if it also told you everywhere it was actually used under the hood? s176 00:12:43.080 --> 00:12:49.080 We can make something that used to be multiple tool calls a single tool call all of a sudden. s177 00:12:49.560 --> 00:13:00.200 What if the way you want to learn about libraries that you're using, instead of having to go to a web search, you just said you did you could just ask for any external library as well. s178 00:13:00.200 --> 00:13:01.360 And it would just give it to you. s179 00:13:01.360 --> 00:13:07.400 Because when I first started learning how to code, one valuable lesson I had was the code is always the source of truth. s180 00:13:07.400 --> 00:13:09.200 Don't read anything but the code itself. s181 00:13:09.200 --> 00:13:18.160 The docs may lie, the um the actual description or architecture file or readme file will definitely lie, but the code cannot lie. s182 00:13:18.160 --> 00:13:21.240 Except if you're working on some weird architectures. s183 00:13:21.240 --> 00:13:25.800 And then when you go down this road, you go from not reading the code to understand the architecture. s184 00:13:25.800 --> 00:13:30.320 You go from not searching the code to understanding exactly what you're getting in every one tool call. s185 00:13:30.320 --> 00:13:32.280 But, what's the next thing you do? s186 00:13:32.280 --> 00:13:36.440 Well, the last thing I do to truly understand code is I run the code. s187 00:13:36.440 --> 00:13:47.000 So, what if every single thing you ran, every single function you ever wrote was immediately available And I'll pull this code over here. s188 00:13:47.440 --> 00:13:51.880 Was immediately available as a simple CLI command. s189 00:13:51.880 --> 00:13:56.840 So, if I run add, add becomes a CLI command that has A and B parameters attached to it. s190 00:13:56.840 --> 00:13:59.880 And I can just run it really quickly and see what happens. s191 00:13:59.880 --> 00:14:09.280 What if every single CLI tool I had could be packed into a live into CLI that's completely standalone. s192 00:14:09.560 --> 00:14:11.560 Multiply. s193 00:14:12.120 --> 00:14:17.120 That I can just run without ever having to actually execute any of the code. s194 00:14:18.600 --> 00:14:21.880 And it's now a total CLI binary that has functions just bundled in. s195 00:14:21.880 --> 00:14:26.560 Suddenly, we can build really quick tooling where agents don't have to go grep through what's happening. s196 00:14:26.560 --> 00:14:31.839 Everything is type safe, everything is deterministic, and everything is actually guessable. s197 00:14:31.839 --> 00:14:39.240 And the best part is imagine you could build on any system, and your agents don't have to worry about deployments across Windows, Mac, and Linux. s198 00:14:39.240 --> 00:14:45.280 And you can just target any layer you want, and it builds for any architecture, including WASM systems. s199 00:14:45.280 --> 00:14:47.920 All of a sudden, as an engineer, you're super charged. s200 00:14:47.920 --> 00:14:51.360 You're no longer bottlenecked by what you can do in the systems underneath you are preventing. s201 00:14:51.360 --> 00:14:53.160 You can just move very fast. s202 00:14:53.160 --> 00:14:56.440 You can move at agent speed. s203 00:14:56.880 --> 00:15:01.320 But, a lot of the stuff that I've been talking about to this date has been about tooling. s204 00:15:01.320 --> 00:15:04.120 What if we try to fix some of the real sins of JavaScript? s205 00:15:04.120 --> 00:15:07.839 Some of the stuff that is deep in the language. s206 00:15:07.839 --> 00:15:12.640 Not the sort stuff, but I mean more important stuff, like errors. s207 00:15:12.640 --> 00:15:17.080 Have you seen error handling be beautiful ever, other than Rust? s208 00:15:17.080 --> 00:15:23.880 Um what I see agents do over here is you do try catch, and then they keep nesting try catch after try catch after try catch. s209 00:15:23.880 --> 00:15:28.160 And eventually they give up and say console.log some error happened and deal with it. s210 00:15:28.160 --> 00:15:30.840 What if we could do error handling from very first principles? s211 00:15:30.840 --> 00:15:34.000 What happens in that world? s212 00:15:34.600 --> 00:15:37.240 Well, I showed you add, multiply, subtract. s213 00:15:37.240 --> 00:15:38.800 I didn't show you divide. s214 00:15:38.800 --> 00:15:40.080 Divide is dangerous. s215 00:15:40.080 --> 00:15:42.280 It's spooky. s216 00:15:42.360 --> 00:15:44.360 So, let's go look at divide. s217 00:15:44.360 --> 00:15:49.400 You can see over here, divide throws a division by zero error. s218 00:15:49.400 --> 00:15:51.000 But, what else happens? s219 00:15:51.000 --> 00:15:55.040 The function actually knows that it throws division by zero error. s220 00:15:55.040 --> 00:15:57.680 Without you having to write any any code. s221 00:15:57.680 --> 00:16:06.800 If I go up to the calculate function, which at some point calls divide, this function also knows it throws division by zero error. s222 00:16:06.800 --> 00:16:10.760 So, error types now get inferred without you ever having to do any guesswork. s223 00:16:10.760 --> 00:16:19.160 That means if you catch or handle errors, we can do exhaustive guarantees, and the compiler can prove that you have handled the error or not handled the error. s224 00:16:19.160 --> 00:16:20.480 It's no more guessing. s225 00:16:20.480 --> 00:16:21.640 There's no unknowns. s226 00:16:21.640 --> 00:16:23.840 It's guaranteed to be proven. s227 00:16:23.840 --> 00:16:32.839 So, if you wanted to ship an API where it guarantees that it never throws, well, this system is broken because it doesn't meet the constraints. s228 00:16:32.839 --> 00:16:35.720 It has two errors that you're not throwing. s229 00:16:35.720 --> 00:16:41.600 If you wanted to go catch that, well, I can write the code for that in a second. s230 00:16:41.600 --> 00:16:44.839 But, you can start catching certain errors. s231 00:16:49.480 --> 00:16:53.280 Uh I mean, I'm just going to return a sentinel value for now. s232 00:16:53.280 --> 00:17:06.199 And now this parse thing, which previously threw division by zero error, is now guaranteed to no longer throw the division by zero error because if I catch any exceptions in here, I return a zero value every single time. s233 00:17:06.199 --> 00:17:08.720 The compiler and the tooling can do a lot of work for us. s234 00:17:08.720 --> 00:17:11.079 And we're already used to this in our codebases. s235 00:17:11.079 --> 00:17:15.000 We many of us probably don't know how compilers work under the hood, and we trust them. s236 00:17:15.000 --> 00:17:16.959 Code is a matter of trust. s237 00:17:16.959 --> 00:17:26.720 The reason that we don't use ML code blindly is because we don't trust it yet, cuz the systems underneath them don't have enough rigidity. s238 00:17:27.319 --> 00:17:28.840 One more thing. s239 00:17:28.840 --> 00:17:38.120 But before I tell you all to go write a bunch of ML code, cuz I've been there and I can tell you what someone tell me if I said, "Hey, use this new programming language. s240 00:17:38.120 --> 00:17:39.880 It's going to solve all your problems." s241 00:17:39.880 --> 00:17:44.120 It's just going to become come with a whole slew of new problems. s242 00:17:44.120 --> 00:17:51.640 So, we said, "I think we'll lose the war on slop if we try to ask everyone to rewrite all their code in the world into this new system." s243 00:17:51.640 --> 00:17:56.440 So, what does a solution like that look like where you don't have to rewrite all your code? s244 00:17:56.440 --> 00:18:02.240 Well, we What we started to do was we started to think about that about 2 years ago. s245 00:18:02.240 --> 00:18:10.600 And we said, "What if you could use ML not just stand-alone like I showed today, but from within any existing language of your choice? s246 00:18:10.600 --> 00:18:17.360 From Python to TypeScript to Rust to Go to Ruby to Java to anything new that comes up even after it." s247 00:18:17.360 --> 00:18:22.360 What if every function in ML is immediately accessible in the language of your choice? s248 00:18:22.360 --> 00:18:28.480 So, in this case, I'm calling the ML calculate function directly from Python, and it's completely type safe. s249 00:18:28.480 --> 00:18:32.920 Not only do we get calculate, we get calculate async in case some of us want to write async code. s250 00:18:32.920 --> 00:18:39.600 So, ML while it has no function coloring, it does give you the benefit of having to do whatever you want across your code. s251 00:18:39.600 --> 00:18:44.080 But what if you went a little bit sillier? s252 00:18:44.080 --> 00:18:49.520 What if you started passing around lambdas across language boundaries? s253 00:18:49.520 --> 00:18:51.520 I have a function here called with timeout. s254 00:18:51.520 --> 00:18:56.880 This function times out after a certain number of milliseconds, and if this work doesn't complete. s255 00:18:56.880 --> 00:19:00.120 And it's guaranteed to no matter how long it takes. s256 00:19:00.120 --> 00:19:03.880 Well, in that world, you can even pass Python lambdas across the bridge. s257 00:19:03.880 --> 00:19:05.720 You can pass generics across the bridge. s258 00:19:05.720 --> 00:19:07.120 You can pass closures. s259 00:19:07.120 --> 00:19:10.000 It should just work, so engineers don't have to go fuss with it. s260 00:19:10.000 --> 00:19:14.560 And more importantly, so when the agent does something, the type system never lies. s261 00:19:14.560 --> 00:19:22.200 The type system becomes the absolute center of truth that prevents invariants from entering your codebase. s262 00:19:22.360 --> 00:19:27.240 And what I really wanted to talk about today was not any one specific thing. s263 00:19:27.240 --> 00:19:29.000 But it's this general concept. s264 00:19:29.000 --> 00:19:33.920 You can build incredibly complex systems without traditional systems like code reviews. s265 00:19:33.920 --> 00:19:40.040 You don't You can work in things in parallel, and you can use AI however you want without requiring any sort of standardization. s266 00:19:40.040 --> 00:19:47.560 But the most important part is you have to be incredibly thoughtful about how your engineering team actually uses the systems under the hood. s267 00:19:47.560 --> 00:19:52.000 When we started building BAML, I didn't think it would be possible to build some of the software we did. s268 00:19:52.000 --> 00:19:58.080 And just yesterday one of our engineers built a partial C compiler purely in BAML. s269 00:19:58.080 --> 00:20:08.320 So, when I start pushing the boundaries of these systems and you stop reading the code, in some ways in my mind, it releases the floodgates for your engineering team to actually cover the gaps s270 00:20:08.320 --> 00:20:10.560 of what existed in your old process. s271 00:20:10.560 --> 00:20:13.080 Have you ever worked at a company that had no CI/CD? s272 00:20:13.080 --> 00:20:15.920 They said adding CI/CD would slow us down. s273 00:20:15.920 --> 00:20:20.960 They They do slow down for 3 months while they add it, but after that, they move a lot faster. s274 00:20:20.960 --> 00:20:25.080 Our processes have to evolve if we're going to ship at agent speed. s275 00:20:25.080 --> 00:20:30.400 And remember, this is the least amount of slop your codebase will ever have to this day. s276 00:20:30.400 --> 00:20:34.240 So, just embrace it and start fighting it back. s277 00:20:34.240 --> 00:20:41.040 I fell in love with software about 15 years ago, and it was the first thing that truly changed the way I perceive the world. s278 00:20:41.040 --> 00:20:43.320 And I really genuinely don't want slop to win. s279 00:20:43.320 --> 00:20:47.160 And I think we can all build a world of beautiful software. s280 00:20:47.160 --> 00:20:51.880 And I think what it takes is I want each of you to go home today and build these sloppy tools. s281 00:20:51.880 --> 00:20:53.240 Make your systems more robust. s282 00:20:53.240 --> 00:20:55.560 Make your processes more robust. s283 00:20:55.560 --> 00:21:01.400 And then for the bravest of you, I want you to go back and think about these core foundation layer systems. s284 00:21:01.400 --> 00:21:04.640 Think about how they're broken and see if you can imagine a way to fix them. s285 00:21:04.640 --> 00:21:06.480 I think we do need a new Git. s286 00:21:06.480 --> 00:21:11.280 I think we do need a new database, and yes, I think we need a new programming language. s287 00:21:11.280 --> 00:21:13.240 I'm Vaibhav, and I work on Bemo. s288 00:21:13.240 --> 00:21:15.440 Thank you.