chapters transcript notes
click any line to jump to that moment in the video
0:10 Hello everyone and welcome back to Agentic Thinking. We're once again discussing some more topics around AI, AI systems, how things are working. Matthias, welcome back. 0:20 It's good to see you again. Absolutely. More AI. Yeah, always great to talk more AI. We, we did a good live reaction show earlier this week. 0:30 Yes. we can take a slightly different pace and go a bit deeper into things. I hope. If you funny things, if you nerds nerding out on 0:40 nerdy stuff, go check out our other video. It's on the channel. I'll make sure I put the link here in the chat window as . And if you'd to check us out, we did a Mystery Science Theater 3000 type take on the OpenAI Dev Day announcement. 0:54 we sat down on the bottom screen, we commented, we teased, we have some fun while they're they're doing the actual event. if you find that stuff entertaining and enjoying, we, 1:04 we did throw some knowledge in there. But it is also more about our initial reactions to their product and their product updates on how they're copying the rest of the industry at this point. that's how our feel 1:15 was indeed absolutely nothing we hadn't seen under a slightly different product name elsewhere. Exactly. , in, in lieu of this, Matias, I'll throw 1:26 this one, throw this one out there as . There was a very funny. I don't know if you saw if you caught it. The OpenAI team announced these things called dots, little 1:36 agents you can go use. Already there had been an announcement made from Grok or XAI that they had Grokbots. it's a bot or it's a dot and lo and behold, 1:48 I don't know if this, Xai went out and bought the domain dot.com bought it and then when you go to dot.com 2:00 it routes you over to Grokbot and lets you see all the Grokbots. They took the domain name of dot.com away, they had it, but they bought it quick, quickly stuck a website behind 2:12 it and made a whole bunch of Grox behind it to kind of tease, I guess, open AI and copy in their name and their schema, which they look exactly the same product. Honestly, did you hear about this? 2:23 I did not. But it's hilarious and funny to me. Yeah. What happens when billionaires play with money and start, , picking at each other with their businesses? 2:33 Oh my goodness. Anyways, reminds me of the old days when Microsoft managed to get. 2:43 As their landing domain for Net. that was pretty cool. Sometimes you have to be lucky and quick in the first, ? Yes, most certainly. The link, if you want to see that whole 2:56 video is in the chat window here. I'll put that there for anyone who wants to go check it out on another time. All , let's talk about our main topic. main topic for today is Rust. 3:08 What the heck is Rust? And the reason I think we are bringing this up is if you look at the recent news article, there's a number of different platforms that are rebuilding their infrastructure solely 3:20 in this new I guess it's a programming language called Rust. GitHub Copilot runs on Rust. Bun is another program that runs on Rust. 3:31 There's a lot of conversation around that. Codex is doing a rewrite in rust, but surprisingly TypeScript 7 is not. Let's unpack this concept. Matthias, you're way better in the coding 3:42 space that I am. Let's give our audience a little bit of a run up on what the heck is Rust and why do we care about it. Compared to other things, it's a programming language relatively young. 3:54 It went 1.0 in 2015 and was originally developed by Mozilla, still remember that those days. 4:05 And it promises to give you C C performance. Without the disadvantages of hardcore C C. 4:21 And the key thing from my point of view is it allows you to produce native binaries on any system you compile for you don't have an intermediary. 4:36 Most other languages, TypeScript, JavaScript, Python, NET, Java, all of these run 4:48 on a runtime that does some type of on the fly compilation on the target machine, 5:02 which makes it very, very portable. But it obviously comes at a huge cost with respect to not getting native performance. And Rust does not have that problem. 5:14 Rust also is very strict from a static typing point of view, which is brilliant when it comes to producing huge non trivial 5:30 code bases. And I think that's the reason those two points together, the static typing strictness as as the native code combination targets you get, I think that's what makes it 5:44 particularly interesting nowadays. And obviously one of the big disadvantages a language Rust or C would have had previously. 5:55 It's quite complex and difficult for human developers. Writing stuff in Python or TypeScript is substantially easier. 6:06 But we no longer have that problem , obviously because humans don't write code anymore. And that that problem completely 6:17 goes away because you pretty much get the code writing expertise for free just by handing stuff out to agents. 6:27 But you get, you get all the other benefits. personally, , I'm producing a lot of my own projects in Rust these days. I'm really. 6:39 Oh man, I can't remember the last time I've done anything in. Net, which used to be my big thing. I know by myself, a NET developer that's out of the window. 6:54 I converted From. NET to TypeScript at some point and I'm even bigger convert to Rust. When I saw, and coming back to the topic here, when I 7:07 saw this very, very big September blog article about GitHub's Rust migration, I saw lots of common touch points there. 7:21 Let's go a little bit deeper here. Yes, I think there's some really interesting. I feel there's a couple interesting concepts that we're unpacking here. One is when I don't write code anymore, I'm not really required 7:34 to learn a particular language and stick with it anymore. . it's, it's less hard, it's less difficult for me to pick what's the best solution. 7:45 There may be some trade offs, there may be some advantages in one language or another. There always is. And how the different languages run. And you can start without requiring the years of 7:55 knowledge, of learning, all the nuances of how Rust works. You can lean on your agents because they already know how to run it. They already know how to write perfect code. In Rust, the function may not do what you want, but the 8:06 function will run every single time. There's other concepts here that I think you still have to be mindful of. We're not saying throw out languages and just pick whatever you want and go everything. With Rust, I think we're just saying 8:17 that the barrier to be able to write in any language is minimal. I was doing an experiment a number of months ago, probably about three months ago . Just build a project. 8:28 I just told the agent, hey, I want to build this project. Here's my concept, here's my idea. It was around token generation on my computer, locally on local computer code gen with large language models. 8:40 I wanted to download models, I wanted to have it run it's terminal command line interface. And I added the simple requirement, write this thing 100% in Rust. I don't want anything else built in anything 8:50 not Rust. And it said sure. And it did the whole thing. Built the binaries, I had code, I had files I could download. I was able to download the actual executable, run it 9:02 on my machine and everything ran Clockwork. there could have been things that I should have been looking at and being mindful of, but it was my experiment in can I just describe the system that I desire and then say, oh, 9:14 by the way, drop it in this type of language? And it did a good job. It didn't take it too long to noodle through what I needed to be built inside Rust. side project I put on the shelf. 9:25 I'm not playing with it , but this is, I think, the ease of what we're doing here. let's unpack. Is there Anything in the GitHub article? I'll put the GitHub article here in the chat window, which 9:36 by the way, is a gigantic article. Huge. Give yourself some quiet space and some time to read it or give it to your agent and tell it to summarize it. 9:47 Interesting. If you look into the header of the article at the top, it says 65 minutes reading time. Oh, wow. Yeah, it's a bit of a, a mind bender. 9:59 we're definitely not going to recite it back to you . Absolutely not. But maybe we can pick out a couple things. Is there anything that specifically Matisse, that stood out to you that you maybe would highlight in here around, , part of this 10:11 process? number one, absolutely. How deep and comprehensive this article is and 10:22 into how much detail they've gone here to explain what they've done. The article is about the GitHub copilot runtime, which is not open 10:34 source, it's quite interesting. they're talking about a project that no one outside of GitHub will ever see in terms of what's 10:44 come out of it. you can't really test anything they're claiming here. You can't check that it's not an open source project. 10:56 It also appears as if the human involvement in that conversion project was very, very limited. the author, Stephen, appears to have run 11:11 the whole project more or less on his own. And then he gives credit to a handful of people who made some contributions. Everything else seems to have been agent driven, including I 11:23 think somewhere, if I don't, if I'm remember correctly, I, I, I have. 11:33 Yeah, there we go. 830,000 lines of, of, of Rust code came out of it. Yeah, yeah. Plus almost half a million lines of Rust unit. 11:46 we're talking, , a pretty very, very substantial project in terms of quantity. And 11:57 it's been going on, according to the article since May. And they give, , all the reasons why they've done that 12:10 and obviously one of the main drivers, they've come from a TypeScript code base and one of the main drivers really was that they 12:23 wanted the Copilot engine to be as portable as possible, but also as performant as possible and they want to be able to embed 12:35 it into all kinds of other products. And that embedding story in particular, if you, if you were relying on a TypeScript code base, would require for you to have 12:46 some node or JavaScript runtime embedded there, which is obviously not ideal. Ideal, if you're thinking, I don't know, Excel or desktop 12:56 or stuff that. , yes. being able to compile into native code, as I explained in the beginning, , makes a massive difference in addition to 13:07 all the performance benefits you're going to get from that. Interesting. Yeah, this is really neat because this is. I'm going to project a little bit here. This is totally speculation at this point. . This step needs to happen before the announcement of the 13:23 new unified co pilot experience that Microsoft is touting. And , the, the term co pilot is I think 13:33 very overweighted just in general. . I go to Microsoft 365. I hear the word copilot, I go to fabric, I hear the word copilot, I hear GitHub and I hear the word copilot. While these are the same words, Matthias, you 13:46 and I know behind the scenes, the bits that run each of those in portable places, they're all different. It's all different fractured code bases. 13:56 I liken the analogy. For those of you who are in the data science or the Power BI world, it's Power Query. Power Query has three different layers of bits . One layer of bits is in Excel, one layer of bits is 14:08 in Power BI Desktop. Another layer of bits is in power bi.com they all have. It's the same product. You still say Power Query in all instances, but they all are 14:18 slightly, a little bit different. Some of them have had newer updates, some of them have not. I think this is maybe an attempt to say, look, that we have this ultra portable framework that 14:32 has been rebuilt off of TypeScript, we've removed some dependencies. It's a self compiled binary. We can just lift it everywhere we want. To me this feels a precursor to hey, let's announce a 14:44 unified copilot experience where we're using all the best things that came from GitHub Copilot and we're putting it anywhere in the Organization. This feels it fits with the story, the broader story of 14:58 build once, reuse everywhere. And I think this is what we're going to continue to see is I even see it in my own software . Everything I'm thinking about and maybe a part of this article that's, that's pulled out here that I think is important 15:10 is one, there's a human role to software development, ? The architecture tests, how do you migrate? 15:20 When do you tell agents to stop doing something and start doing something else? The direction piece here, that still is paramount in what they're doing with this rust rebuild. 15:31 And that human role, I believe, is what I'm using more in my software. I'm looking more comprehensively across multiple products, multiple pieces, 15:41 and saying, I think I see the same thing being used multiple times. For example, my ui, I build lots of workloads in fabric, I build apps and websites. But I want all of it to 15:52 feel the same. I want to look the same. I'm stopping building the individual product. And I'm starting to say, , agents, I need you to help think with me. How do I build reusable components of things as 16:04 I build software that I'm having fun with? Some of them need to have paywalls. you can build one piece of software with a paywall in it, but what do you need to have that paywall reused in 16:16 other pieces of software? There's a lot of common structural pieces that you want to reuse or build or enhance that, , today my paywall uses Venmo. , maybe I want to add to 16:29 that PayPal or add to that something new, or maybe Xpay is going to be one you're going to want. I don't know, who knows what the future holds, but I need a package in which I could leverage paywalls across multiple parts 16:42 of products. my paywall that I'm building on the side is a mix of crypto payments. you can go buy your things with Solana and you can use your wallet to pay for things in real software as 16:55 as, , , maybe you want to use Venmo instead, ? pick, pick your payment provider and you can pay for things both ways, fully realizing that today everything's Venmo, but in the future we're going to have a lot more agents, bots, crypto experiences that 17:08 are going to be paying for things. I want to be prepared for that. I want to have software that can easily adapt to one place or the other. What are Your thoughts on this, Matthias? . what you're seeing as . 17:18 Yeah, I guess what you're talking about is good old software architecture, ? Thinking about, , high level architecture, what am I aiming for? How do I create components that contribute to a bigger system? 17:33 How do I reuse components? None of that has gone away, ? we may no longer be writing, , the individual 17:43 lines of code, but we still have the job to get things architecture and vision and to some degree testing, ? 17:55 If, if I guess from my point of view that's the big difference. But between using agents to produce software and wipe coding, if you're a vibe coder, you don't think about anything that, ? 18:08 You just create a big prompt and then you're happy when something comes back. And it may look pretty, but what 18:18 lifetime will it have, ? What happens when something breaks or when you want new features? Is that even going to be viable? 18:30 With good software architecture you don't have those problems, ? This is where you design and build for longevity and maintainability. 18:43 that comes to mind and in a way we can say nowadays we should have much more headspace and much more freedom to invest in things architecture 18:56 and planning because we, we no longer have the burden of writing code. . 19:08 those should be some of the massive amplifiers that we're getting from the agentic world. Something I wanted to point out, if I may, from the article, 19:20 there are a couple of interesting paragraphs towards the bottom. One of one is a performance comparison. 19:30 Very, very, very interesting figures. They're comparing the May version of the product, which was before the migration to an end of August 19:42 version, which is pretty much where everything is running in rust. one example here, launch a client, create a session and run one turn before the migration. 5.25 seconds after migration, 18x improvement, 290 20:01 milliseconds. And then another example, resume a existing session that had 32 turns. 20:12 May 5.6 seconds. August 21, 20.8 260 milliseconds. this is what they've achieved. 20:22 Wow. Yeah, there we go. Those are huge speed improvements. Yeah, that is paints a really nice picture. 20:33 But the next article is how much did it all cost? Yes, that's a fun one. And I love how they gone into some, some great detail here in terms of doing some analysis on 20:46 token usage, etc. Etc. they said the total token spend for all the porting work was 20:56 136 billion tokens, roughly. Out of which you said 146 billion. Correct. And then 136 and then 21:10 130 billion of those were cashed. Remember we mentioned it a few times. Yeah. The difference between fresh tokens and cash tokens is huge. From a cost point of view, you always want to make sure 21:21 that caching works as. As as it possibly can because it will save you enormous amounts of money. 130 out of 136 billion were cashed. 21:34 But nonetheless, apparently the monetary bill for all of that came to $120,000, which may seem a big number, but do think about 21:46 how much you'd spend on actual developer hours without agents? . this is deceiving. I believe. . You look at the number , oh, why would you ever 21:57 spend something that? . Let's put this in perspective. . What was the length of this project? . Yeah. . in three months. 22:08 three months. , in three months, full rebuild of something that is creating anywhere between 12 and 21x increase in speed on 22:18 delivery of results. . three months. If you were going to say no agent, do all of this with a team of engineers. And this is where I think agents 22:30 make things deceiving. And we've talked about this a little bit. I think, Matthias, is the fact that agents are, are a time machine. The fact that they can parallelize work, the fact that they can work when you're not looking at them, the fact that they're 22:40 building things outside of your time zone. you're , I'm going to go to dinner. I'm going to give the agent a task. I'm going to go have dinner and then come back. And , I'm doing something, but it's building something while I'm 22:51 doing something else. It's a time machine. I would love to understand the area under the curve. this is almost we need storyboard points to, to see 23:01 what, , , we can measure real storyboard points loosely in a, in an engineering team and say, , this was , you know, 300,000 storyboard points of what work was being done. 23:12 . If we had to put that against a real team, that's 25 engineers working for, , six months to a year. Do this. we don't have the numbers to quantify this. 23:24 If you start pulling the numbers, that would have taken a team of engineers to handwrite all this code without any agents. We're probably talking millions of dollars. Yeah. 23:34 Tens of millions, maybe. With all that. Certainly not three months. And the time compression. Yeah. you're getting two bonuses here. You're getting a really fast delivery of something. You're getting a single engineer that is able to architect and direct. 23:47 there's. There's no. Matias, I don't think we should write it this way because I think the architecture should be A and you're no, architecture should be B. Because of my experience. . There's none of that. 23:59 There's one guy at the top saying, this is the architecture. Figure it out. We're just going to go that direction. there's a huge amount of friction, political noise that's being removed 24:10 from the system because we build. We build what's here. This is wild, in my opinion. I want to focus on the area under the curve. 24:20 The area under the curve did not change. The work acquired over time did not change. It's just the fact that we were able to spend a hundred thousand dollars in tokens again would be, I think, peanuts compared to 24:32 an actual team to get the area of that work completed in a shorter amount of time as . And this is the part that I think is wild to me. Our minds are having to rethink what does creation of things look 24:47 because that area or the amount of work. How would you say this units of work per hour is 24:57 10x100x of where we were previously? Would you agree with this? Is this conceptually the direction of what I should be thinking about here? 25:07 Totally. , I'm personally experiencing that quite real time vividly at the moment where I'm continuously running into severe hardware limitations. 25:18 I've got a system that is good at parallelizing that I desperately need to add more hardware to my sort 25:28 of built Love IT engine because my agent constantly tells me how it's being throttled through cpu, disk 25:40 and memory constraints. Wow. yeah, that is absolutely true. And it's, it's a. It's a very nice problem to have because 25:51 unfortunately, it's something I can address. . But again, it just shows we certainly live in different times nowadays. 26:02 Anything else comes to mind as far as that one is concerned? No, I think I'm good on this one. this one's good. There's really neat article, really , what's going on there. Happy that there's a great improvement in performance. 26:13 But this is not one company doing this one. There's more. Yeah. the other one I wanted to add into the mix here, BUN was rewritten in Rust. 26:23 You see, there's a real theme here that was announced in July, early summer, earlier this year. 26:33 What is bun? Let's talk about what is BUN people can understand. I got another framework, but what is bun? ? bun is an alternative JavaScript runtime. 26:44 it's an alternative to node. In fact, it's more than just a runtime. BUN is also a package manager and a test runner. 26:56 BUN is . BUN replaces NODE and NPM and VITE in a way, or VTest, let's say VTest. 27:09 If you think you don't need Node, you don't need npm, you don't need vtest, because you've got this alternative system that is all of that. And BUN implements the 27:24 node APIs, but in a , they would claim better and faster way. 27:36 And earlier this year they decided to rewrite the whole thing in Rust. I think the reasons for that are pretty clear based on what we said earlier. And BUN became very, very known and popular 27:51 for one reason I would say in, in, in, in circles, you know, where people wouldn't have been aware of it already because CLAUDE code, the Claude CLI was built on top of BUN from the 28:07 beginning. And this is how many people have heard of BUN if they hadn't already. 28:20 And you won't be surprised to Hear that in December 25, Anthropic acquired Bunch. , it was a relatively small community driven project, Anthropic, , that's when they had loads of money 28:34 to spend from all the VC money they'd collected. Given that they had such a massive dependency 28:45 on bun, , for, for their Claude cli. They just acquired the whole thing, it looks , , to me, as someone who is been following the BUN project for a 28:56 while, it looks they've had certainly substantially less frequent releases since. it's a bit sad. But the, the Rust rewrite was certainly 29:08 a big one. And again, we've got an article from the BUN block in the show Notes here where they talk about that rewrite and 29:20 apparently. that's , that's. That's a rewrite from Zigzag, which is yet another language also quite close to C Z from my point of view, definitely a bit more of an 29:32 obscure language. that's where they've come from. And yeah, if you want to see more about it in terms 29:42 of stats and performance improvements and all of that, look at the article we've provided here. ever since v1.4, 29:54 bun is written in Rust and another project I Thought would be quite useful to share is TypeScript 30:05 7. Oh, . . everything up to this point, we've been talking about everyone moving to Rust. Rust is , oh, let's go do everything in Rust. Thorough agents at it build things. 30:15 TypeScript 7 did any vowel against Rust and they chose not to use it. this is good to understand why you didn't do something just as 30:26 as why you did do something. what's the converse of this? What did they pick? TypeScript went with go instead of Rust. 30:38 just to understand the context here. famously Typescript has always been built in Typescript all the way up to V6. 30:54 ever since at the very beginning, , obviously there's a hen and egg problem here, but at some point they had a very minimal TypeScript compiler and then they used that one 31:10 to then build the TypeScript project itself. Sounds weird, ? And presumably the compiler itself would always have been slightly ahead of the main version of the project. 31:22 . And that became a real bottleneck , in terms of the compiler performance. 31:34 Because, , whilst TypeScript as a language is incredibly developer friendly and flexible and very 31:45 good because of its typing constructs, it's not really 31:57 great for performance, particularly when you're talking multimillion lines of code code, project. And they ran into some real performance 32:11 constraints when it comes to compiling projects VS code, for instance, versus code. Obviously TypeScript code base. Millions and millions of lines of code that compiling vs code before 32:24 v7 used to take a big machine. And a lot of time they had to make a call at some point to give up 32:34 that very neat foundation of saying TypeScript is using TypeScript to build itself and to go and build the TypeScript compiler and something 32:45 else. There's a very nice interview, you can watch that on YouTube with Anderson, the creator of TypeScript who talks all about the. 32:58 The V7 conversion, , how they achieved more than 10x improvement, how they used the versus code code base in particular, , as a 33:10 significant benchmark there. And he was asked how did they end up with Go? 33:20 And he very clearly says Rust was a serious contender and definitely something they looked at. But his main argument, I'm paraphrasing it, but he's 33:35 saying they didn't. They wanted to port the TypeScript code base, they didn't want to rewrite it, they wanted, they wanted to go 33:46 to a different language, but they wanted to go to a language that in terms of the, the primitives of the language and the similar. The philosophy of it and, and the 33:57 semantics was really close to Typescript and Rust is not that, you know, whereas Go on the other hand is. 34:08 And he said going to go. They didn't quite get exactly the same performance improvements that hypothetically they would have achieved with Rust, but they 34:23 had the massive advantage of being able to do a port, you know, where you do a syntactic conversion of your code base 34:34 instead of a complete semantic rewrite of it. And as you can imagine, , that ultimately is a very 34:45 pragmatic way of deciding that. And yeah, if you want Anders to explain in his words, which 34:55 are substantially better than mine, go and watch that video there. My brain hears this stuff and this is very intriguing to me. I'm very interested in this. While I don't do code, I'm very 35:08 interested in the architecture decisions and why we do things and how long it takes things to get done. That stuff is very applicable and I think very useful for us to study. . What these really smart teams are doing and just 35:20 to unpack what they're doing. One of the things that makes me really one in this TypeScript 7 article, there's some beautiful, some beautiful diagrams showing you how much faster it is versus TypeScript 6 35:34 versus TypeScript 7. definitely check out the article. That's the one I just recently posted here. You definitely want to work on this one. One of the things I'll notice here. Let's talk about VS code. And it's 2.3 million lines of code 35:48 to make it . I just want to unpack that for a minute. Whatever machine they're using, it compiled in 125 seconds before. 35:58 it's in 10.6 seconds to compile . this is an 11, almost 11.9 to be precise, but almost a 12x speed increase. I'm going to pick on you a 36:11 bit here, Matthias, because I think this is a good point to talk about. When you have big projects, when you have lots of code running, the amount of time it takes the code to compile 36:23 turns into real dollars. This is because a lot of my development cycle, and I believe yours is too, is running inside GitHub and GitHub has runners, 36:35 and runners are action based. I commit something to my main branch. I'm ready to compile some code, I'm ready to produce the output of whatever the thing is, doesn't really matter. 36:46 I'm building a static website and I have a whole bunch of pages on this. If I can get the code to compile 5%, 10% faster. The more we work with agents, the more commits we're 36:59 making to code. , what's happening , and the theory I think is what's going on here is the volume of creation with agents is rapidly increasing. We've seen this with GitHub's usage through 37:12 the roof, everyone's building code. My GitHub if your GitHub page, ? on your GitHub page you have all these little the square graph, ? It's every day. 37:23 How many commits have you made or changes of code? My graph, all the old code that I did in 2015, even earlier 2016, probably January. 37:33 Those colors look almost dark . My GitHub illustration is very green, very bright green. 37:43 Because the amount of code I'm pushing directly to GitHub has greatly improved, greatly sped up with agents. There's a couple compounding factors. More code is being written than ever. 37:56 More commits are happening than ever. If you combine those two together. More actions, more time, more computers are running. 38:06 We know in the data space that storage is cheap. Storing the files on GitHub is almost nothing. But compute is expensive. Anytime I want to spin up a vm, 38:16 a machine, an action that's spending real money, and we only get, as a GitHub user, a certain amount of minutes before you have to start paying for them, it costs you real money. you've hit your threshold this month. 38:28 Me personally, I set an upper limit threshold for the Carlo Solutions organization On how many GitHub action minutes I needed. We ran into that, we ran into the limit and I had 38:38 to up the limit because we're doing much more production of work across my team that I need more minutes of actions to continue to compile code. 38:51 This is, I think, a real concept and I really improvements this where we're ripping out 10x20x25x time of code compilation need. 39:03 Because this turns into real money. And if you're on an old code base, this is going to encourage you to move from six to seven. Because if you have a lot of code lines in Typescript, this 39:15 is real money that you're leaving on the table at this point. . Ultimately, it's about feedback loops. If you're in a code base and you make a change, you 39:26 want to be able to get feedback from the system with respect to does it compile, does it pass my tests? ? Yes. If running your Test Suite takes 25 minutes each time 39:42 you're not going to have a good experience there, you're going to wait ages. That's been true forever. . 39:53 When humans were writing code and you had a poor build system or a slow developer machine and you had to wait ages, it 40:03 really impacted your productivity. The same is true with agents, but even more because you usually have multiple of them going at once, . 40:16 Rather than just one at a time. absolutely, very true. And that also. , yeah, that's one thing. 40:29 being able to get something to compile and tell you whether or not it compiles is one step. By the way, this is also where language servers come 40:42 in, ? LSP a big deal inside the VS code ecosystem, where you've got language servers running in the background that are able to 40:58 understand files containing code semantically and in particular they are able to understand 41:08 snippets of them rather than an entire code base at once. the language server protocol and the language server ecosystem VS 41:19 code is addressing directly that issue. It's. It's there to give you very quick feedback, ? Yes. You've. You made modifications to a particular function. 41:35 The language server is able to give you immediate feedback even if the project itself doesn't build, ? 41:47 Yes, correct. You don't want to get the build time to find there's a problem. You want to find the problem much earlier in the process. And I'm going to maybe ask a question here because I don't understand this one or know about this one language server 41:58 protocol, the lsps that is that being exposed directly to agentic development experiences particularly , , as the agent is 42:09 writing its own code inside your code base, those LSP notifications or things that's coming back to the agent and say, hey, you wrote a function, it's not real, the syntax is wrong. 42:22 Then the agent is immediately picking that up and then able to. Oh yes, you're , I'll fix the thing. CLAUDE code added. I'm just quickly googling it here while some talking. 42:36 They added native support for LSP a long time ago. Yes, exactly. That is something which is in the harness. But I am here. There we go. 42:48 I can see an article which is dated June 26th as a version 2.047 Claude code has native server language server protocol 43:02 support, which is good. But this is my point that my point is more and more software development tooling is being geared more towards the agent. How does the agent see this? 43:13 How does the agent write things? And then all These other Stan, we would still use it humans would still look at it in VS code and say, oh, there's a red squiggly line under this function because something 43:21 wasn't defined correctly or you added a parameter that doesn't need to be there or just syntactically, something was wrong. We need to see that. But , more importantly, the agents also 43:33 need to see that as . If you think about this architecturally, . Without that, your LLM obviously does next token prediction, . 43:43 When it looks at some code, it ultimately does pattern matching and tries to figure out given a vast amount of 43:55 learned examples, How is your code snippet most likely to modify to 44:12 match some of the good examples that they've learned from. . Whereas using an LSP adds a level of semantics that the 44:22 LLM per se does not have at all, even though it always appears to us if there's intelligence. . But the bringing an LSP into the mix would 44:33 be able to identify, for instance, this particular token happens to be a function name. And ASP can know that, but an LLM cannot. 44:44 ? Yes. stuff that. Exactly. It's an additional layer of context you're giving to the agent as it's building things. And as I unpack some of this, 44:55 I'm having an aha moment here around one, all this makes sense. But , when large language models are trying to write you functions, it's statistically I think the term would be is 45:08 you're regressing to the mean. You're going to the most common function that you're trying to write. And this is brings the phrase to my mind nothing's 45:18 new under the sun. . There's every function I need to write in my program. Someone has probably already written a similar function in some other program and in some other language that is the 45:29 ideal or the most performant way to write that function. large language models are just trying to regress to what is the most common observation that I see about your particular function. 45:39 nothing's unique. But the LSP being part of this pattern, you don't need to regress to the mean. You can build what you need to build and get the syntax 45:49 . it's almost a good. This feels a harness, major harness improvement. Oh yeah. To allow the agent to not have to be rigid around 46:00 regressing to the same function that everyone writes over and over again. we can be a bit more creative and still get the output that we desire. 46:10 What I find very interesting though is as we're talking about this and how coding agent harnesses and LSPs or should be, , 46:22 theoretically a very, very good combo. Weirdly enough, one, I don't think the announcement of CLAUDE code adding 46:32 native LSP support has been received as big as it should be, nor does it appear to be as big a feature even today 46:44 as it should be, given what we just said. . If you Google CLAUDE and lsp, you're not even going to find any top hits that go directly to the CLAUDE code documentation, for 46:56 instance. it's a bit of a weird one, which I can't really make sense of. Maybe some smarter people can comment on that. It feels it would be a perfect match, but somehow it's 47:09 not. Maybe we're missing something here in terms of harness development. Or maybe the LLMs are good that the extra help 47:19 from LSP is no longer needed. Who knows? Or maybe we didn't even know, , , . Yeah, we, we're just talking heads at this point, looking at observations 47:29 of , how we see and how we're interacting with agents in the world here and what we're building. And again, we all have different. Everyone's going to have different degrees of, of use and discoverability what's 47:39 going on here. I hope you enjoyed this discussion. I think this is a probably a good moment here to kind of wrap and wind down here a little bit. I think we had some really good discussion. I'm very encouraged by seeing software being entirely rewritten in these new 47:52 languages. That's very exciting to me, seeing other companies do this at scales that I'm not able to do myself personally in my company, I'm not going to spend $100,000 on any rewrite of 48:02 software. But I think this is starting to set patterns in the cost and rewrite world that we're able to observe. this is possible. , you, you build an app today 48:15 on a framework that is what you make the best decisions around today. This really drops the barrier for you. to me, it minimizes the risk of picking the wrong language 48:30 to start with on a project. You can build a project. Let's say we build, go for a couple years. AI is just going to get better and maybe you decide at some point in the future. 48:40 No, we should have gone and gone down the rust route. That's what we wanted. , put Matias on it for three weeks and, and spend, , 50,000 in tokens and get the rewrite. 48:52 not a problem. Does this also mean at some point in the future where we say, , we think it's going to be these three languages. We narrow down three languages that we the best. , great. Build all three at the same time. 49:05 And then you evaluate and monitor performance of all three at the same time. The lower you bring the barrier of cost down and the shorter you bring the time down, that just means less risk 49:16 to you as you build. The thing is how I'm perceiving it anyways. That being said, Matias, this has been a great conversation. I have many points I'm going to have to chew on and 49:28 think about . We hope you enjoyed this conversation as . This show is highly technical, if you haven't learned this already, we're going to talk about things that are deep and things that 49:38 are, that are at the high level. But, but there needs to be some level of forum, public communication forum around this topic. I think this is relevant banter that we should educate ourselves on. 49:49 we need , this language. if there's other topics that you , if there's other things that are interesting to you, please let us know down in the comments if you found this content valuable. 49:59 We really appreciate it. If you give us a thumbs up, just let us know with some feedback there. We'd love to have a thumbs up on the video. It helps us know that this is content that you . We'll continue making it. You don't, that's fine, no problem. 50:10 We can, , don't give us a thumbs up. But if you also want to be notified of any new updates or conversations we're having between this or explicit measures or any other content, there's also a subscribe button. 50:20 We'd love you to hit that as . Matias, thank you much. Another great conversation. This has been wonderful. We'll see you all next time. Thank you. 50:35 Hopefully my surprise will work. It's been a little slow to play here. Let's see if it'll see if it'll run here. 50:46 Maybe come on app, figure yourself out the suspense is killing me. 50:57 I've been trying to add music at the end of our videos. 51:13 Sam. 51:42 Monday memo says accelerate burn the tokens don't you hesitate Dashboards watching every prompt you send Use too little and you're at the end 51:56 Secret agents, secret agents Building systems in the basement Secret age agents under the radar Just trying not to get the paper. 52:16 Tuesday memo flips the script again Talking budgets bleeding cut it then Same old boss with a brand 52:26 new fear Yesterday's hero is old over here Secret agents Secret agents Building systems in the basement Secret agents under the radar Just trying 52:44 not to get up the paper we spit up tools they never blessed Shadow stack to survive 52:55 the test by sea for Claude when the gate gets closed by sea for Grok when the path gets froze More tokens, less tokens 53:06 make up your mind where solving work they leave behind unsanctioned Ain't the dream we chose it's the only way the deadline goes. 53:35 Business users in a quiet war sanction path don't open anymore if the company can't decide the lane Secret agents keep us in the 53:49 game Secret agents, Secret agents Building systems in the basement Secret agents 53:59 under the radar Just trying not to get the paper Secret agents. 54:12 Under the radar. 54:23 Sam.