AI tooling wars: Bun, Claude, and open source under fire

0:00Mehdi: Hello everybody. Welcome to the Explain and Analyze podcast. I'm Mehdi, a DevRel at ModoDoc. I'm joined with my colleague, which is also DevRel at ModoDoc, all the DevRel today, Alex. And each episode we grab the data and AI story around the world and take a look, explain and analyze them. Alex, would you take the honor to start with a first link?

0:11Alex: Howdy. You bet. I think this one has been very fun to talk about. Everyone has an opinion about this in the developer community, which I love. So the first thing I wanted to talk about was that Bun, a JavaScript engine, has been rewritten in Rust from Zig.

0:40Mehdi: Ben was already fast, right? And I think it was because it was written, yeah, it was written in Zig, right? And what's the, because a lot of things being, feel like we, especially with like AI taking over or chose for programming language, which is aside from JavaScript and Python, everything is being rewritten in, at least core engine in Rust.

0:43Alex: Bum is already fast. is written in Zig. Yep.

1:10Mehdi: Do you have some thoughts? I'm not an expert in Zig. Why they decided to actually move out from Zig?

1:19Alex: It's a great question. think I have opinions, of course, because I am a developer on the Internet and everyone has an opinion about this one. think, you know, Rust is definitely a very popular target for porting things over the rewriting and rusting beam. Zig in particular is closer to see than C++ a little bit. It's a little bit more manual memory allocation, whereas Rust has the barrel checker and is a little bit more structured. So it's it's a little bit of the.

1:26Mehdi: You

1:47Alex: the manual control versus automatic management discussion of age old times, except both are not garbage collected. So it's not that hands off. Plus there's also the added drama that the folks behind Bun were acquired by Anthropic. So that's also a big factor here. People are wondering is that why this is happening? to me, I think it's just folks that are incredibly good at using AI end up working at Anthropic. So I don't think it's necessarily.

2:04Mehdi: That's true.

2:16Alex: corporate driven. I think that the biggest interesting thing is just that this is a huge piece of software that got completely rewritten in a new language.

2:26Mehdi: How long do you think it's gonna take?

2:29Alex: It's already merged.

2:31Mehdi: It is already merged. okay, so I thought they were starting. Things are happening too fast for me.

2:33Alex: It's already merged. It's very fast. To me, my take, my take is that this people's opinion, in my opinion, is based on how much they trust the test suite. That's that's where it comes down to. If you believe that the test suite can catch it all, then you're probably like, sure, I love memory safety. I love I love this plan. If you think that test suites are not 100 percent, you know, real real world coverage, this is a little bit of, know, This is a foundational piece of infrastructure being totally rewritten in a new language in like a matter of weeks.

3:14Mehdi: Yeah. And it's interesting because they mentioned like, yeah, indeed, they release a new version three days later and they said this would be the last version in Zig. I think it's super drastic because before we used to have announcements, discussion on, know, specifically on open source, you know, framework, but I guess now they are being acquired by Entropiq. have still some direction probably. should have a specific direction, but it's just, feels so fast. I haven't seen, I've seen the news, but I actually didn't understand that it's already happened. Have you actually tested? Do they have some benchmark?

3:55Alex: I haven't tested it. I think that it's mostly around long-term safety and ease of contribution, where they believe that because the language is handling more of the memory safety, that they can move faster. That one quote you mentioned, I do think this article took it a little bit out of context. It did say, if we decide to merge it, then this last release would be the last one on Zig. So there was a little bit more back and forth with the community there. ⁓

4:01Mehdi: Okay. I see. Okay, okay, okay. Okay, that's good. Let's do that for you.

4:27Alex: But it's going fast. It's going very fast.

4:30Mehdi: Okay, so yeah. The binary is gonna be shrinked. That's also a good thing, but it's for AI safety contribution, which is interesting because it's also why TypeScript is gaining into the AI era. But Python is still there. So how do you explain that? Like what's your bet on that?

4:33Alex: And to me the question is, what does it mean for... You could do types in Python as well.

4:56Mehdi: Even if it come on nobody, like it's not enforced. So like it's so funny enough, I used to do type a lot in Python because it's basically a big fan of data class and so on just to instead of passing just for configuration objects, just giving type full object. I love that. But now with AI, I mostly review and I'm not like.

4:58Alex: It's not enforced.

5:23Mehdi: Yeah, type this, type that. If it's readable for me, that's good enough. I don't need to understand at that level the complexity of the code, right? If I debug, it's mostly towards discussion to LLMs. So I do less typing actually now. I understand that it can be nice to be enforced by the engine, but for human readability, I'm not sure if that has so much value.

5:52Alex: I have always been a data cowboy. So my Python is very rarely included types ever. ⁓ I think that's probably gonna change moving forward because it's so much less friction now to add them. It might be like a single statement to do something like that. To me, I think Michael Kennedy, who's a leader in the Python space, phrases it well where he says that he really likes the interfaces where you really need to...

5:56Mehdi: Okay. Mm-hmm. Yeah, that's great.

6:17Alex: to have the typing. ⁓ And that's definitely the first place if you're going to have it. But I think that's an interesting thing is what can we take away from this for our own work, right? Should we use more or less types? Maybe we should. Should we use Zig or Rust? I don't know if we need to decide that. to me, this emphasizes that the test suite is critical. Because the only way this is possible is because the test suite has got to be credible. so I think that's my takeaway is more tests.

6:37Mehdi: Yes. Okay. So I have one interesting thing, which is more database thing. It was a blog, agents use system differently by Davis Trebek, if I pronounced that correctly. Sorry if I'm scorching your name. And. We all know that agents are using resource and API differently. But this was, I feel, good take around mostly database specifically and how the agent's experience should be rethinked for them, right? Because we all designed the system for mostly human usage. And so what I like is mentioning, you know, snapshot and time travel because agents needs to be sandboxed and they do mistake quickly. like if you drop your database, you know, by mistake, you should be able to roll out a rollback quickly, right?

7:43Alex: Don't you mean when you drop your database by mistake?

7:45Mehdi: Yes, exactly. That's a good correction. So when you drop your database by mistake, either your agent or yourself, you should be able to do it quickly. But what is interesting, it says that there is some trade-off and it hasn't seen... There is a couple of missing things where basically if you follow... I think it was downstairs. So depending on how you do your optimization, basically, is that something can be slow in time of branching. And so I will note that in spite of large number of database advertisement efficiency branching, there is still a lot of performance optimization to be done in this space. and he called another paper which evaluates a system like Neon, Dulse-Gray SQL, I didn't even know this one, TigerData and so on. And he saw that for fast branching, it suffered like five to... 4,000 times slower reads as branches deepen, while system optimized for fast data operation is 25 to 1,000 higher branch creation. So yeah, either you do your switch branching fast, but then your operation is slower, or... ⁓ if your branching is slower, then your read and operation are fast. There is kind of a trade-off that's been built so far with the design that we have without agent eating our database. But now it's changing. I'm sure you have a take on that with us having being a mother. What do you think?

9:28Alex: think this article is really, really cool. I'm just looking at it for the first time, of course. That's the fun of this kind of thing we're doing. So there's a lot of good meat here. I think that transactions are important with AI. I think time travel is important for AI. And I think branching is. I completely agree. The ability to go back in time, all of those three pieces really help a lot with that.

9:35Mehdi: Okay.

9:51Alex: The other aspects about that where the performance of branching being important, to me that feels a lot like the traditional kind of data lake house ingestion compaction trade off, where the speed at which you can ingest might mean that you ingest in really messy pieces and then you kind of compact it later. That's what it seems like branching would land on at some point.

10:14Mehdi: Yeah, and there is also the point of ⁓ rapid scale up and down. It's totally true. If you're a data analyst and you act on a problem, you're going to run one SQL, then think about the results, then you spend time to write your SQL again, right? And you think about the results. And basically your work is kind of like distributed, it's like your workload compute, right? It's like the time that you need to think to analyze the number. ⁓ and then maybe you're do, you know, scaling queries. AI basically fire those up, like even in parallel, right? And then regroup everything. So you have a huge spike, you know, up, I would say, if you need to allocate some compute to this specific agent that doing an analysis. And then it's basically down to zero, right? So I feel like also this drastic change in... in compute and call start. And that got me thinking that I think we have also a lot of things to do even deeper in the architecture layer, you know, on the hardware sides. I mean, we've seen the raise of SSID and so on. I'm curious what's your thinking there, but I just got think then, okay, if if call start is really, you know, a hot problem without pen intended. for agents, it means that we need just to go deeper in the stack to optimize our workload for that. I was thinking machines have been optimized for a specific kind of workload.

11:48Alex: I think it's very interesting. I went to AI Council last week and ⁓ they had a panel of database experts talking about infrastructure in the AI era. And one of the things they talked about is the cloud hyperscalers don't have a primitive like S3 for this kind of low latency cache setup. There's like S3 Express One Zone, there's a couple of things kind of in that direction, Tigris, but there really isn't a solid answer for some universal fast cache system. And we're currently in the Cambrian explosion era where everyone is building these types of things, both from the AI side, on the sandboxing side, the VMs, how fast can you start your VMs, and then on the database side, how fast can you rehydrate it. I think it's an exciting time and I do think it's a free for all. It's an important problem and I don't think there's one answer to it yet. But that's gonna determine your performance a lot. ⁓ So it's important.

12:40Mehdi: Yes. Yeah, so maybe we're to see not really a hardware company, like SAS that has a specific setup of hardware, windows and self-hosted to provide those things. Like a bit like with the raise of GPU, right? It's like now we need GPU data centers. Yeah.

12:53Alex: I haven't even thought that far, interesting. I have long had this like, you know, I've seen some research from some database experts at TU Munich and they benchmarked cloud SSDs versus client SSDs. And the cloud SSDs are 10 times slower. That's crazy. That's, order of magnitude doesn't happen that often. So it, I think there's plenty of room to run for caching performance.

13:21Mehdi: All right. You want to follow up with next topic? You have quite a closed topic or I would say, Entropic topic. This is not sponsored by Entropic, by the way.

13:30Alex: I have a couple of anthropic topics like that. The next one is one that I think is kind of neat, and that is the Claude codes ⁓ slash goal ⁓ slash command. And that basically allows you to give it a prompt that determines and defines a goal and kind of, especially if you can measure how it is going to be completed.

13:40Mehdi: Yeah.

13:51Alex: And what that means is that as your agents are working, as your sub-agents are working, there would actually be another sub-agent that would be checking if that goal has been completed. So to me, it feels a little bit like the return of Ralph Wiggum, but a little bit more natively integrated. It's gonna loop things and then check if your loop is done. But instead of a hard-coded to-do list, it's a goal. And it's like a lot of things in AI, it gets fuzzier and fuzzier over time, right? This goal is not like a defined like task thing. It's just a, it's a vibe, right? It's like be done when the code quality is good and the tests pass and you know, you're.

14:30Mehdi: Yeah, I think the goal is basically a measurable test, right?

14:34Alex: It would be better if that's the case, but it doesn't have to be. You could put subjectivity in there too, but...

14:39Mehdi: Have you used, like, for me, I was building something recently, and I wanted, basically, the test would be that two image are the same, right? And even that, I was actually hard that using vision, and there was some, like, you can... It's always go to, like you can analyze on each bite of the image on like what pixel is different, but I don't need that. I don't need to be every pixel, you know, but I want to see like, it looks like it's the same, roughly the same image. Like there is no distortion or no hallucination in there. And then I include the pipelines good. But yeah, that's kind of a merserable test, but still hard because there is vision included. Have you tried it with specific merserable goal?

15:28Alex: I did, I tried it with, know, it passes the test suite, you know, the kind of, and that worked fairly well. ⁓ I haven't tried with like a performance benchmark, but like, know, improve the performance until you get to X amount. I could see that being really, really helpful. I think to me, the main draw here is just that it's a way to poke the agent. So if you think back to like Gastown, which feels like a year ago, right? But it's probably just a few months ago, but like a huge feature of Gastown was all these different.

15:33Mehdi: Okay, very classy now. Yeah

15:57Alex: agents poking each other to say, working, keep working. And that's what this goal does is you have an external agent that gets to decide if it's done yet. And if not, go tell the other agent, get back to work. And my mission is to get more efficient at running stuff overnight. And to me, the specific measurable task is less important to me than the just don't give up, know, like, like work harder, Claude, do more for me.

16:11Mehdi: Yeah. So that's a take, I haven't think about it and I think it's really interesting to think at this feature as another agent to orchestrate other agents, internally, the goal is it's transparent for you. Because for me, initially I was like, can just put that in specific skills, but I guess... if you have another agent that spoke and it's based in the process more consistently, the agent might skip skill information as it goes through a loop. OK, ⁓ I'm a bit more convinced to try it out because to be honest, I haven't tried it out yet.

16:56Alex: For me, it's more like the... For me, it's all about like the, I've seen those messages of like the, you know, I commented out these tests for now because they seem out of scope, you know, or the, like, this bug was caused by a previous, previous committer. I'm like, Claude, that was you too, you know, like, get back to work. I think that that's where I see this as being valuable.

17:07Mehdi: Yeah. Yes. Okay, I have another topic which might sound like a topic, but actually I want to nail down to BI stuff because we are in that sector. a lot and we've seen a lot of change. So it's an extract from Lady's Podcasts about, what it is, like the title is While Cultivating Agencies Matters, More Than Cultivating Skills, from someone from Notion. But it's actually not about the agency, which is funny because it's one of the core value of ModerDoc, but it's really not about applying a ModerDoc. I just took actually this postcard for something

17:55Alex: Yeah.

17:59Mehdi: else because he's talking about malleable software. So he mentioned, let me quote it, that apps today are locked into squares. Fully do-it-yourself is exhausting, because you start from everyone is building their own size, their own mini app for them. And so the middle ground is basically platforms that let users tweak and share. without rebuilding from scratch. You say also, you know, I love collaborating with others and also that has been a frustration for me, just in general, that I see a lot of my coworkers, you know, building things and the shareability aspects of all of that, like if you build, you know, raw JavaScript app with cloud codes, it's kind of difficult, Versus you're inside a sandbox area from a provider and you have this shareability and some other stuff. So I think it's resonated a lot with what we've been building on ModoDuck with Dive. And I'm curious to see if you've been also experimenting the same frustration that I have, or if you see that there is more software. Like I mentioned BI and the Dive we've been building, but I'm curious if you have other thoughts on other piece of software where we need this.

19:19Alex: I really like this thought experiment. To me, it feels a little bit like a bit of a pendulum or a cycle where you kind of go from standardization to customization. And I think in the age of AI, a lot of the success of software is going to be determined by how long you can use AI with that software before it becomes a muddled mess. And that comes back to architectural fundamentals. That comes back to separation of concerns and modularity and like architecture.

19:28Mehdi: Yeah. Yes. And Byvers was built also.

19:48Alex: Build versus buy, yes, yes, right. If everyone builds their own, then it's not standard at all. So when do you buy the standard or not? I think there's absolutely a, I think that we're gonna see it oscillate very rapidly back and forth. To me, in terms of BI, I think that we've been very far on one side of the pendulum for a long time where a BI tool is, it has to be pretty restrictive because it was slow to build. BI tool, there's just so many feature requests from everybody. It has to support a huge number of backends. Right, I want that to be a little bit darker blue and can you make the font Comic Sans? ⁓ Despite your users, we're in what is it, spite-driven development. So I think the extreme customization is really interesting. I think what we'll see is a little bit more componentization over time, where once you make five custom things, you're gonna say, you know what?

20:14Mehdi: Yeah. Can I have my logo there? Yes. Yeah.

20:41Alex: Every time I want a graph, I want to maximize button on it. And this time, it's probably going to look a lot less like I'm going to write a JavaScript library for that, a lot more like I'm going to make a skill for that. But there is going to be still that common thread of, once I do the same thing five times, I want to automate it a bit. I just think it'll be a little bit fuzzier.

20:58Mehdi: Yeah, but I think the challenge is how people are going to come together. A lot of people are pushing back SAS, and we are at Modeler for other internal SAS tools, right? And I'm not sure.

21:02Alex: people side.

21:10Mehdi: it's always the right decision. think if you're a tech company like Notion and us, yeah, we have resource internally, but if you have a random team, I don't know, a real estate agency, they don't have even IT and they use their service and won't say, yeah, I could write code this. But real estate listing is all in all the same, right? You can invent some stuff and I think you should offer to people the ability to check. So I think it's like, as you mentioned, there is really a big challenge on providing this freedom and without, you know, restricting the users and also educating. How do you educate people about, you know, free form software versus specific deterministic feature that you provide?

22:01Alex: I have a little bit more of a reductionist take. I'll kick it a little old school. All of the companies in the world are building those style of things in spreadsheets today. And they have for a while. And to me, I think it is more likely that the spreadsheets get a little more powerful, but we still have the same kind of vibe of like that one guy at the company that knows what's up, you know, he's the one guy that built the spreadsheet three years ago. And like, you got to go like call him in on the weekend to go fix the spreadsheet.

22:26Mehdi: I see. So you have a human technical depth that's going to...

22:32Alex: I think there's gonna be, I think a lot of the same problems are faced in spreadsheets and I love spreadsheets. So I think we have some antibodies there, some tools to handle this problem of like, how have we done this with spreadsheets anyway? Not too dissimilar.

22:49Mehdi: All right, next, what do you want to go on?

22:54Alex: Sure. The next one that I thought would be interesting is that there is now a ⁓ Codex plugin for Cloud Code.

23:01Mehdi: Yes. Okay. So I tested Justice Boy and it failed on the first time. So tell me. Like it ran in a loop. I asked maybe a big arse because it was a review and the code base was big, but... And actually have a screenshot because it was funny. ⁓ It says something like, let me go back and I felt like...

23:06Alex: Please, good. but it's cut. no.

23:24Mehdi: Okay, did you actually just kill the process of... But just go again maybe to introduce what is it exactly.

23:32Alex: Yes, yes, sure. So this plugin, it's open source like GitHub. It has like 1,500 stars. It has to be great. And so I agree. ⁓ I agree.

23:40Mehdi: No, because that's, I disagree completely. In the age of EIS today, like any repo can be, I feel like GitHub is the new Twitter. Like you can have virality and then nobody knows what you're doing.

23:55Alex: but this one has 19,000 stars, excuse me. So way more viral.

23:57Mehdi: Yeah, okay, it's OpenAI, it's OpenAI. All right.

24:01Alex: Right. So nothing too crazy there, I guess. to me, I think the approach is interesting. I still think we have not solved that as an industry. It's very open, but it's how can I maybe not use the fact that other models are even stronger or weaker than another, just the fact that they're different. Sort of like in machine learning, you think about like, you might run the same algorithm with different random seeds when you start. So you get some of that with subagents, like launch three reviewer subagents and they'll get a new random seed and kind of a... adjudicate your PR, but this is, know, choosing out of a different distribution and this is saying like, hey, use a totally different model from a different company to review this code and look at the approach and grade it. And I think that approach is strong and I expect that to be here for a while. I think each of these AI companies like to believe their moat is very large, but in reality, this is a very concrete API. right, ask a question, receive answer. And if something else gives me better answers, I could switch over in a millisecond. And I see this as a skill that I want to get better at, that I do think is something that's going to be here for a while, which is just use the models for what they're good at. And if nothing else, get a double check before you have to read the PR.

25:10Mehdi: Okay, I want to dive on this because I agree with you that most of those AI companies think they have modes in their model, which... If you asked me a year ago, I would say yes, because there is drastic difference. But now that performance are converging, China are being dumping like, you know, open source model. And I've heard that it's like just to kill ⁓ US competition, because if you give basically free stuff, you know, out in the world on models that like have some performance. level from the the big two or big three like OpenAI and Anthropic. But one thing I see is that, for example, OpenCode is a great project and I love it, but it's... from an enterprise point of view, they get limited from before you could use just your cloud subscription to use basically API call to ours on Tropic. I don't know exactly the detail, may say something, but the point is that they started getting things so that you're forced to go to their pricing and to their environment and ecosystem. versus basically having the freedom to switch over models, which I feel like it's the futures. People want that and the level of quality of the model will reach that level where they, as you said, they're both good, but different. How do we get out of this trap of vendor locks?

26:45Alex: I think that that is a very interesting point and the harness appears to be where the companies are trying to build up the moat and that they're trying to enforce access limitations at the harness level. I think it's an opportunity for the open source harnesses that can call into both, but again, they've got big disadvantages pricing wise, so I could see how that would be challenging in general.

27:06Mehdi: Yeah, you see what Sal Matmann said, like, you can have a couple of months free if you switch now. And I think it was this pricing attack was just when they released the plugin you mentioned, Codex plugin for Cloud. So yeah, there is a war coming on, but if I am in Codex, then I'm stuck. I don't want to be only in Codex. I don't want to only in Cloud. think if you start, like I've been starting to use Codex as sides, and you start to feel the difference from those models, then that's where things get interesting, because then you start to think, okay, I'm gonna ask this model for this and that. And for example, those two, I still feel like both OpenAI and Anthropic are far behind in terms of image intelligence and video intelligence. Like, past video, like Gemini actually is really good at that. And so, yeah, I'm just not optimist about how we're gonna be able to do it, because I feel they're putting walls and walls here and there to avoid this.

28:11Alex: I'll give the optimist take that. You can always count on me for that. So the optimist take is that I don't think subscription plans are the long-term business model because currently every subscription has significant users that are giant loss making machines for these companies. And then they're subsidized by people that don't use the subscription to the fullest extent. And I don't think that's a very sustainable business model because I think the gap there is just so big.

28:32Mehdi: Mm-hmm.

28:39Alex: So power users can really just use ⁓ a huge multiple of the subscription. So I think as pricing converges on per token, per request, something that's usage oriented, that levels the playing field on these harnesses and allows the open harnesses to have more of an opportunity. So that's my optimistic take is that the pricing structure makes it a more even playing field over time.

29:02Mehdi: Yeah. OK. Let's see if it's the optimist or premium seamless that win in a couple of months. Let's revisit that. Using cloud codes, someone mentioned the unreasonable effectiveness of HTML. I actually strongly disagree with this blog. ⁓

29:09Alex: Stay tuned. interesting.

29:27Mehdi: Yeah, I was actually thinking I don't share that much blog, I disagree, it doesn't resonate with them, but because it had a lot of views, you look at the link, there's 12 million views, BlogsonX, and that was, when was that released? Yeah, just 10 days ago. So the whole premise is that this person has been using HTML instead of Markdown for visualization things. So he mentioned, you know, Markdown are the information is more clear, you have more tunable UI, if you need, you know, slider or whatsoever to think or resonate about things. And he mentioned also sharing and publishing for people. And I think there is a lot of truth in that. And a lot of people are doing more HTML. think, for example, slides are a good example. A lot of people are doing HTML. But actually, I feel, and there is a couple of people in the comment that... there is not enough of separation of concern where you have content versus presentation. And we're not even talking about the token inefficiency, like Markdown and HTML, so it does acknowledge that. But I think what's surprising is that it doesn't talk about MDX, which is Markdown with any components like React component and a lot of documentation website. works like that, you just write the content in Markdown and then inject some presentation layer in specific competent. We were just talking about reusable competent, right, before. So yeah, I'm curious how you have been using Markdown and if you have been using more HTML in Cloud Code. I think this is more drastic. It's really saying like, I'm not using Markdown for anything I'm when working with Cloud Code. What's your current state?

31:40Alex: You know, I've got a couple of different thoughts. I could kind of go a little bit either way. To me, I think that we are rapidly entering the era where the bottleneck is a human's ability to review. And it is not so much a token limitation. And so to me, I'm willing to invest more tokens to shorten my review process. especially if the tokens are overnight or over lunch. And if I can get something to where I can very quickly understand the PR that's been changed or even have an app, like a small little applet web app where I could, man, applet, what an old term, a web app where I can tweak things and visually see the answer immediately. That has a big ROI in terms of saving my time. And I think that's got to be a very precious commodity in the age of AI is like developer hours, interestingly enough, right? So I.

32:33Mehdi: So what's your take then? You would go down to the road of building your custom HTMLs to review? Because that's one of the big things, that reviewing HTML, raw HTML is pretty hard versus just Markdown for example.

32:51Alex: I probably am a little bit in the middle where I would use HTML for some features, but I would, you know, for anything that I'm going to commit into a repo anywhere, it's going to be Markdown. I think for me, the HTML is all about building myself debugging tools and review tools on the fly. And diagrams, Markdown diagrams, not ideal. Claude's not very good at ASCII diagrams either. They always render terribly.

33:02Mehdi: Mm-hmm.

33:16Alex: So to me, it's a limited use case where I will definitely use it. And I do use it. ⁓

33:21Mehdi: Yeah, he does mention like, Claude has been good at using ASCII to make diagrams inside of markdown files. But I think like, why would you do that? Like there is Mermaids framework that does solve that and you can always go to the HM1, but I think, yeah, this is where I kind of like disagree. Terminal are not suitable, that's that I agree for every visual and maybe it's because we are nailed down today as terminal as the default for development. Are you using any IDE actually these days? Like Conductor or stuff?

34:00Alex: Yeah, maybe. I do, yeah, I use VS Code for review, because if I'm going to make a C++ PR to a project like Duck Lake, like...

34:12Mehdi: Okay, okay, okay. But just in general, if you do stuff like other stuff than that.

34:18Alex: I'm usually in the terminal for building data visualization or my typical workflow. I'll occasionally use the Claude chat if it's like a total research project about like, hey, research this, approach and research this. Cause I think that the artifacts that can produce in the web are more pleasant for reviewing that research. So I do actually make that deliberate trade-off to go back to the UI, to HTML for the research type of task.

34:41Mehdi: Okay. ⁓

34:44Alex: but a lot of terminal, more than in the past. I'm not great at the terminal, but you know, getting better all the time.

34:51Mehdi: Yeah, but I think the TLDR is that we definitely get more HTML than we used to for short ad hoc tasks, like you mentioned, for example, slide presentation diagram, but I don't feel it's the right medium for default content, especially for you. But we'll see, maybe there will be a framework. for that, but I believe there is already. But if you can, that's the problem with AI is that you question every single framework we've been built so far because there is kind of a different usage. It's kind of a rabbit hole thing. You want to go next with again, clothes. You should get free credits for all the.

35:29Alex: man, I'm so far from that. I think this relates back a little bit to the point we were talking about before, which is that there are some policy changes happening around what subscriptions can be used to do. ⁓

35:42Mehdi: Yeah, it's actually coming on the 1st of June, right?

35:46Alex: June 15th. So coming fairly soon, but this was nice in that it didn't change immediately. So I think in some ways we could take some meta takeaway points from this. So starting June 15th, there's some different billing. But this tweet that I'm showing here from Claude, from Anthropic.

35:52Mehdi: you

36:05Alex: tries to put a positive spin on this rather than to acknowledge that things get more expensive and just the comments just exploded. I don't know if there's a good way to make an announcement about raising prices, but I think they should try something different than this next time because this was not well received. they're basically just limiting that this Claude-P mode is basically a non-interactive way to use Claude code. you know, Claude programmatic, and they're building it very differently in a very expensive way just because other harnesses were using that feature, and so people weren't using the Claude code harness.

36:39Mehdi: Yeah. Yeah. So it's exactly what like coming back to the initial topic where they build, they started to build their castle where once you get in, pretty hard to get out.

36:53Alex: Yes. So I think the takeaway for me, there's this big trade-off I go back and forth on in my mind, which is, do I get really, really good at one tool, Cloud Code, or do I sample from a huge variety of them and get surface level on all of them? And so far, I've mostly been focused on Cloud Code and seeing just, can I customize it a bit? Can I make sure that I'm using it in an effective way? But

37:15Mehdi: Yeah. The framework has been more open. Like skills usually was, you know, initially just from, you know, started from Anthropic, know, as part of the AI Linux foundation. I mean, the AI part of the Linux foundation. And so, or is it the MCP? I mean, say something weird. Anyway, it's an open spec and, you know, OpenAI is not supporting skills as well.

37:24Alex: Mm-hmm.

37:41Mehdi: So there is open standard, but I feel like they have business incentive to actually also not do those things, right? So don't know how it's gonna play out.

37:53Alex: Yeah, I agree. So I think the only constant is change. I think that's part of the takeaway as well as to just, we have to kind of plug into the stream of data and adjust to the changing surroundings. This might change what harness you use because it might affect your pricing 10X. And so we have to stay plugged in. Otherwise we pay that 10X. There's some big changes there. I think also as people, as the AI market changes, certain things like any startup where initial pricing is designed to attract users and then the pricing changes over time. And that's gonna happen all over the industry. We have to all kind of watch for that a little bit, but also as we are messaging, as we are building things and messaging out pricing changes, I think we can learn from how this was received. It was called a rug pull. was, know, Theo was talking about, know, framing this as a free credit instead of a regression is wild, you know.

38:44Mehdi: Yeah, yeah, Tio has been also a bit on a war with Anthropix. I think that was like just a blessing for him.

38:50Alex: There's some bias there. You're right. There's plenty of bias there. And yes, I'm quoting someone that is also a polarizing character out there too. yes, plenty of disclaimers.

39:01Mehdi: Alright, so we'll see if we get more open standards or more walls, but it seems... Yeah, it seems challenging exactly as you mentioned to kind of like build your harness, but at end of the day, I think the only one thing you need to be able to do is ⁓ change. I think the good thing is that with AI, change is much more easy to do. Like if you migrate things from Markdown or you need to fit a certain framework or you need to rewrite an entire engine in Rust. ⁓ Yeah, I think that's...

39:33Alex: You know, theoretically.

39:37Mehdi: That's maybe the good thing is that it's a bit of a paradox that we're using AI and we are getting into walls, but it's actually also a tool to enable us to move from other provider much easier. All right, I have two more links, but I want to go to...

39:50Alex: Yeah, I mean.

39:56Mehdi: This one, is first, is the Vibe coding is killing open source. it's a paper that was, let me share from various people and I feel. Just the title, I think you get some information. It's actually a paper already from January, end of January, which seems like years ago. But I'm curious, just with that name, I'll put the links, of course, and that is a good plug that if you want all the links that we been discussed and the resource notes, you can go to mother.explain-analyze to get all those information. So we have, I've been experimenting a lot of. trashes PR in open source where people barely read documentation or even not pointing their LLM to the docs, to read the docs. then, yeah, the quality is really low and it's really hard for Maintainer to go up. So where do you see open source going with, you know, agent taking over PRs?

41:14Alex: I think it's a little bit of... I don't want to think of it as like an arms race, but it is sort of a, you know, back and forth a little bit where right now the infrastructure for writing PRs is ahead of the infrastructure for reviewing them. But I expect that the maintainers are going to have to build up a strong muscle to wield AI in order to review these PRs in some way, in addition to the human review. I think today for open source maintainers in particular, the...

41:38Mehdi: Yep.

41:44Alex: human review time is the constraint. And I think, so I'm gonna give a talk on this at our event called The Dive coming up in June. I have to look up the exact title because it's a tongue twister, but it's something like, conscientiously contributing code in C++ with cloud code or something similar. So the idea there is when you contribute, your goal should be make this as easy to review as possible.

41:47Mehdi: Yes.

42:11Alex: And that's been true forever. Again, it's a back to basics thing, right?

42:13Mehdi: Yeah, if it's human, it's the review.

42:16Alex: And that might just be because I'm trying to contribute back to infrastructure projects. It might be different if it's a different project where maybe there's AI reviewing it. Maybe you need to just make it AI reviewable. But in most cases, it's still human reviewable, I think. so that means things like doing the basics, reading the documentation, looking at similar PRs, checking to see if something's been done before. And I always like to ask, a cloud, kick off a sub agent to check how many functions you should not have created. and you should go reuse functions instead. And then make sure you've got tests, make sure the tests are not like a million tests. It's easy to submit a thousand tests when really 10 should do, but make sure it's tested. And then it's a lot about explaining your reasoning. And that's not ask Claude to explain its reasoning because it's gonna give you like five paragraphs that are like mostly gibberish. It's...

43:07Mehdi: No, it's sometimes too verbose because that's a good interesting point you said, like they need to train so I have more AI reviewing PR, but at the same time, you still want to be able to go back to this PR and readable or just do the final match. Okay, it's ready to merge, right? There is an agent that has been reviewing the codes. Like typically what we use, like it was boring CI that doesn't some check.

43:10Alex: Yes.

43:36Mehdi: And then there is a human that do the final call. And for that, yes, you need to explain your reasoning and it needs to be a bit more succinct and kind of like, why are you doing this? I think sometimes there is more... context than just the current code base. Like, ⁓ yeah, I'm doing this because this other product or this library has been investing into this. And so I think it's better for us for free to forward, which is hard. Like, the element needs a bit more context on that. I don't think it's happening a lot today on open source.

44:09Alex: I think.

44:14Mehdi: So yeah, I do feel the level of quantity of code we've been shipping is more, the quality, even with the model getting better, I it's not there. One good example I want to call out is Obsidian. So you know Obsidian, the note taking app. So they had their plugging submission system to a repository. where basically you say, have a new community plugin, here is the repo, and I want to be in the directory. And there was a new plugin every four to six hours, like PR requests. Okay, so it's like 2,500, yeah.

44:56Alex: I can imagine coming back from the weekend and just the wall of PRs.

44:59Mehdi: Yes,

45:00Alex: Yeah, yeah.

45:00Mehdi: and that's just for new. There is other stuff, like people updating their code base and so on. I watched this because now the repository, they completely changed their process. It's fully automated. So they have a dashboard where you basically submit, there is a CI and basically AI, I think review exactly as you mentioned, and it's auto approved. If you pass all the green, it's auto approved. and they do have IMAN in the loop for a specific case or if there is an error that could be a false positive for example. But that's beautiful because that enables people to build their own stuff back in the sandbox. I feel we start to speak always back to the same topic, also with the extendable software for people. Where here for Obsidian, the sandbox is, this is the constraint for having to be your directory and your plugins to be available. But yeah, super interesting how a system can be, you know, can strive like this, I think Obsidian is great, but Obsidian itself is not open source, like community plugin, you can actually even do a community plugin which is not open source. So I am worried again, sorry I'm really pessimist today, about what open source is gonna become.

46:19Alex: I think there's absolutely a lot of open questions. think there's a lot of pressure in open source. You have this increasing deluge of PRs and issues, but you also have a lot more attacks. These supply chain attacks are not going away. I mean, it's a lot of pressure on the human side where I think it's in many cases a human challenge of... In some cases, open source is a labor of love where people just love something they want to share it and they want to provide it. And then if the burden of maintaining this thing that they love becomes too great, then the world misses out. And I think that's part of it. There is, course, open source that's closer to the commercial side and that has a different set of trade offs where it's not necessarily a labor of love, but it definitely still faces both of those challenges. I think. part of the approach of allowing people to contribute in safe and automated ways is still powerful. And I think plugins are again, another architectural decision, another back to basics idea. But if you can have a plugin system that can operate totally independently of your core software, you're gonna move way faster than age of AI. DuckDB has community extensions. I think that's a speed boost. A lot of other database engines, you look at Data Fusion, Velox, others. they don't have quite the same ease of use of a community extensibility.

47:40Mehdi: Yes. And I think like it's by, mean, it's a good architecture now, but I think like it's by accident because there is pro and counts, right? It's like you want to have control on core features. And so Doug DB has, you know, core features of this community. But I think it's, it's a complexity. I mean, hats, it definitely has some trade off, but I think now it's, it's definitely interesting because there is much more people able to contribute, right? I think. before and still now surprising that there is not that much that I felt that it be extension. I think there is much more than there used to be. have a tech DB extension radar for that. But I think people are still a bit, you know, cautious. But while actually it's not that hard, but you need some basic on C++. Now there is other API. But the point is, yeah, it works really great with the, in the age of AI to, as soon as you lower the technical barrier to entry. And that's a separation of concern, right? It's not the responsibility of the core product to maintain that. I think that's the key thing, right? Because the other platform are slow because if they want to add specific features that look like plugin, but inside the maintenance responsibility is on the core team.

49:04Alex: And there's a lot of patterns from history here. A big part of the success of Python is PyPI. That's not reviewed for code quality. There's no reviewer process for that. But they have, over time, had to add a lot of infrastructure to be able to handle these malicious attacks and rollback packages and patch things. And plus the infrastructure cost of hosting PyPI, that's been a whole business model that's had to be solved as well. So

49:10Mehdi: Yeah. Yes, that's true.

49:31Alex: I think there's a lot of learning we can do from PyPI. But that overall model of sort of being very open with what plugins are allowed is, I think, very appealing.

49:41Mehdi: No. All right. One last one. To be again, a pessimist. I'm very sorry. I really didn't do on purpose. I promise next time I'll have more fun, optimist blog. But here it's about mental health when using AI leads to brain fry from Harvard.

49:47Alex: Hahaha!

50:01Mehdi: And again, it's already a blog from March. A new study finds that certain patterns of EI use are driven cognitive fatigue while others can help reduce burnouts. And I think also next to that, was, I had two things. again, Lenny podcasts, shout out to him. And it was from Simon Wolleson that was on his podcast and said that, sorry, to quote him, that it's using 100 % of his brain and it's really tiring. So he was also recognizing this. Have you experimented such a fatigue since Modalive has been ramping up on using AI? And I'm curious if you have to use Giz. I don't want to go into the details of our articles where it can help you reduce burnouts.

50:58Alex: I think I have had that a little bit. think the analogy I just read yesterday that I thought was funny was that Claude code is Farmville for developers. It's like a hobby thing where you have to constantly check back in and tend this garden. And that kind of constantness, I think is a part of it. I have seen, I think it's gone in cycles where like, depending on how busy my week is in other areas is how much I can really plug in and keep the agents working in the background. I that's sort of like, there's been an ebb and flow for me where I have had to take some break from it and say, you know what? Tonight, I'm gonna go to sleep early and I am not gonna kick my agents off overnight, right? So.

51:48Mehdi: Yeah. Also the app, like Cloud Code Remote and so on, that's super vicious. Yeah, it's great. It is great. But again, it doesn't help you to make good breaks, especially if there is a tiny ask, right? It's like...

51:54Alex: I like it, but that's mostly... You're right, it does not, but it does help if you're standing in line somewhere, you get to feel productive and do something. I think since Claude released auto mode, I've felt a lot less pressure. I used to really have to be allowing a lot of things and really steering and directing a lot. And I think things have improved there. I have some other plans around, I want to set up like a workstation that has very limited credentials so I can start to do the dangerously skip permissions a little bit and go full auto. So that's part of my answer to this is,

52:30Mehdi: Yes.

52:36Alex: set up the guard rails in such a way that I am more comfortable delegating more control. And that I think will reduce the weight I feel.

52:46Mehdi: Yeah, have a bit roughly the same. I think for me, it's also the constant switch. you mentioned that earlier, the only bottleneck, right? And it's like... Or no weights I don't have. Like I cannot understand people having like 10 saying they have 10 agents running. Okay, if you have a repeated task, which is deterministic, like, you know, do a research about specific topic and then make decision. You can say, yeah, this one is running every day, but I'm not interacting, you know, steering. I'm just consulting the input. But I think if you're really building with agents, three to five is maximum. I do see some people having creative things with agents, monitoring other agents and so on. yeah, it is exhausting and I I burned a lot of tokens for nothing. And I guess you too, and guess anyone listening, don't be honest with yourself. Did you?

53:52Alex: I think that's very fair. There's a lot of forces there. I think that the... you know, the context switching is real because if the bottleneck is humans, we have to go back to what makes humans work effectively. And in many ways, multitasking is not a strength of the human mind. So how do we reduce context switching? Some of that is as models get better, they can do tasks for longer. So we switch back and forth less often. I see that as one path. Some of it though is just the domain you're in. You know, if you're in a domain where it demands exact perfection, you're gonna have to read every PR. Whereas if you're doing something that's, know, something that's more, sometimes visual things can be a little bit less precise. If it looks good, that's good. It doesn't have to be every pixel. So there's varying levels of like, you know, how much you have to double check things. And that might control a little bit about how many things you could have on in the background.

54:25Mehdi: Mm-hmm. Yeah. All right. We are at the end of this episode. Again, if you want to check out the channel notes, go to motherdelac.com slash explain, iPhone analyze, and, ⁓ you can have all the links and the summary of our discussion and I'll see you in the next one. Alex have a great day.

55:03Alex: You bet. Cheers, folks. Happy analyzing.