B (6:06)

Yeah, and it's I, and I love the title, which I don't know that we've actually said yet, which is Vibe Coding Kills Open Source, which is quite provocative when you think about it. And all the components of the title are provocative. I mean, Vibe coding, there's been all sorts of commentary for it against and, you know, trying to understand it with Open source being very foundational to software coding for the last, you know, three decades at least, and most commercial packages having various open source components to it with. But, but that isn't. That is part of a conversation that I know I've certainly had with other people in terms of at this point with these tools especially, you know, you mentioned Claude code, and I know that's probably the most popular coding tool recently. I certainly use it. And with Opus 4.5 that came out in November, that really kicked off a lot of innovation. I think a lot of us that do code ourselves are wondering why, you know, I can just go do exactly what I want or I can take existing software and make alterations and stuff with, you know, how. How should we be thinking about Open Source in this new. With this new paradigm of, of Vibe coding or, you know, it's becoming, you know, kind of a, you know, prompt engineering for software engineering, whatever you want to call it. There's a bunch of names coming out now.

C (7:38)

Yeah, yeah. So I think. And we got a little bit of heat because of the title. I think in I' academia is quite conservative and this sounds like a clickbaity title, but to this my replies that it's not clickbait if it's true. But of course, let me explain why we think that it's true. And we thought about every word we discussed in detail. Is this the correct word to use in the title? And I agree with that. Sentimental. Vibe coding has this negative connotation, but that's, that's the word that people use. So let's just stick with that. And so the way we approach the problem, at least at the time, there was very little data. Now that we have more data and we have done some new empirical analysis as well, looking at data, but at the time we were just thinking like, how would an economist approach this problem? And the way I think about economics, and this may not be the canonical undergraduate economics textbook, but that's what I kind of think that the three main pillars of economics are. One is that people respond to incentives. So whether it's monetary incentives, so they want to make a good wage, but it might be other incentives as well. So in open source it's typically not, at least not directly, some payment it could be kudos if you like that. You know, it's good to fame or it may just be like a good feeling of solving other people's problems and sharing your solution with others. And that's also, you feel good about yourself and feel good about helping out others. That's also an incentive. So economics can also talk about that. It doesn't have to be money that's involved. The second pillar I would say is that the economy is a closed system. So you, if you take away something here, you have to just basically have to make sure that things add up. So I think when it comes to AI, one thing that is a very scarce resource I think is human attention. So this idea that AI is going to take over everything and it's just going to infinitely produce stuff, including software. I mean, it's getting better and better of doing that longer and longer runs for AI agents. But ultimately there has to be a human who instructs the AI and who reviews the result. And so there is this attention. There is a very limited resource. So if you turn this towards AI, you have to take it away from something else. And then the third pillar I would say is how these two things come together. So if something is scarce, there's very few of it in the economy and the price of it has to go up so that people can adjust. And so this kind of system thinking in economics actually helps us think about the open source ecosystem as well. Because here I think just looking at individual data sets or there are a lot of surveys about how people use AI, there are surveys about how software engineers use AI, but these are limited. Even if you do this on tens of thousands of people or hundreds of thousands of people, they don't necessarily capture the entire system of engineers and users and how they interact. And we saw that it's very important to capture that kind of interaction that as an economist. So actually all four of us are within economics. We are specialized in, initially specialized in international trade, which is fundamentally about this type of market equilibrium forces. But there, there are different countries that are trading with one another. And so here, you know, it's not countries, but there would be a software developer who's, who's building a software package and there's a user who is downloading the package from GitHub or whichever package manager. So we, and then we started thinking about it and we realized that we actually have the tools in economics to think about this and we just have to make sure that which of these apply to the open source sector and which of these are irrelevant. So we do think that the response to incentives is still very relevant, even though it might not be monetary. And so we identified that it's whatever developers care about. It's roughly proportional to the human attention that they get or the visibility that they get. So it might be that, and I understand that there are different types of open source project. It might be that the big corporation sponsors the project and it would be different. But say a hobby developer would typically be kind of happier. And actually even the corporate developers would be happier if there are more people using their product. For the hobby developer, it might be that it looks great on their cv, that they have fantastic contributions to open source and they might get a better job later, so maybe even earnings wise they can turn it into money, not just fame, but it might also be the kind of incentives that I mentioned earlier. But in any case, the more users they have, the better. So that's one key component of our theory of open source is that while it's easy to write just a simple project for myself and a dozen people, I'm much more happier if I can share it with thousands and millions of users. And so that's one aspect. And the other is that what is changing with AI is that the technology of writing software is drastically changing. And so that of course affects the cost of writing open source packages, of actually developing the software, but also sharing it with others. It becomes much easier. And if you think about it, these two forces actually go against one another in the following sense, that so if I have just an idea of a software package and before AI, I might not think that it's good enough of an idea or I might be bothered. Oh, I would have to pick a license and upload it to GitHub and write some documentations because they're going to be users who ask questions. And so all of these hassles, of course GitHub itself is, is responsible for reducing that type of friction for developers. So now a large chunk of open source packages are on GitHub, but with AI I think many of these costs go down and so it's much easier to produce open source. So this would actually probably create more open source packages than before, by contrast. And so this is where I mentioned the, this finite resource of attention. Every developer, but also users, they are kind of users of open source libraries as well. And so they either pay attention to the developer. So just let me give you an example, say in web development, and that's actually a kind of a use case that's perfectly solved by generative AI that, and you know, we might agree or disagree about different software use cases, but I think, you know, a simple front end development, it's almost 100% covered by recent AI models. And I can ask AI to build me a website with a number of features without ever looking at the libraries that are being included there, ever looking at their documentation. And in open source this kind of feedback is actually very important. Not just looking at the documentation, but if there's a bug then I can report that bug back to the developer. And so that type of visibility of the human behind the open source package is getting reduced.

B (15:49)

Yeah, I find that fascinating. I had not really thought about the notion of the developer's attention being a point of scarcity, you know, in terms of, of managing that. But that makes perfect sense when you say that, because I know that I would say everybody that I speak with regularly that is doing development, that is, that has become the challenge of, you know, they can produce a volume of code with the tooling these days, whether it's open source or whether it's proprietary, but they are still required. There's an expectation from their employer certainly of going back and validating and making sure that everything is correct and figuring out the bugs and stuff like that. And I think one of the things I'm curious about is how that plays in as we're talking about kind of that notion of what happens to open source from all this. How does that, like, what does that imply about the role of the developer going forward and the responsibility of the developer as you're looking, because you know, the volume of code from that, obviously the, you know, if there's a company behind the open source project driving it, they're trying to get a lot of users on board and stuff like that. But with these different incentives for different players in that, how does that play out? There's a complexity there that I think maybe I missed and possibly other people have missed too, that I think you're delving into.

C (17:19)

I think it's very important. And so you mentioned proprietary software and it's very important to distinguish between the two in that, of course, for proprietary software as well, people like to have many users because they mean paying clients. But the business model, and when I say business model, again, it's not necessarily money. But so the model of open source libraries is very different from proprietary. You can be a very successful proprietary software company with, you know, even if you don't have millions of clients, if you have like deep pocket clients, it's totally fine. But for open source you, you have to have like millions of users to, to be successful because kind of the margins are so thin. And again the margins. And there is a great study by scholars at, at Harvard Business School looking at the, the value of open source in terms of the value that it creates and the value, the amount of work that goes into it and the amount of work that goes into it versus the value that it creates. There's I think at least a thousand fold difference. So you know, in a business that would be like a huge, huge gap. It would mean that you cannot really monetize the value value that you create. So the only way open source can survive is if you have really, really big user base. And that's, and that's why I think this type of argument that with AI human attention drops, your user base drops. It's particularly aff affecting open source now in terms of what do developers doing and how are they. So when I talk about developer, I think of them as having two jobs in this model. One is to write code and to share their code with others. But the other is that there are all kinds of dependencies that you are using. So if you build a website, you go on to install a whole lot of JavaScript libraries and so you're selecting which of those to use based on your familiarity with the package or maybe you go and read the documentation. And this is the part that completely you can still instruct your AI to go with this versus that because you have stronger feelings about one library versus the other. But you could in principle just ask the AI to give me a website and, and it would. And so that kind of selection of libraries is actually something that we're looking at in the data now. By now I think we have sufficient data to try to tease out the effect of AI in. And we're actually looking at website development because that's something that's kind of easy to track. You can actually see what's going on on websites. There's this case of tailwind, tailwind css, which is a very popular CSS library. And so they had a tremendous increase in usage, a lot of it driven by AI agents, but also a very big fall in website visits. And then their particular monetization model really depended on website visits because they had some premium package that they are selling on the website. So if you don't show up on the website, revenue drops. And so that. So actually what we're doing in a new part of the paper that we're working on right now, we have some preliminary, preliminary results that I'm happy to share is try to see Whether this tailwind story is the exception or whether that's the, whether that's the rule across packages that are relevant for front end web development. And so we did the.

B (21:12)

Yeah, keep going, I'll ask. There's a thing that you have prompted me, but I'd like you to continue and then I'll ask afterwards.

C (21:22)

So here we actually did a controlled experiment. So that's of course one of the things that you do in science, but in social sciences it's very rare because how do you control the economy? But here we actually wanted to see what different AI models would do there. We can control because we can really instruct the AI models. So what we did was the following. We took 100 websites. It's actually a representative sample of very popular websites out there. We described what they do, the use case with a product requirements document and we actually checked, or we asked an AI model to check that there are no mention of technology in there. So it's kind of functional requirements or performance requirements, but no mention of any technology, any brand name. So we have basically. But you should think of say banking websites or car dealerships. So the most popular, most heavily used websites, E commerce, health, all kinds of different websites. And then we asked various AI models across different families and different vintages to try to build that website from scratch. And then we looked at what is the. And really the only instruction we gave is that you have to use NPM to install dependencies. Because it's. Yes, there are others, but I think it's Fairly universal for JavaScript dependencies to be installed via NPM. And basically as soon as you install everything that you need for your website, we actually pull the plug. And then we looked at like what are the dependencies that the AI model wanted to install. So we already did this for seven models. So now, you know, we could have 700 different websites. But we actually pulled the plugs. I think we do want to do want to build some of these just to see kind of how different they look from the actual websites that were the seed of the experiment. And then for every model, we know when they came out, like when they were released. So we could see. And there's a lot of correlation, of course, so tailwind is very popular across all these models. So it's almost universally recommended to be included, but not. So some websites need a calendar, some websites need a chat box or a map. And so these features are different and the different models have different opinions about this. And so we could track kind of how when a certain model started recommending a package. And then we look at two outcomes that we can actually measure in the data at the weekly frequency. We could go deeper, but I think weekly is sufficient here. One is downloads from npm. Were these packages more frequently downloaded? And so that of course would include the demand generated from, generated by AI. AI models just go and download these packages. And then the other metric is stars on GitHub, which we think of as a proxy for human attention. So you really like a package and say, okay, I really want to engage or at least just show that I like this package and I make the effort to go on GitHub and give it a star. And so what we find, actually it's very much in line with the predictions of the model. The first one may not be very surprising is that as soon as more and more models start recommending a library, for some of the 100 use cases that we have, downloads go up. So for every additional use case for which there's a recommendation, downloads go up by like 3 to 5 million per week. So it's a pretty, in terms of percentages, it's something like 3, 4, 5% of weekly downloads for the typical package. But by contrast, what you see in stores is that they often actually go down. So at the very least they don't go up as much. They either zero or they actually fall. So for packages that kind of become very, very wipe coding friendly, at least the mechanism and the model is that you divert attention from humans towards the machines. And so the machines are downloading, but the machines are not interacting with the developer on GitHub. And so that, that already seems to be. So this is data for basically 2025, where I think a lot of the agentic software revolution was happening. And so already in the first year of that, you can see this effect.

B (26:01)

I'm curious if you extrapolate out the use of agents selecting these different libraries for inclusion, especially since you very specifically did not constrain that in the prompt up front, you gave it the choice of doing that. If you were to kind of take that out to the extreme case is there given the fact that a lot of the, the, not only the libraries, but a lot of the tooling, you know, the, the very notion of version control and such are really human constructs that, you know, we, we humans historically are trying to deal with complexity as we're writing code and we have created all of these ecosystems of toolings and libraries and stuff. You know, you mentioned tailwind. You know, tailwind exists because it makes it easier to implement CSS for a developer and it's very friendly, I've used it myself a lot. But you can look at all of these different tools and libraries out there in the same way. Is there a case when you're, when you're assuming that you have kind of unlimited prompting available to you on a very high capability model with agents such as, you know, OPUS or something, is there in the future, is there a need to have libraries in that, you know, when you talk about open source and you know, going back to the title, is there a reason that the model needs to use a tailwind and other, you know, other capabilities to integrate in with it rather than just construct it based on those functional requirements up front? Yeah, like what, how does, how does the notion of using these existing things that humans created already versus the AI just going and saying the functional requires this and you know, here's all the requirements I've been giving. I'm just going to produce what, what it is from scratch without the notion almost as disposable code. Because if you needed to make a change, you might potentially just do it again. Assuming that you can get some consistency.

C (28:09)

Yeah, that's a great question. And so I can reflect a little bit on my personal experience vibe coding while I'm doing scientific computing. It's a very different, I spend a lot of time instructing my computer but it's of course very, very different from what it looked like say two years ago and, and it's not so much. So for me personally the big difference in how I program is not so much that, okay, now English is the programming language. I think it's actually, it's strange at first, but it took me like two weeks to get through that. Then it took me some more time to realize that structures are still quite important. So you cannot. And this might change with different, different generations of AI models. I remember it was say about two years ago, so it was more the tap completion era and not the fully agentic era. But it was an aha moment where I was working on a scientific paper and I started writing some code in Julia, which is a scientific programming language. I love the language because it has a very good high level interface. So you can, it's very easy to get started as a scientist who knows little about programming. But it's also a proper programming language with all the right abstractions and tooling. And I set up, I wanted to solve a problem and I set up the function properly and as soon as I typed out the full signature of the function, I gave it A proper name. So a lot of scientists, when they engage in scientific computing, they would be very sloppy about these things. I'm going to call my variable X, my other variable Y, and these kind of things. But these were like, you know, the function name was a verb. There were meaningful arguments. They had different types, and they were. The types were declared, which is optional, but, you know, I thought I was going to declare, you know, what I'm expecting. And as soon as I finished with the first line, Copilot wrote the entire function in like one shot. And it was perfectly fine because it understands what I want to do. I didn't even give any instruction. I just had to push that it understood what I want to do by kind of looking at the names and the types and figuring what the types represent. And then so this is going to be a binary search problem. And so I'm going to have to do this and immediately figure this out. And so the way I think about AI in, in software, but I think in a lot of other use cases, definitely in science or other knowledge, work is more like a very, very capable, very fast coworker. As opposed to some machine or some tool. And I think that's still a little bit hard to get used to that. So in science, there's a lot of discussion about how to use AI, how to be efficient and increase your productivity by using AI. And I feel that some of the discussion is misguided, as if it were like, can you share with me your skills for writing a research paper, running a statistical analysis? And so you basically, it's like your colleague, like, should I share my skills for talking to colleagues in the coffee break? No, you just walk up to them and you tell them what you're working on, and hopefully they're going to have some useful feedback. So it takes some getting used to. But I think that type of. And of course, much like if you're working on a project with the colleagues, if you have good structure and good coding practices, it helps you collaborate. And so if anything, I think the importance of, of maintaining good structure is more important than before because you have a very effective colleague who can immediately do what you ask and give you feedback. And the better your practice is, the more you can get out of them,

B (32:30)

so that it enhances that collaboration and communication between you and your AI colleague, in this case, in terms of being able to have those structures that exist for the community versus everything from scratch. Am I understanding you correctly on that or.

C (32:46)

Yeah, I would think that this is primarily a kind of a collaboration Problem. Now the question you asked earlier, so maybe there is the next level where a lot of the work are done by AI and maybe they don't need these type of interfaces and maybe they would maybe just write things from scratch. Yeah, sorry. I started saying what is the. So programming in English is kind of weird at first, but you can get used to it. But what took me more time is the type of programming that you are mentioning, like throwaway code. Typically think of I have to design the thing and then am I going to use it two times? Then I'm not going to abstract, I'm not going to write a function or do a bigger abstraction, I'm just going to write it. Am I going to use it 10 times? But with Genai you don't need to do you solve a problem. And in like scientific computing, I think that's actually a good practice to just, you know, go. It's very iterative process. You never know what the data is going to tell you. Let's just try to do this and then if you're kind of happy with the result, okay, can you save this as a skill? And so now you have a computer program and then if you do something very similar the second or the third time. One of my secret problem that I use quite often, several times a day is just the following. Do you want to update your skill? It's okay to say no. And so quite often the agent would say I'm fine with my current skills, but sometimes. Okay, so in the last chat I learned that you like it this way or that way and would update how to approach that particular problem. So this idea that you start with a very concrete implementation and then you kind of generalize from there is I think very new and, and I think it could have this effect. What you're saying that besides a few core libraries that you don't really need anything else. And it's kind of similar to how these agentic harnesses have evolved. Like what can you do with the model? I remember when there was the MCP fashion I really want to get into MCPS because they sound like really cool and it would be so useful for me because I use all kinds of different tools and if only I could orchestrate them all at once. And then this was actually before I started using CLAUDE code and then I realized that I'm actually using the command line a lot of times anyway and you can do everything on the command line so it might be a little bit inefficient. So now I basically don't use Any mcps at all. You have a command line client, just figure out, you can ask for help, figure out how to do it, and they would do it. And so that could be kind of a next level of agent programming that these agents have. I mean, they would still need a handful of tools, but it doesn't have to be, doesn't have to be a lot, but then they would have to be really, really properly maintained to make sure that. So that's one issue with open source is that if we froze everything like today and nobody ever contributed to open source anymore, it wouldn't mean that we are staying stuck. It would mean that it declined. So you need to maintain it because there are unknown bugs, there are vulnerabilities. And so it's a very complex. I mean, ultimately every software is very complex. And if you don't know about these vulnerabilities and there's no one to fix them, then the quality of open source would decline. So that was kind of the motivation for us to be, you know, kind of a little bit alarmist when giving a title to our paper.

B (36:35)

Yeah, well, you know, and you, you produce this paper at a point when really, you know, every organization on the planet and the people that work, both the, both the technical staff and the, you know, management of each organization is trying to wrap their head around this, you know, really rapid change that's happening and figure out the implications. Do you have, do you have any thoughts on how people should be thinking about this? You know, as they're looking at, you know, they're trying to figure out what they need in terms of programming staff, and we've seen some companies announcing layoffs and, you know, going through that. That's in the news. And others are only maintaining their senior staff. You know, and a lot of the college grads these days are struggling to get into jobs and people are trying to understand how does this fit? If you look at the last 20 years, and I'll just kind of make up an arbitrary example, it's very common for organizations to be participating in and building on open source as a foundational material. But given this relationship dynamic that you've just described in terms of how things are changing, if people that are watching this right now or listening to us, you know, how might they be thinking about this? Based on what you're looking at, you know, right now, like, what. What changes would you say? You know, what, where are they falling behind? And what would you say? And I'll let you take that any way you want, whether it's from A managerial perspective, a developer perspective, a product perspective. I'm just curious what your, what your thinking is on this.

C (38:16)

That's a very broad question about kind of AI and the labor markets. Let me begin with the software part, because there I think at least we understand what AI is currently capable of, and it's very capable. So I think if we understand how this works in software, I think it helps us understand maybe the other parts of the economy as well. And so the way I think about software engineer's job is that there's at least three different things that you should do as a software engineer, maybe with different degrees, and maybe you can add some more. So you need to understand the user and maybe it's not in the same person, so maybe these are different people in the company, but so you need to understand the user needs and kind of translate them into, not necessarily actually decided, not into a program yet, but just to kind of figure out what they really need and kind of what's feasible and what's not feasible. And then kind of designing a system, the different components and how they come together, what are the relationships, and then finally writing the actual code in whichever syntactically correct Python. Cool. And I think this last part is basically out, like it's 100% automated. It helps if you can still do it and review code, but I think the fact that it's out doesn't mean that, you know, software engineering is over because I think the first two are actually not very easy to do. If anything, they are harder to do. And of course, with more and more capable models, the design, you could sometimes let the AI do it. And they can. I mean, one thing is that they will almost never say no. So they always pretend to complete a task, but it might not be a design to your liking or design to your specifications. I think the thinking part you cannot really get rid of, and I think in particular the interaction with the users and figuring out what they really need. So the AI can build you a website, not like what should it build, it can be build any website. So someone should really figure out what are the things that are important and that are not important. Now the challenge, I think, which is, of course, it is still a. So I'm kind of optimistic in the sense that I think of AI as a tool that augments productivity of knowledge workers and not really replacing them, because I do think of knowledge workers as more than just translating into, you know, syntactically correct Python strings. I think their primary job is to think. But there's a Lot of bundling in school and also in jobs that we think you're a good developer if you write good Python code or we teach programming in various programming languages. I think it would be really, really interesting to think about how do you teach programming when the programming language is English? Because I still think you need to understand this computational thinking to be able to interact with your AI agents. So it's not a very concrete forecast or recommendation, but at least in spirit, I'm optimistic that I think we have, and this is my trade, international trade economist speaking. One of the key results in international trade is the result of comparative advantage. And that goes back to David Ricardo, that even if you take two countries and even if one country is absolutely more productive in everything that they produce, you can still gain from trading with them. You just do what you have relatively more advantage in, even if you're kind of absolutely disadvantaged. So even if AI can do everything better, we can kind of exploit. And I think the thinking part would always be, will always be a human comparative advantage, even if AI can do a lot of thinking itself. And the reason why this comparative advantage story is important for AI is exactly the resource constraint that I mentioned at the beginning that I could ask Claude to build me a website and it would go on for a day and build me whatever, but I would have to spend my own time to look at it, think about it. And so it's actually not a good use of my time if I don't spend it thinking. And I would trust Claude to do the thinking. So in my scientific computing, actually my work has changed a lot. I do more computing than before. Almost no writing of code, like practically zero. I do a lot of thinking and actually decidedly on very analog tools like pen and paper or, you know, I went back to reading books about the different methods to kind of step away from the computer and think more about the problem. And then just kind of, because also the translation barrier has, has practically disappeared. So if I, if I can kind of semi coherently talk, talk about the, my ideas that I came up on a walk in like a 15 minute voice recording that's good enough to turn it into working code. And I think what we should be doing, and this is what I tell my fellow scientists as well, when you're asking how should I work with AI? Well, you should figure out, try it and see how it works and then try thinking about what is it that you want to focus on. And you can basically outsource everything else to at least a lot of the tasks you can outsource to AI, but doesn't mean you should outsource everything. So kind of keep, keep the core scientific activities to yourself.

B (44:25)

I think that's great advice. I guess as we wind up here, I am curious, I'd like to ask you to step out of the firm research that you've done so far and kind of think a little bit about where, you know, unscientifically, you know, just speculative, you know, when you're, when you're kind of done and you're thinking about the future, what are your thoughts on where things may go in this and what might evolve and recognizing that this is purely prediction and may not play out that way. But I love to hear kind of what your personal view is, you know, about where things may go in, in terms of things you've not yet had a chance to research and maybe things that, that evolve that you don't even know that you would be researching yet. Just kind of playing out the timeline a little bit to some arbitrary length. Can you share some of those thoughts?

C (45:18)

Yeah, I think one. And so my thinking is still very much influenced by being an economist, but these are not research projects. These are like vague ideas of thinking about the future. These are really, really exciting times to, to be an economist as well. Because these are kind of big systemic changes. Like, you know, we've had this type of technological changes, but not as rapidly. And that's really, really fascinating to live in and think about. And one thing that I haven't seen, I haven't really seen mentioned a lot of time, but I think it's a very important feature of at least the current flavor of AI is that it can be very localized. So by now you could actually buy one of these fancy boxes that have a very high performance GPU in them and it would be not much bigger than a laptop, maybe it would be a little bit thicker and of course it would cost much more. But like no Internet, nothing. And it's actually already good enough to run fairly good open source models which are not state of the art, but they are basically of the same quality as like the state of the art was last summer. And so I really like to think about how much different that economy could be when everybody has kind of knowledge locally available to them. Because a lot of the digital economy is really built on platforms. So like Google and Facebook and similar companies and they made a killing of just making sure that everybody's connected to them. And they are kind of a gatekeeper and if you have to go through them, they set whatever price they want. But I think this force of intelligence becoming very, very cheap and even locally reproducible is a force that goes the other, goes the other way. And that could be just completely rewriting what we now understand about software, digital economy, knowledge industries, basically the entire economy and society.

B (47:39)

That's a big way to end right there. That's so really, really interesting conversation. Mikalush, thank you so much for joining us today. Hope that as you continue to research these areas, you'll come back on the show and share some of the ongoing research that you have in the future. But definitely given me quite a lot to think about and some new angles on that that had not occurred to me before. So really appreciating that economic lens on, on this, on this topic. So thank you so much for joining.

C (48:16)

Thank you for the opportunity.

A (48:23)

All right, that's our show for this week. If you haven't checked out our website, head to PracticalAI FM and be sure to connect with us on LinkedIn X or BlueSky. You'll see us posting insights related to the latest AI developments and we would love for you to join the the conversation. Thanks to our partner, Prediction Guard for providing operational support for the show. Check them out@prictions guard.com also thanks to Breakmaster Cylinder for the Beats and to you for listening. That's all for now, but you'll hear from us again next week.