We are a data informed business. We are not a data driven business. We believe that product decisions are extremely strategic and closer to art than science. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldeboz. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Hello and welcome back to the Piewites podcast, episode 133. This week, Robin, one of our coaches, takes over, and he has Will Rafaelson on the show, and he is a principal product manager at Prefect. They talk about his use of Python Prefect as a workflow orchestrator, how it works, how it handles failures, and they go, yeah, pretty much into nitty gritty. Very interesting. But they also talk about open source and business and how to combine the two and tips for starting an open source business. They also touch upon Marvin AI and its relation to prefect and how it's a nice way to start with Python. And of course, as always on our podcast this year, wins and books. I really enjoyed this conversation. Gave me a lot of insight and inspiration. Hope it does so for you as well. And now, without further ado, I'm handing it over to Robin and Will. Enjoy. Hey, Will, nice to meet you again. Hey, Robin. Yeah, great to talk to you. Thanks for having me on. Good, good. Yeah. How are things going? How have it been? And were there any wins in the last weeks that you could celebrate? Yeah, things have been going good. You know, my answer to wins is actually related to how things have been going in the last week. It would be very easy to talk about a revenue or product win, but I actually want to talk about a squishier win, if that's okay. And that's a win related to people and process. I don't really like talking or thinking about process in particular. It tends to feel like it's all just opportunity cost. Let's just shift code, let's shift features. But I do feel like in the past few weeks, we've hit this really nice stride with our people in our process. We've got three new fantastic engineers. Shouts out to those folks, and, like, our size is just one, where we've got a very lightweight process where, you know, we do these six week pushes where we have no stable teams. Right? You. You come together on what we call like a raft, three or four people, you bang out your feature and you have two weeks to cool down. That might be backlog work. It might be, you know, it might be kind of polish on the feature that you just shipped. And, you know, process working is always something that is kind of a fleeting point in time, right? You figure out there are some breakdowns, a process breakdown, and you figure out you need to add process. And so you overindex, and all of a sudden things feel heavyweight, but then your team grows and for a moment it feels perfect. And so I feel like right now I'm in this perfect moment in terms of like the size, the people and the process we have in place. And so that's my win for today. Nice. That's something I can really feel, I mean, related also, having worked in startup environment for a while, and it's always, you're always trying to surf on one wave as long as it's good, and then you know that at some point you need to change it or whatever. Yeah. So nice. Yeah. Also, I had a couple of recent wins, I would say one of them being that I finished a book, actually, I read, which fueled some more inspiration. And like a couple of weeks ago, I also met Sebastian Ramirez and others on, on the first fast API meetup in Berlin. So that was a quite big one, actually. Yeah. Was his mustache as awesome in person as it looks online? Even more impressive, I guess. Even more impressive. That's great. I haven't run into him in person yet, but we pass each other on LinkedIn, obviously, we're huge users of Fastapi, which I'll actually mention in a little while here. Nice, nice. Yeah. So I can just recommend for anyone who is listening as well, go to these meetups. I mean, we are all happy working remotely from home and so on, right? And coding is good. We want to be efficient and productive, but for me, it really significantly boosted the inspiration, motivation and so on. Was already good before, but it's just nice to meet kind humans and builders, with that being said. So you're the head of product in prefect right now. Do you leverage Python actually, or like in your function as a head of product or are you very far away from Python at this point? Yeah, no, I do leverage Python, and I think my dominant use of python is maybe in some level not that relatable to folks. My relationship to Python or my primary use case right now is maybe not the most relatable, but frankly, I'm obsessed with our product quality and our product is a Python product. And so there's nothing that goes out the door that I don't use personally. And I try not to throw surprises. But I I am one for late stage feedback. It's the earliest time to give feedback that's not hard to change is before something goes out the door. I'm constantly using prefect to test new features and ensure that the quality is there. Then aside from that, I use Python as my swiss army knife. I need to make a SQL query and then join that. I only know how to train a model with this particular library. I'm a bad engineer. I use Python there. I also do a lot of administrative work in Python for the purpose of having reproducibility both in the form of maybe product or business analytics. But also again, in my role, product is a lot of different things, but in my role is the plow at the front of the train. I'm trying to remove obstacles for developers and designers and our execution teams, which means I focus a lot on releases and making releases go smooth, which often involves hitting our APIs to change account features or things like that. And more important than it being easier to use Python, it's the fact that there's an artifact of what I did so that if I mess up, it might not even be checked in. Honestly, there's no real natural repo for me to put this terrible script I use that changed something for 3000 accounts in our company, but it will be on my computer and someone can read the lines if there's any errors. Yeah, I communicate with a lot of restful APIs. I'm using Python for that. Unique to me, I think is that like, Python is actually the only language I've ever seriously programmed in. As someone who was never going to be a software engineer, every time someone was like, hey, rust is so cool, or JavaScript is so cool, this is going to help you in your next job. I was like, it's actually not. Python has what I need. Obviously when I need to do some UI stuff or some lower level stuff, I might go out. But the only thing I'm really confident in is Python. So if I could use Python for it, I use Python for it. Yeah. And of course pivots are the perfect podcast to say something like this, right? Because we are also mostly just focusing on Python because you can do a lot of things with Python infrastructure as code with Pulumi, data orchestration with prefect, for example. So you can really go a long way until you need something else than Python and maybe even you can prototype ideate mvp with Python. And then when you say, now I got some funding, I need to make it pretty and so on. Then you can always put some more JavaScript on top, or if you need it to get faster, you can add some rust under the hood also, and you can maybe better buy some engineers that really know their work. And we've made leaps and bounds in the front end frameworks as well in the past year. They're not called Pine cone anymore. I think they're called reflex. Now that is such a cool project. I talked to them a few months ago and there's work to be done and it's a transpiler under the hood. We're not completely loading JavaScript and HTML, but it is way better than the alternatives. And that was a long time coming. I love that team. Nice, nice. Yeah. So we have talked already a little bit about prefect, but some here may not yet know prefect. So question being what is prefect? Actually, yeah, for sure. So prefect is an enterprise workflow orchestrator for those that use python. And if you don't know what prefect is, you might also not know what an orchestrator is. And so I'm actually, I'm almost better at evangelizing the use of orchestrators than I am evangelizing in the use of prefect. And how I talk about it is like, for data workloads, whether they're ETL or analytics, machine learning, the path to production is one where there'd be dragons, there'd be traps. I tell this story where when I was working as a data practitioner, data engineer, data analyst, I would do something useful and I would show my boss, and my boss would punish me by saying, this is good, you should put it in production. I'm like, oh no, now I have to schedule it, create, monitoring, logging, observability. I have to make sure I don't kill the box. I have to make sure it's version controlled, maybe dockerize it. All of these things that are useful and cool, and I might like nerd out on them, but they're fundamentally not adding value to my business. What added value to the business was that first little thing that I did. And so the overarching philosophy of prefect is that with the path to production being oftentimes kind of boilerplate or undifferentiated work, we can do 80% of that for you, right? We'll store credentials for you, we'll make sure you could schedule it, we'll make sure that it's observable. We ingest logs, search over them. It's all these little things that would, that would take, honestly, hundreds of hours in both upfront cost and carrying cost. So that's kind of the prefect philosophy. What the hook is if you're a pie bytes listener and you really don't care about my product philosophy, it's an easier way to schedule stuff and collaborate on it. No more cron, no more sshing into boxes unless you really want to. It's just an enterprise scheduler. And I say enterprise, not that you have to be an S P 500 company to use it, but just that it is rock solid. The fundamental thing that we are is reliable, because what we're doing is we're supervising processes. We are orchestrating complex stuff. If it works 99% of the time, it's not useful. It has to work 100% of the time. So yeah, it's the golden path to production, as I try to put it. Nice. Yeah. And actually I also really liked the prefect when I started looking into the different options that there were back in the days. So we considered using airflow, for example, the other big player, or different other terms of all kinds of orchestrators. And what I really liked about prefect was it felt directly, really pythonic to me. So you just add a decorator, basically, and you get a flow or a task on top of a function that you defined before, and that's it almost. So it couldn't be much easier than that. And I think, especially nowadays, there are a couple of new things that have evolved over the time how you can use prefect that make it even more nice to use. I must say, I didn't work so much with any other orchestrators, so I have a little bit of a skewed opinion here, maybe, but that also speaks for itself. I use prefect coming out of the python realm, wanting to use something that is directly available in Python. It was good enough, so I didn't need to look further necessarily. Yeah, that's maybe also a nice way to approach it. Let's say if you're coming from the Python world, there are a lot of tools that you can just use in python that are good enough, and then maybe don't be too dogmatic about it. Maybe there are other tools that are even better that you can use when you scale the team further. But as you mentioned with prefect, I guess you can even go towards that space because it can grow with you. For example, I have now a small idea for a startup or an app idea running with prefect. And yeah, it's doing its job, it's consistent, gives us slack notifications. I can observe how the things are going. Sometimes something is breaking. Maybe OpenAI API is not stable again another time, and then you can just easily retrieve a task and so on. Yeah. But maybe from your perspective, how has prefect evolved over time? So I guess you have been there also for quite a while now. Has it been from your perspective? Yeah, it's definitely. No one would accuse us of evolving too slowly. As you know, there's new things and there's changes a lot, and we do our best to ensure everything is kind of backwards compatible. We have to, but we invent a lot. Like, we kind of, we cast a wide net and then the things that are landing are the things that we invest in further. And it's funny, I guess in some sense it feels like I've been here a while. It's been like a bit over a year and a half. Yeah, I guess startups kind of feel like dog ears. And before I joined, I joined right when prefect two came out, prefect one was an entirely different code base. And so there were some changes. There were like architectural and fundamental system design changes to prefect. But from a user experience perspective, the big change from one to two was this idea of dynamic workflows. And so what we mean by that is the dominant orchestrator paradigm for the entirety of the existence of orchestrators was focused on DAX directed acyclic graphs. And the fact was, the reality of the user experience was, if it can fit in a dag, you can run it, you can observe it, you can orchestrate it. And that works for a lot of cases, except, interestingly, for some of our favorite things to use in Python, which are things like if statements. So control flow, or for loops. And the reason that ifs and loops, you can't pre hoc or before you execute, fit those into dags is that the structure of the graph is not known until the code runs. So take a for loop, for example. If I say so in the dag world, if I say I've got three environments, dev, staging and prod, and I want to do something for each of them, it will be a graph with three nodes here, and then it will have the edges to the other nodes after that. But if I very simply just want to call an API that says, hey, what are the environments? And one day there's dev two for some skunk works project that somebody did, and you have four, then the dag, you cannot fit that into a dag beforehand because now there's four and you didn't know that until you ran it. So how would I design a graph for something for an indeterminate number of environments? And so we said, let's just figure out how to make that not matter. You can use if statements you can use for loops, and we will discover the graph as it runs. Now, that means the graph may be non deterministic, that has downstream effects. That's okay. As long as we can show people what that looks like and give them tools to automatically or otherwise react to the dynamic nature of those graphs, that's okay. And so today, people ask for features from prefect, one that were directly related to dodging the idea of dynamism. It was like, oh, well, we have this map path thing, how do we do that now? It's like, you don't have to use a prefect feature for that. You can just use a for loop, or you can just use a while, or you could just use an if statement. And so breaking the dag, as we call it, was a huge change. Just a few others. I won't waste your time evangelizing prefix changes, but I think one thing that especially after I came here, me and the rest of the tech leadership, we realized that orchestrators, so orchestrators are obviously valuable for scheduling, alerting and things like that. Orchestrators are really uniquely positioned vis a vis observability. There's a lot of observability tooling and a lot of observability tweets happening right now, data observability, data lineage data catalogs, observability of things like lower level compute metrics, Prometheus datadogs, stuff like that. But prefect watches, or, sorry, an orchestrator just watches everything in motion. And so we have all of this metadata about not just what the column was and what it is now, or not just how much cpu was used, but like, what processes were running, what functions were running, things that machine learning engineers and python people, I think, resonate with more than data columns and compute utilization. And so we focused really hard on making observability a first class citizen in prefect, introducing the idea of events as a telemetry type. So not just logs, but you can see events, you can react to them, you can look at a stream of events and what was producing them. And probably most useful is like, you see things and you do things, you do things and you see things. And so once you have subservability data coming in, you can tailor your orchestration business logic to react to those things, or in some cases, react to the absence of things. So like you said, the OpenAI API might be down or whatever. If you subscribe to their status page and an incident is opened and it's not closed in five minutes, well, then maybe you need an alert, you need to pause some expensive workflows. This idea of observability, real time, event driven stuff, that is a new frontier for. It's not that new. We've been doing it for about a year now, but that was a new frontier for us and some very, very smart and ambitious colleagues and I have been able to, I think, realize an observability vision for an orchestrator that's relatively novel. And if it's a good idea, it won't be novel for long, but I think it is still novel right now. Yeah. So it's also interesting to have the interview now and then maybe again in the year and see where things have evolved in that time. Yeah. So also maybe for listeners to visualize it a little bit, maybe we can give a simple example of how you could combine, let's say an event that triggers a pipeline, maybe even spinning up some infrastructure or so what happens next? Like what can happen wrong and so on. And how would all this look like a typical or not so typical, whatever. A lifetime of an orchestrated flow and prefect. Yeah, for sure. So first, just to define the orchestrated flow, what you've done is you've got this script that I made and I showed it to my boss and my boss said, put it in production. And I'm like, damn. But in the prefect world everything is actually great because all I had to do was add an import statement at the top from prefect import flow and task. And then I've decorated my main function with a flow decorator. And then any tasks that that main function calls if I want to, I've decorated with a task decorator. The more you decorate, the more observability you get. But if you want to run code outside of prefect tasks and flows, that's fine as well. And then we've set up an automation trigger, or, sorry, a deployment trigger. We've deployed our flow by making the prefix server cloud or open source aware of the runtime metadata that is required to run that code. And we've said, when you see this event, then run this flow. That's just the simple case. What happens is an event comes in and we are at all times constantly evaluating incoming events for their adherence to criteria that people have set. One common way for people to do event driven flows is we have native webhooks. I have just created something, let's say, where when this webhook pings, no matter what, run this flow. We're constantly evaluating all of the different webhooks, all of the different events that folks can send via APIs or that we're producing. We evaluate it. We say, this matches this criteria. It's what we call a trigger criteria. This automation system takes the event, it matches the trigger criteria and then it says, okay, next step. What are the actions that are associated with this trigger? And it runs this flow. Running the flow really depends. We try to be very non discriminatory across infrastructure setups. Being able to interface elegantly with exogenous infrastructure setups is very important to our product philosophy. You said maybe spin up some infrastructure. Maybe you have specified in this deployment where we provide that runtime data that you want to spin this up on your dask cluster. The dask cluster has to spin up the dask job. The dask internals are totally opaque to me, actually. Let's use the Kubernetes example because I actually know about it. So you've got a Kubernetes process that's communicating with the prefix server. You have specified that you want this flow to run as a Kubernetes job and you have the job specification specified in various places. You can do it on a flow, you can do it on deployment, you can have defaults within your environment. But let's say you just want to spin up a pod, you want to pull a particular image and you want to ensure that the job has a timeout of 3600 seconds, five minutes, and it'll retry five times. Prefect knows how to communicate with kubernetes to spin up that pod with the appropriate job specification, execute the code and then exit. But more importantly, it's what happens if it fails. Because if everything always went well in terms of execution, remote or otherwise, you probably wouldn't actually need a prefix. You could just use Cron. Because Cron is rock solid at scheduling work. As long as it goes well through the lifecycle of that Kubernetes pod, we're going to be emitting and harvesting events from the Kubernetes cluster. One use case that I really like here, and maybe why I steered us towards the k eight's example, is if something goes wrong in a Kubernetes job and you don't know how to exec into a pod, or that pod is gone, it's been evicted, python failures are not going to help you. The logs will just stop coming and you'll just see nothing. But because we can harvest during the lifecycle of this flow run, we were harvesting events, we would actually redirect the Kubernetes event stream to the prefect event feed or event stream. You'd be able to see, you wouldn't even see that it failed, it would just crash because we stopped communicating with that pod. You would see crashed the logs wouldn't help you at all. But the events there, we would have transcribed those events from kubernetes and you would see that the pod was evicted. From a higher perspective, I guess. The diagram here is prefect, decides when things should run and then it spins up, ad hoc, any of that infrastructure, and it monitors it to completion. And then if that fails we can restart the cycle. Failures are just another event and events can trigger things. You can see events. So maybe something fails and you get an alert, maybe something fails and you reapply your kubernetes manifest to ensure that it's pulling the latest changes. It's a sticky product in that once you do something and you understand the primitives, you continue wanting to do more. Yeah, nice. So I hope that gives some overview. Otherwise we will also link in the show notes, the links to prefect, with some simple examples and so on, and then you can actually just try it out as a listener on your own. Super simple to start and then I guess the sky is the limit kind of. You also just mentioned open source. So there's a paid solution and an open source solution, right? We often get asked also something that was discussed on the fast API meetup. How do you start an open source business? Starting something open source is simple. You create an open source repository and then you have an open source repository. But how do you do something open source and also earn money or get your coffee every day? Maybe you can speak a bit about the mentality there at prefecture, what is open source and what is paid and how that plays well together. Yeah, yeah, for sure. So there are a number of kind of face value benefits to having an open core product. We really value our community. You're never annoying us when you create a GitHub issue in our repo. The trust that we have in that community is just irreplaceable to the success of our business. And so we need that to be fully open to maintain that connection with the community and our user base. So having it open allows us to gather that feedback and we accept contributions. Obviously other people can create issues and close them and create prs. It's important for trust, I think. We are a user focused company, we are a developer focused company, and the fact is, on our self hosted offering, our open source offering, you can pull back the hood and you can figure out how everything works if you want. It was always, I think, important to, and I wasn't here when this project began, but it was always important for those getting that kind of winning the hearts and minds of a core group of developers to have an open source channel. But we also need to be a business. And so we wanted to ensure that we had the right place, the right point of kind of price discrimination or feature discrimination. So what you want to do right is you want to ensure that the paid offering is just good enough to pay for. That way everyone that really doesn't want to pay for it sticks on the open source and everyone that does want to pay for it. It feels like a low price to them and what we've landed on. And to be clear, there's no hard and fast rule here. We constantly have ideas of should this go on the open source or should this be in the paid offering? But the guiding philosophy is anything for a single person or a small team should be free. And then anything that really is business critical and it provides true value to your business. Can we have some of that value? We would like some of that value. And everyone basically, like users, our investors, the market, et cetera, like everyone basically agrees that that's a cool way to do that. And so we're constantly walking that line like we owe a debt of gratitude to our open source users. And also we need to grow. One example of something that would be an obvious decision though, is something like custom RBAc, like custom roles. I want to make sure that this particular person or service account that has access can only do these particular, very granular scopes. A, that's all governed on our servers. We don't have an open source way for you to govern authentication at all. And b, if you are doing that, it means that you are a company that is getting significant value from this product. And as such, we believe that we have a, a place on your budget. Yeah, sounds fair. And it's also, I mean, ideally we all would want to create products that are for free so everybody can leverage them and get the best products, right. But at the same time, getting some of the value back allows you to reinvest, right? So that makes the product even better. So yeah, at some point we all also need to earn the money and the bread. And I mean, in Pibeitz alone we had a similar situation, right. Bob and Julian founded it many years ago and it was a platform, you could log in, you could do the py bytes and so on. But then the PDM program was founded where you can build applications together with a coach, one on one, and of course, something like this is hard to do without getting remunerated for it, but it also allows us to do more of these podcasts, for example, or to create some programs or focus on content that we otherwise wouldn't have been able to do. So, yeah, that's, I guess, just interesting. Do you have any tips for people that want to create something like an app, a startup, or so how to start the open source community and how to grow this business model out of it? Or do you have to have a business model in the beginning because otherwise it may be not work and how to set this up? Or at least do you have some lessons learned in that regard, let's say, yeah, I wouldn't be too, too dogmatic about it. Like business strategy and startup strategy is so subjective. It's why I don't really read a lot of thought leadership on this stuff. I think if you're a developer, which is going to be the vast majority of the listenership of this, I just create the open source repo and worry about the business later. Put your product hat on, who wants to use this and why? Like right now, the developer tooling ecosystem is so good. I can think of so many cool things to do, and maybe that's all you want to do if you want to create a cool library. Don't even listen to me, just create that cool library. But if you do eventually want to turn that into a business, I would focus really, really hard on users, who they are, how big that population is, and make it not theoretical open source, the library. Talk to people. We connected on LinkedIn or Slack DM's and now we're doing this. This is an extremely generous community in terms of time. If you can see someone on LinkedIn that you think might enjoy your library, chances are, unless they're like super, super strapped, if you say, hey, I built this for people just like you, I'm not asking you for money, but I'm wondering what you think of it. Are you down to do a 30 minutes coffee and I'll walk you through it? You're going to get a lot of good responses there. I get those messages a lot. I respond to those messages a lot. So I hate being a guy that's like, just start, right? Because just starting is hard. We all have jobs, it's hard to find time, hard to find money. You might not even be technically mature enough to start that company, but I would say like the second and third steps will become fundamentally clearer after you take the first one. And so I think taking that first step is great. And just again, luckily the developer tooling environment is so rich right now. GitHub free private repositories, we've got stuff like prefix. Also I was talking about open source versus paid before. There's a whole cloud product that we have a whole tier of the cloud product that is free and extremely generous. You can start a startup with prefect as your orchestration backend. You can use DBT for free. I think these deployment solutions like Netlify and Vercel all have very, very cheap free tiers. And if you have to eventually upgrade to the paid tier on any of these, that is essentially a good problem to have because all of these should be well calibrated. That once you are doing successfully and you are making money, then your vendors make money. I do think it's easier than ever to start. It's going to get even easier and you should just do that. Yeah, exactly. And I think that's also so motivating and inspiring, also gives some hope for humanity. Right. We have huge challenges that we need to overcome, but the tooling gets always easier, so it's always easier to start something. And as you said, if the products are designed well, the prices are designed well, so that you only need to pay when you're already getting value from your customers, then I think everything can grow sustainably. And I think for you, as a head of product, is there sometimes the situation where you're like, oh, personally I want this feature, but then the whole community says no, and then it's like a tough decision, or maybe it's not a tough decision, it's very easy democratically, but yeah. How do you feel in those moments? Maybe do you have some strategies how to bring in both, let's say rational arguments and an argumentation and emotions. Right. Because I can feel that. I can imagine that instinct also sometimes as a valid source of information. Yeah, it absolutely is. And I love this question, and I'll speak only for myself and my product approach, but some or all of this does apply to the prefect leadership, technical leadership as a whole. We are a data informed business. We are not a data driven business. We believe that product decisions are extremely strategic and closer to art than science. That said, there is a type of science that we do, which is really the science that. It's more like the science that a macroeconomist does than a biologist. A biologist has two petri dishes. They can tell which one where the spores took hold in or whatever. But a macroeconomist uses empiricism and quantitative methods more in the form of like, evaluating empirically assumptions. So I'll start with a hunch that is, you know, people don't convert from open source to cloud. We should focus on cloud tier one to cloud, tier two conversions. To be clear, that's not a real hypothesis, but it's like I actually, any intervention there, it will be very hard to like a b test, like a biologist would. But what we can do is we can look for data that supports the underlying assumptions, which is how many people in our onboarding survey said that they came from open source or something like that. So it's not going to be this a b test, this statistical methods that you maybe learn in 101. But we try to ensure that our risks and our assumptions are reasonable in a mostly democratic way. And in terms of the community, I have to weigh the needs of the community in a balanced way, because fundamentally, the users that I'm building for, hopefully we're ten xing every year. So I don't actually have those users. I'm not talking to them yet. I'm actually more interested in someone that's not using prefect than I am the people that are using prefect. Sometimes it's a balance, and again, it's really hard to know what the balance is. I'm averse to being dogmatic about, yes, always listen to this community members thing there and only listen to investor advice here. It's a balance, it's an art. And luckily, I have very thoughtful and dedicated partners in the technical leadership of prefect that understand that this is an art and that we have to get there together. Yeah. Nice. Okay, maybe one or two last questions before we hit the time constraint. Let's say on the one side, in piboids and the PDM program, we always build apps. Of course, these days, also quite a bit with generative AI, the prefect engineers actually have come up with Marvin AI. So a framework which allows to easily create some AI functions and so on. Maybe from your perspective, what's your vision? Is there a vision you can share concerning Maven AI and prefecture? Is there something, how do these two go along with each other? Or is it just a nice side project because you also wanted to play around with generative AI a bit, yeah, all of the above. Let me start with a few maybe disclosures. So, for one, I don't work directly on Marvin, but I'm close enough to the product, the product lead for that. My colleague Adam Azam has got a specific vision. But also my second disclosure is around that we are early enough in this generative AI and LLM boom that we are hesitant to make strong, strong statements on opinion. What we want to do is we want to position ourselves in a way that this is very much a Jeremiah, my CEO piece of vocabulary, but we want right way risk, which is no matter which way this thing goes, we will be positioned to aid those that are generating value from the boom. And the philosophy around Marvin is not that different from the philosophy around a lot of other software, or at least the philosophy around prefect. The things that make AI valuable in software are a lot of the same things that make anything valuable in software, which can be kind of boring. So for example, you mentioned AI functions. We also have these AI models. Type safety is really, really important for using any output of a function or a method in software. But the response from an API is just Json. The response from OpenAI API or any self hosted LLM is just this Json blob. So how do you ensure that you can convert that JSoN blob into something you can use in downstream software situations? Well, right now the answer is you use something like Marvin. There are a number of different, again quote unquote boring aspects to this stuff. Data classes and type safety are one of them. The longer term vision is one in which it's not just AI bots that are enabled by Marvin, but it's AI workflows. Most AI use cases are not just going to be chatbots. As fun as chatbots are to get some speech written in the style of Darth Vader or whatever. That's not going to be a market changing technology. That's where prefect and Marvin really start to marry. We actually just released our first Marvin powered or AI powered feature within prefect, which is AI generated log summaries. This gives us for failed or crash runs. We'll generate a recommendation on what we think you might do, or an explanation that gives us a first person view into really, how do you use llms in software? This whole thing is that llms are cool, software is cool, but LLM powered software is still something that companies are really figuring out in isolation. And we see a lot of cool AI features, right? Like notion has AI features and like, you know, I'm sure my bank has AI features and all of those things are home world. And there's a challenge to taking the rich and interesting but unstructured output of these llms and turning them into things that can be useful in a scalable way. A million API calls, over a billion API calls over imposing structure and imposing predictability. That's always been prefixed thing, and now we're bringing that to the LLM space with Marvin. Nice. Yeah, that sounds really exciting. And also, if you haven't tried it yet, I highly recommend it. It's also a nice way, I think, to start with Python. So it's something that we even now do in the beginning of the PDM programs, for example, also in the initial program, because you also see just nice Python pythonic development. I would say you get in touch with the decorators, pydentic models and so on. So quite some new concepts, let's say, for a lot of beginner developers, and you can combine it with some fun LLM playing. Right? It's always interesting when the answers are not exactly right and a little bit often funny. So what's funny about that, just in terms of getting started, is. So I, I run a program at prefect, which is intro to technology for non technical employees, because I believe that everyone, like our recruiter, our HR people, our finance people, they should be able to explain at a coffee table what our software does. And the Capstone project is often like write a prefect flow. And I've always said I'll write the python so that you can just focus on getting into production with prefect. But nowadays I actually have Marvin write the python. So I just have them create function signatures and then they're like, wait, that's it. And I'm like, yeah, that's it. We just got the capital of the city that you put in. Now we can get out of production and run it on a schedule. Yeah, exactly. And I think that's really exciting because it brings also software development more and more close to everyone to leverage, because maybe a couple of years ago it was still harder to learn, but now with generative AI, with the descriptions that are sometimes awfully misleading, but oftentimes also good enough to help a little bit, especially when you add a coach. It should be really possible for everyone to learn enough Python to get started in six weeks. That's also what we are now doing with a program besides a typical J ust a couple of hours a day or even just a week, and you can already get started. And I'm really excited to see where this all is going, because I think Python is a great language to have this interface to allow everyone to leverage a little bit of software development and AI in the day to day job. And yeah, it's accelerating that sometimes a little bit worrisome. That's also coming to the end of the podcast to the book that I read about existential crisis, actually, or existential risk for humanity. That's the precipice. And I had it on my reading list for a long time, and now I finalized it, and it really gives a nice overview. I believe in what are the different risks that humanity is facing or can face potentially. Luckily, the most important risks are man made, so it's on our own hands, let's say. And I think with AI is also something like this, we need to develop it safely. If we make a big mistake, then it's potentially catastrophic. But at the same time, it opens up a lot of opportunities to accelerate the problem solutions that we have that are other existential threats, like climate change and so on. So, yeah, it's always, again, it's like a wave, right? You're trying to take the wave. You're trying not to take the waves that are too big. Maybe then you rather avoid this ocean and, yeah. To have a good surf, let's say, and bring this home. Yeah, yeah, absolutely. Our CTo, Chris White, would love that. He's a big surfer. He's out in the Bay area. Nice. Good, good. Yeah. What are some books you're reading lately, or any progresses on that? Yeah, for sure. So I don't read a lot of books professionally. I work really hard all day thinking about this stuff, and so when I have reading time, I mean, my choice is either read during the workday, which is generally not feasible, or continue thinking about stuff I'm working on after by reading those books. So it's relatively rare that I read professional books. I do read a lot of nonfiction outside of it, I will say I've read two things professionally that I think were useful, one of which actually is a book. So, for one, I revisited a series on the orchestrator, and there's a particular article called 28 dags later by a guy named Stephen Bailey. It's just a fantastic articulation of the issues that orchestration might solve in the future. So I'd recommend that. And I also picked up and have been referencing Joe Reese's fundamentals of data engineering. It's an O'Reilly text book, and that is very, very good. It's very straightforward. It's very accessible. If you have even a little bit of technical background. It is very plain text. It doesn't dig deep into mathematical underpinnings or too far back in the history of computer science. So I really like both of those. Yeah, that's what I've been reading these days. And then, of course, I scroll Twitter, and that's, you know. Yeah, that's if you're, if you're listening to the podcast and scrolling to Twitter, maybe just stop it and get back coding. Like, there's a lot of exciting things you can build and. Yeah, that's always a good reminder. Nice. Yeah. Well, it was really, really nice having you on the podcast. Do you have any last things to share or any further things to ideate? Yeah, thanks. No, no, thanks so much for having me. It was great to chat again. I don't. As I said, I like prefect, but I like an orchestrator more. As you dig into orchestrators, reach out to me. I'm on Twitter, I'm on LinkedIn. And if you do want to try prefect, we have a very generous free tier. And we have a free tier that I have licensed to make even more generous. So if you're hitting a wall and you want to try something that you don't have access to, that's my favorite type of request to grant. I will let you convince yourself that it is worth buying. So please reach out to me. Join our slack community. Any way that you can. Reach out to me, please do. I love to hear thoughts on prefect orchestration, data engineering, and the future of computing. Awesome. Sounds good. Then see you next time and have a good evening. Great, see ya. We hope you enjoyed this episode. To hear more from us, go to Pybite, France, that is Pibit es friends and receive a free gift just for being a friend of the show. And to join our thriving slack community of python programmers, go to pibytes community. That's pibit es forward slash community. We hope to see you there and catch you in the next episode.