Pod Insights Software Engineering Daily Pydantic AI with Samuel Colvin About this episode Python’s popularity in data science and backend engineering has made it the default language for building AI infrastructure. However, with the rapid growth of AI applications, developers are increasingly looking for tools that combine Python’s flexibility with the rigor of production-ready systems.
Pydantic https://pydantic.dev/ began as a library for type-safe data validation in Python and has become one of the language’s most widely adopted projects. More recently, the Pydantic team created Pydantic AI, a type-safe agent framework for building reliable AI systems in Python.
Samuel Colvin https://x.com/samuel_colvin is the creator of Pydantic and Pydantic AI. In this episode, he joins the podcast with Gregor Vand to discuss the origins of Pydantic, the design principles behind type safety in AI applications, the evolution of Pydantic AI, the LogFire observability platform, and how open-source sustainability and engineering discipline are shaping the next generation of AI tooling.
https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/11/Gregor-Vand.jpegGregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn.
Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2025/11/SED18883-Pydantic-AI.txt
Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected]
The post Pydantic AI with Samuel Colvin https://softwareengineeringdaily.com/podcasts/pydantic-ai-with-samuel-colvin/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.
Transcript 11,896 words · 3 speakers
0:00 Speaker 00 Python's popularity in data science and backend engineering has made it the default language for building AI infrastructure. However, with the rapid growth of AI applications, developers are increasingly looking for tools that combine Python's flexibility with the rigor of production-ready systems. PyDantic began as a library for type-safe data validation in Python and has become one of the language's most widely adopted projects. More recently, the PyDantic team created PyDantic AI, a type-safe agent framework for building reliable AI systems in Python. Samuel Colvin is the creator of PyDantic and PyDantic AI.
0:42 Speaker 00 In this episode, he joins the podcast with Gregor Van to discuss the origins of PyDantic, the design principles behind type safety in AI applications, the evolution of PyDantic AI, the LogFire observability platform, and how open-source sustainability and engineering discipline are shaping the next generation of AI tooling. Gregor Van is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.
1:34 Speaker 01 Hello and welcome to Software Engineering Daily. My guest today is Samuel Colvin. We're really excited to have you here today, Samuel.
1:42 Speaker 02 Thanks so much for having me. Yeah, really excited to be here.
1:44 Speaker 01 Yeah, so Samuel, you are, just to get this completely correct, you are the founder of PyDantic, is that correct?
1:51 Speaker 02 I am the founder of PyDantic. I have to say, since I recently moved to the Bay Area, people have started asking me for the first time, "Did you also create the library?" Which seems like a slightly weird question. I feel like I'd be a fraud if I was, "Created PyDantic, the company, running PyDantic, the company, and didn't create the library." But yeah, I created the original library way back and now run the company by the same name.
2:11 Speaker 01 Good, yeah. Well, I'm glad we cleared that one up at the start. I'm glad I didn't ask, "Did you only found the company?" So as we like to do on Software Engineering Daily, just getting a sense of where have you come from, from a developer's standpoint. I've seen on LinkedIn, you've worked through some interesting companies and I think really interesting to understand how Pydantic came about. We're obviously here to talk about Pidantic AI, but we're going to just hear about the story to this point in time.
2:36 Speaker 02 Yeah, so I was a mechanical engineer way back and then been a software engineer for since like 2014, worked in a number of different roles, ran a bootstrapped self-funded company before, but then started, I don't know, really got into open source like 2016, 2017 and around then type pins were just coming to Python and I guess 3.5, 3.6 and they seem really powerful, but it seemed to me then and seems still to me today, completely ludicrous that they don't do anything at runtime. As in, I totally understand the history of why that's the case. It makes sense once you understand that, but imagine week one of learning to code and you're told you're writing software, it's going to be interpreted by a computer,
3:18 Speaker 02 everything needs to be exactly correct. And then you're told, oh yeah, by the way, these type hint things in Python, although you might get a squiggly line, everything will initially continue to work when you pass the wrong types, you'll just get an error later on. It's completely weird. So it came from this like, could we, did it even make sense? Was it possible to enforce those types? It worked, it obviously worked spectacularly well relative to my initial experiment of was that possible? So yeah, that was like 2017 and then the library just took off. I mean, took off gradually, but relative to other open source I had done at that point, kind of took off.
3:52 Speaker 01 Yeah, I mean, it's had like, is this number correct? Like 300 million downloads monthly?
3:57 Speaker 02 Yeah, we're about 460 million downloads a month now. Just hoping to cross the like half a billion downloads a month.
4:04 Speaker 01 Yeah.
4:04 Speaker 02 Sometime, I guess, end of this year, early next year. Yeah.
4:07 Speaker 01 Yeah. And I mean, it's used by, I mean, if you just look at any kind of logo on the Pydantic website, like all the big, big, big people, everybody, Nvidia, Meta, NASA, yeah, everyone. So.
4:18 Speaker 02 All the companies who are writing Python and they're using it somewhere.
4:20 Speaker 01 Yeah. Is it fair to say, though, when it was introduced, like, it was a little bit controversial to introduce types to Python? Is that a fair statement?
4:28 Speaker 02 So, as I say, types obviously came to Python long after Python existed. They were there for static typing and for things like documentation, arguably. It was almost an oversight when they were created that they were left around at runtime. And I think there were those who wished they had got rid of them at runtime and stopped people like me doing odd things with them at runtime because obviously, once people like me started using them at runtime and once they were found to be really useful, it did limit how, what you can go and do with them in static typing time, right? There's a world where, as in TypeScript, they are not part of the actual language at all and you'll have much more flexibility about what you do with them. Because they're not only part of the AST, but they're actually there in the runtime.
5:11 Speaker 02 We can use them, but that has some constraints on what you can do with them, as I say, in static typing. But I think it's incredibly valuable, right? I mean, it's the only language where you can do this trick effectively. Pydantic is obviously not the only library that does it, but it's kind of the preeminent one, I guess, at this point.
5:27 Speaker 01 Yeah. And you mentioned constraints there. We're going to touch on constraints in a little bit, just sort of philosophy behind that. We're going to move on from pure Pydantic in a second. V3, where's that?
5:38 Speaker 02 The first thing to say about V3, because I know that obviously the transition from V1 to V2 was quite painful for a lot of people. We fixed a lot of broken edge cases that we should have fixed before V1, but we also probably made some mistakes in V2. The V2 to V3 transition will be much, much smoother. We will mostly be changing some config defaults that we haven't been able to change because we've been very careful about breaking changes since. And we can probably telegraph most of them. The biggest change coming soon in Pydantic is, I think we're going to call it struct. So it will be a new primitive type in Pydantic, probably used as a decorator. It should be pretty much data class compliant.
6:19 Speaker 02 But the big difference is that under the hood, the data will be held as a Rust type rather than as a Python type, particularly if you're loading the data from JSON or from a binary format. So we should be able to Get three X ish improvement in performance out of that, which will be significant. So obviously Pydantic is already very, very fast. It's 50 ish times faster than Pydantic V1, which was already faster than some of the libraries that went before. But there are a number of interesting things you can do if the data is fundamentally in Rust. One of them is go straight to a parquet data without ever having to go through the Python types. We also will have an array type, which kind of will go with it to allow you to basically define a table. That's probably the biggest thing.
7:00 Speaker 02 And then there were some other we're discussing whether or not we add a binary input type, which would be probably protobuff to make it very easy to basically serialize Pydantic models over GRPC or something like that. Not quite sure about that, but yeah, there were some cool things you could do if we remove those constraints. Obviously David Hewitt, who now does a lot of work on Pydantic is also the maintainer of Pyro three, the Rust bindings for Python. So we're kind of pushing the limits of what you can do with Python and Rust in Pydantic.
7:26 Speaker 01 Awesome. Yeah, very exciting. So yeah, hopefully for anyone who's seen Pydantic in the title of this and came to hear about that, then there you go. There's the update. So let's move on the kind of next, I guess, library product that came along was Logfire, I believe. And am I right in saying that also was when I guess Pydantic as a company got venture backing as well? Is that fair to say?
7:50 Speaker 02 Yeah. So we end of 22, beginning of 23, Sequoia wonderfully reached out to me. It wasn't a company before that. It was just me working on it. And so I started the company as I got the seed round. So yeah, raise the C brown beginning of 2023. So I had going back a little bit on Pydantic, like early 2022, I started working full time on Pydantic, doing the rewrites to Rust. About eight months into that three month project, I was halfway done, wondering how I was ever going to finish this Sisyphean task of rewriting the whole thing while it was blowing up in its usage in the background. So yeah, the first thing we did when we raised money was hire a team and go and. Release V2, which we did in the middle of 2023. And then we started looking around for what to build. And I had actually owned the Logfire domain name from like 2019.
8:35 Speaker 02 I had felt that logging, as I would have called it then, or tracing in Python was broken, or at least nothing like as nice as it should be. So we were trying to work out what we were going to build on the commercial side. And we settled on building this observability platform, which is now, is now Logfire.
8:50 Speaker 01 Awesome. So yeah, let's just, as you say, it's observability. Let's just take sort of five minutes on. You've kind of touched on it, but what is Logfire? How does it work? Why is it there?
8:59 Speaker 02 It exists because I wanted the experience of instrumenting your Python application to be as simple as writing the rest of Python. And OpenTelemetry had come out. OpenTelemetry is a wonderful open standard for doing observability. It means that there are SDKs out there for every language, basically, that you might want to use. And there was things like the OTAL collector that can like proxy the data, spin it out to multiple different backends. Almost every platform out there supports OpenTelemetry now. The problem was that they made this pragmatic decision early on in the development of the SDKs to have the same API in every language. And that makes a lot of sense in some ways, but it means you can't do all the neat things you can do in Python.
9:41 Speaker 02 And I think it's also fair to say it's sort of managed by teams within the hyperscalers and the big observability companies. There's never been anyone else who has been particularly interested in making it easy to use as a library. And so the first thing we have is Logfire SDK, the pip installed Logfire, incredibly nice experience for tracing. I think it's fair to say the nicest way of doing tracing in Python. That's just emitting OpenTelemetry data. We do some clever things to make it better than normal OpenTelemetry. We allow you to serialize a Pythonic model or a data class or even a date time. And we'll record data about that, which isn't supported by default OpenTelemetry.
10:19 Speaker 02 And then the commercial bit is the LogFire platform on the backend, which is a closed source observability platform, which is what we charge for, although actually we have an amazingly generous free tier, possibly too generous, but now we've made it. I think we're not going to change that limit where you can look at your logs or your traces. And we technically, it's all tracing data, but we make it look, it feels like logs. It's instant. They'll come through as your application is running and then you can just basically click expand to dive into what's going on within a particular task or HTTP request or whatever else. But we also do metrics and logs. So we have like full observability. I think the other thing that has changed, there were two other things that I guess
10:59 Speaker 02 make LogFire unusual. One, we let you write full SQL to go and query your data. So it's ultimately an analytical database with a nice UI on it and an SDK and all that stuff. That's useful for developers who want to write some SQL. It's easier than having to learn a new DSL. But the really powerful bit is AI's love writing SQL. So the single best, they call it like AI as an SRE. And there's a whole, a whole industry of companies trying to do this. Honestly, the best experience I have seen for that is connect Claude code to LogFire via MCP and ask it, go fix a bug or go and investigate the slowest endpoints or go and find out why my users are churning. And suddenly Claude code has visibility into
11:43 Speaker 02 all of your actual application data and it can go and investigate. And so that's an incredibly nice for us outcome of supporting SQL. I don't think any of us knew that's where AI was going to go when we started that back in 2023, but it's definitely super powerful. Then the other thing that's different about us is we have first-class foot support for the AI observability stuff, things like evals, things like token usage and pricing, but we're also general observability because I don't think that in five years' time, anyone will talk about AI observability. It just won't be a thing. In the same way, no one talks about cloud observability or web observability. It's just going to be a required feature of any observability platform.
12:20 Speaker 01 Yeah, lots of interesting kind of nuggets there. I mean, as you touch on AI as as SRE and there's obviously a bunch of companies just taking that. And I think it's been very interesting where actually if you just call code to a good library, then there you go. You've kind of got it. And I think we're just seeing that where sort of the, I'll call these sort of low level platforms are still beating out like anyone who comes along with a sort of specific products around that. So yeah, super interesting. We're going to move on to Pydantic AI, which is the main topic for today. So again, let's just talk about where did it come from? And I'm sure there's maybe a bunch of people listening right now thinking, oh, well, of course, Pydantic, of course, there was going to do an AI thing, but I know that's not the story. So let's talk about it. Where did it come
13:05 Speaker 01 from? What is it?
13:07 Speaker 02 I mean, in some ways, we were doing the opposite. Like, we were reasonably cynical about some of the AI stuff for a long time. And that's probably why we didn't build an agent framework in 2023 as others did. In some ways, that probably turned out to be a good decision because we waited for the patents to settle and we were able to build something that was, that's probably influenced the patents a bit, but we've also been able to read what others are doing. Whereas those who created agent frameworks or equivalents in 2022, 23 are kind of stuck. Either they have to go and break their API again, or they're stuck with primitives that I think we've now moved on from. So yeah, come late last year, we were starting to build AI functionality into Logfire. I knew all these agent frameworks out there used Pydantic. So obviously Langchain,
13:51 Speaker 02 Langgraph, Crew AI, Llama Index, all of these guys used Pydantic. And I assumed there was going to be a good one that I could go and use. I started looking at them and was super disappointed by what I found. They're not type safe. I think type safety is incredibly important and only getting more important with AI's writing code. If you look at the standard of engineering among the like top 100 or 200 Python packages, it's pretty high. Everything has coverage. Everything has pretty thorough unit testing. They have like CI that does releases. They have typed documentation, tested documentation, stuff like this. That was none of those like low level things
14:30 Speaker 02 Sure, no single one is a showstopper, but they're kind of indicators of quality seem to be the case with any of the other agent frameworks or L L M libraries. And so we thought for a long time about whether it does this or thought for a bit, is it really worth us going and building another of these things? It seems like a kind of gold rush. Don't we want to make the spades? But when we realized that we decided people weren't doing it the way we would, we decided to go and build PyTorch G I. So we tried to keep it relatively unopinionated and low level, try to do the things that you definitely don't want to have to re-implement again and leave the kind of opinionated, how am I actually going to make this thing work with an L L M? Up to the end user, because we're not the A I engineers, we're the people who are good at building libraries.
15:16 Speaker 02 And we want to let you go and innovate on how exactly you're gonna use an L L M. Is that a like good starting point?
15:22 Speaker 01 Yeah, I mean, I think just to make sure we're not breezing past and assuming knowledge from the audience, I mean, PyTorch G I ultimately can do things like it can call L L M's, it can create agents, do function calling, do evals. So it's a agent orchestration, would you call it, or not exactly?
15:39 Speaker 02 Agent framework, agent orchestration. We also have a graph library. We're about to have a new version of our graph library, which is a bit less boilerplate than the current graph implementation. I mean, I think there's some debate about how valuable graphs are. They don't do anything particularly special. You can't do in other code. But they definitely can be a nice way of thinking about it. So we have that support. I mean, for the most part, if you're building an application with L L M's, PyTorch G I will let you get going much more quickly, but unlike some of the other agent frameworks, will go on to be usable in production and will let you do the customization that you want to do. Where we probably, what we don't have is necessarily all of the integrations or all of the batteries included. Here's a button to add
16:24 Speaker 02 support for whatever database or whatever RAG service. We would rather let you build that because in production, that's probably what you want to go and do anyway. And as I said earlier, I think type safety is absolutely critical. We have a fairly unusual way, but type safe way of doing dependency injection so that you can access dependencies within tool calls. Which is, I mean, a lot of it's inspired by Fast API. I worked with Sebastian a fair bit on, not so much working on Fast API, but we talked to him for a bit within the team. And definitely a bit inspired by Fast API, but actually, given that there are new typing concepts like concatenate available in Python now, using them to give the most type safe experience you can.
17:02 Speaker 01 Yeah, and I wanted just to touch on, kind of before we get into more of the agentic and tooling side of things. Type safety, obviously huge. That is Pydantic. And I mean, that is by definition constraints. And like, how have you thought about just that? Way of approaching things when it's come to Pydantic AI. I mean, have the concept of constraints come into it in a way?
17:23 Speaker 02 Yeah, I mean, I think one of the things I'm realizing is people sometimes blur what they mean by type safety. I would say there's data validation or type validation. That's what Pydantic does. I have some untrusted data. I have some Python types. I will guarantee to give you an instance of that object that matches those types or raise a validation error. There's that thing, and obviously we support that within Pydantic AI. I think we have some of the most advanced support for different ways of doing structured outputs. We support tool calling for structured outputs, built in structured output that some models support, and then what we call prompted outputs, where you basically give the model a JSON schema and say, try and match this. But that's when I talk about type safety, I'm actually talking about static typing, like using the types that are available in Python to do relatively complex stuff. So,
18:08 Speaker 02 for example, agent is generic in the output type. That means that when you access the result or output from an agent run, that will be at typing time, an instance of the output type, but we also guarantee it's an instance of that at runtime with Pydantic. But we also go much further, like I say, dependency injection, type safe graphs, which again, the biggest downside of other graph libraries is you basically, sure, you have this like possibly useful mental model of a graph to describe things, but you lose all of the type safety that you would expect in other bits of your codebase. We have a way of supporting graphs that is type safe.
18:45 Speaker 01 Got it. So let's move on to actually kind of, I guess, the usage, so to speak, but. I'll kind of just throw out like, it's a very generic question, but I think it's maybe something that can lead to more discussion around like how Paddleantic AI is approaching this. Like, if I was to say, what is the correct number of tools to expose an agent to? Like, very, very big, right? So like, how do we think about that?
19:08 Speaker 02 I think people talk about like 10 to 15 max. I think it's interesting that that number has not moved this year, although the same people claim models have got way brighter. And I think what has actually happened is people's models have got cleverer, but our idea of how big an agent should be has decreased this year. So this is like, everyone was talking, I remember in February, I was AI engineer, everyone was saying this is the year of the agent. Well, that's true. I don't think that means we're going to stop using agents, but one of the things that's changed is our definition of how big an agent is. So there are ballpark three definitions of what an agent is. There is the like AI definition, which is an LLM calling tools in a loop until some condition is met. There is the engineering definition
19:49 Speaker 02 of an agent, which is effectively a microservice. And then the joke is there's the business definition of an agent, which is something that can replace an employee. Ignoring the third one for a minute, if you think about the first two, LLM calling tools in the loop and a microservice, at the beginning of this year, we thought we would have our agent, which would be a microservice, and inside it, it would have one agent in the code sense. It would be given all of the tools, all of the context, and it would iterate until it magically arrived at the answer. I think we have, for the most part, moved away from that idea down to the idea that we have multiple different agents that you piece together to give some constraints on what your application is able to do and is therefore make it more
20:30 Speaker 02 deterministic while still giving the LLM the kind of space to innovate. So, concrete example, let's say we have a deep research agent. We think of that at the business level or the infrastructure level as one agent. If you look inside, what's happening is you might have a planning agent, which generates a plaintext description of the plan that you're going to execute. Then you have an agent which will extract structured data from that plan, turn those bullet points into some structured Paddleantic model of like, here are the steps that we're going to go and execute. Then we might use one For each of those sub steps and then we have a final agent that basically takes all of that context and outputs our final summary of what's happened, the kind of research.
21:10 Speaker 02 And now, if you think about that system as, sure, you can think about that as agent orchestration again. AI people love inventing new words for existing concepts, for the most part. Agent orchestration, we have ways of modularizing code. We've had them for 40 years, they're called functions and classes and we don't need to invent new ones, it turns out. But like, yeah, that thing that at the beginning of the year, people will have said, oh yeah, I've got deep research. It's just one agent that goes off and runs with access to these many tools until it magically arrives an answer. I think we've moved away from that and there are lots of reasons for that. It's we can switch which L L M we use for each of those different tasks, even which provider. We can switch in and out which search we want to use and we can debug it more easily. We can work out which of those things went wrong.
21:55 Speaker 02 If you just give all of your context to an L L M and hope it gets it right, it's magic when it does and it's unsolvable when it doesn't.
22:02 Speaker 01 And maybe this is seen as one of these AI fatty terms, but I think it's probably something that developers have heard, the idea of swarms or agent teams. How would you, I'm sure you think of it much more nuanced than that. So, I mean, in relation to what you've just been saying.
22:19 Speaker 02 I think most of these terms are pretty much bullshit, I think. I mean, our big thing in PyTorch is AI is still just engineering. Sure, what L L Ms can do is borderline magical, extraordinary. If you had told us this is where we would be five years ago, probably none of us would believe it. But how do we go and use that? We apply the engineering principles that we have learnt and improved on over the last 20 years, 40 years, whatever long you want to think about it. So, yeah, I mean, I'm not going to show code now, but like I had a deep research implementation that I wrote the other day. Where, yeah, you could think about an agent swarm, that is like, I call the same agent many times in parallel to go and do research.
23:00 Speaker 02 Then I take all the results and I pass them to a like more powerful model and I get it to summarize the result. There are more complex workflows, but it's very rarely actually a complex graph. I mean, I think that's one of the things you notice if you try and go through Langraph's documentation, go and find like interesting, genuinely innovative graph example, doesn't exist.
23:22 Speaker 01 I mean, yeah, you said you're not going to bring up code. That's good because we're an audio only output here. So I'm not going to narrate code, but let's talk about how you would think about this. You're somebody who's obviously working in this realm day in, day out. So if you were going to be building, let's just take the obvious example, like customer service agent, do you have a framework for it? What are you going to expose if we're talking across a bunch of tools? And how do you think about adding and removing in the sense like, what's your kind of experimentation process on that as well?
23:52 Speaker 02 I'd say a few things. I'd say first of all, unlike in traditional applications where any experienced engineer can basically eyeball what's going to be performant and implement it first time, that is not going to be the case with AI. You're going to have to go and try a bunch of things and throw stuff out and try again. And so the two things that in my opinion matter there are type safety, because you want to go and refactor, it's a heck of a lot easier to refactor if you've got type safety. If you want to tell Claude, go rewrite this to work in a different way, it'll do a heck of a lot better job with that if you've got type safety. Second thing is observability and observability from day one. Observability is not something that you shoehorn into your application the day before launch because someone told you you should. It's genuinely useful from day one, trying to work out what's going on. And then thirdly, I think evals are important. Eval's are a
24:36 Speaker 02 powerful mechanism to kind of allow you to have at least a chance of systematically improving rather than kind of random walk, but also just like digging in and trying to understand what it is that the LLM is actually doing. They're very rarely, it's extraordinary how what they can do, but their processes are reasonably easy to follow for a human. They're not meaningfully more intelligent than us. So we can go and read through it and understand where they've come from a decision in general. I mean, there's a great talk from Barry Zhang at AI Engineering at the beginning of this year called Think Like Your Agent or something like that, or Think Like Your Model. The idea is it can be really hard to work out what data your model has access to versus what data you have access to.
25:19 Speaker 02 And therefore, understanding what mistakes it's likely to make, which basically a lack of context. One of the examples I like to use with this is if you give an LLM data in the form of some bullet points, do a pretty good job of understanding the different bullet points. If you give it that same data in the form of a markdown table or a CSV table, does a much, much worse job. And yet you and I look at the CSV file and open it up in Excel or look at it as a markdown table, it's really easy to see what's happening. We can look down this column. But if you imagine how an LLM sees your data, which is effectively is one long line of bytes, now trying to correlate where is like, comma seventy three point four, go back all the way to work out which column that relates to, it's incredibly
26:00 Speaker 02 hard. And so you try not to give access to tables in that form. If you can give it access to that basically XML or JSON where it has the key each time, it'll do way better. But that's just one example. But there are many examples where ultimately the problem is you have failed to give the agent or the LLM access to some key data it needs to solve the problem that you implicitly have, but you haven't realised you have it because it's kind of so obvious to you.
26:25 Speaker 01 I guess then, taking that, I want to maybe go slightly back to if we think about multi-agent and that question around like, are we talking about a number of tools in one agent or are we talking about quote, multi-agents? Again, how do you think about that? I mean, it's sort of organisational design almost. You've already touched on the idea of like, think of it like a human. Are we talking like, from a human perspective, it'd be like, oh, are we talking silos? Are we talking about communication of teams who get to talk to each other about something? Again, how do you think about that? And this is also then thinking about, well, how do we look at shared memory or messaging or like the concept of voting between them? How do you look at that?
27:03 Speaker 02 I mean, I think the first thing to say is if you have a isolated task and you can take the context that's required for that task and move that into a separate agent and call that within a tool or call that in a separate step, it can be a great way of reducing the amount of context that the main agent has. So let's say you're building a research agent that has access to go and query some big SQL database. Now, the obvious thing to do is to go and smash the whole of your schema into the main agent and it now has access to all of the information it might need and it can go and write SQL to query that data. Well, fine, but you've now, if you're combining that with like some other significant tasks, you've got an awful lot of stuff in your context. If you have a tool that is called like run aggregation, let's say,
27:47 Speaker 02 and it takes a natural language description of the data that it's trying to find. And then within it, it calls a separate agent, which that has access to all of the schema and the database context and examples and stuff like that. Then one, we have a system that's way easier to debug because we can go and run the SQL agent, see when it works and see when it doesn't and write evals on that in particular. But two, the main agent has got to do that. And also a bunch of other tasks, look up some rag database, worry about memory, access some NoSQL database, blah, blah, blah, blah, blah. It doesn't have to think about that at all. It just gets this plain text tool, describe the data that you're looking for, but a context on the kinds of attributes you like. And you've gone down from thousands of tokens of context for SQL
28:30 Speaker 02 down to a few hundred or tens even to describe that like get data endpoint.
28:35 Speaker 01 Okay. We're going to move on to graph theory or graph theory meets AI, if you want to call it that. I think just did some sort of pre research, obviously, as I do before all interviews. I think you've talked about the concept of graph theory meets AI, if you like. So I believe there's this concept and whilst I'm not in this domain, so audience forgive me on this one. But DAGs directed acyclic graphs. Could you talk to us a bit about that and sort of how this is sort of looking at the process by which an agent might move along its kind of steps. I think in theory, one is kind of quite linear and the other is you can kind of have a cycle. And I believe Pydantic AI kind of prefers one approach over the other.
29:18 Speaker 02 Like I say, I think the jury is out to some extent on graphs and their use. I mean, I think most people, when they talk about DAGs, they mean effectively a graph with some dependencies that like relate by node. The graphs that you end up building, if you're using LLM are quite often cyclic. As in, there's no reason why you can't have cycles in there. We have Pydantic Graph, which is part of Pydantic AI. It's used under the hood by agents. I'm a bit torn on how valuable they are. Someone said to me recently that the most useful thing that graphs do is make people who want graphs happy. And that is a very clear definition of why a graph is useful. But how much value are they after that? I think not that much. I think that to be rude for a moment about a capesta, I think Langchain,
30:00 Speaker 02 they're taking a lot of heat for Langchain and how it didn't have any functionality. They chose to go and build LangGraph because that seemed like the right thing to do. And bluntly, they didn't understand how to do durable execution. So they had graphs as a way of snapshotting. And now they're stuck saying graphs are the right way of doing it because they can't go and build a third library. That's their new way of doing it. So what's happened, I mentioned this earlier, that we were able to adopt the new way of doing things. One regarding which I have sympathy for them is that since they released LangGraph, everyone else, Anthropic, OpenAI, Google, us, and a bunch of other agent frameworks have all centered on this model of agents of LLMs calling tools in a loop, which are a very powerful primitive. Now, you can implement that with LangGraph, but it's a lot simpler just to go and use our agent or even OpenAI agent's agent implementation.
30:45 Speaker 02 There's a reason that one is so similar to ours, which is it's, I'll say, inspired by our agent implementation. So the other thing that LangGraph lets you do is snapshot at the end of each node. And so if you, something fails, you can go back to that point. Now, that works, but if you want to have that and parallel node execution, so run multiple different nodes in parallel, you basically have to abandon type safety completely. You have to manually check that your data is consistent. Our approach is different. We support durable execution frameworks like Temporal, DBoss, and we have a bunch of others coming soon. And they let you get the durable execution, this idea of an agent that can run for minutes or hours and resume from, basically pick up from where it left off if it stops or if you get errors,
31:29 Speaker 02 which I think is a much, much more powerful way of getting the longevity part of long-running agents. But I was giving a talk yesterday on the temporal and durable execution. Obviously, you can use durable execution with graphs to run your graph within a durable execution framework. And now you get that same snapshotting effectively behavior, restarting a graph from where you left off. It's much more fine-grained. It's literally snapshotting at every async call. And the code should be much easier to write because you don't have to worry about this snapshotting that gets in your way.
32:02 Speaker 01 I mean, just, I guess, talking of slight, lame in terms here, but if, you know, if we're talking about failure modes as such, and okay, something fails and there's this concept of snapshotting, but is there a concept of being able to kind of move on even though some part of the chain failed?
32:19 Speaker 02 So our graph implementation, we have some basic snapshotting. I think we will, I don't think we'll retire it because people are using it, but I think my approach would be durable execution is the way forward. Like, these are solved problems. People like temporal, but then not by any means the only one. There's a whole space of those companies have done an amazing job of giving you ways of writing what feels like normal procedural Python code. But if you get a failure, it will automatically be retried. If you want to go and sleep for, for three weeks before the next task needs to be run, you just sleep for six weeks and it will take care of restarting the process from the right point. That stuff is, I think, really powerful. I think it is a far better solution to the same problems as graphs.
32:56 Speaker 01 So let's talk about the general DevX. How did you think about that? I mean, I guess, were there any things that you've learned through especially Pydantic V1, 2, and maybe even sort of how you've been thinking about V3? Like, as to how the DevX feels and looks for someone coming into Pydantic AI?
33:14 Speaker 02 I mean, I think that we know we're battle scarred by introducing the wrong API and having to maintain it for a long time. And so we're very careful about the surface area and not just adding in any old thing that someone wants to add. I think others who are earlier on in the like arc of maintaining open source, perhaps don't necessarily think that way. I think that the extraordinary powerful thing about code and about good open source libraries is people can go and use them in ways you never thought of, right? Pydantic is used for a myriad of things I never thought of when I started it and lots of things I, you know, to this day. There are hedge funds, for example, but other, you know, large organizations who do stuff with Pydantic that I had never thought of. And that is, you know, if you build a really powerful tool, the point it is
33:58 Speaker 02 universal enough that people can go and do things you hadn't occurred to you. We want to build an agent framework where we build those fundamental things. You don't want to have to go and repeat. So the very simple thing an agent will do is if you're doing structured data extraction and the model gets the Gets the response wrong and you get a validation error, it will return that validation error to the model and say, please try again. That is a very neat, very nice thing that will very often catch intermittent or intermittent bugs. You do not want to have to go and implement that again. It may as well exist in a library where you're sharing that implementation with everyone else. But then how you go and implement RAG, for example, is far more opinionated, far more context specific, far more room to go and like innovate and try doing unusual things. And we don't want to get in your way of letting you do that.
34:42 Speaker 02 So we're, I think, yeah, strongly of the opinion that we're trying to build the right foundations rather than give you these like high level abstractions that like, tell you what to do, but constrain you in doing it well.
34:54 Speaker 01 You touched on it with a reference to pure Pydantic, but when we think about case studies or things you've seen Pydantic AI being used for, I guess, could you just like pull out some of those that come to top of mind right now in terms of either things that you've just been very impressed by, or I would say maybe more interesting things that even you hadn't thought of Pydantic AI going to be used for.
35:15 Speaker 02 I mean, I'm trying to think, there's someone in our public Slack who's written a coding agent with Pydantic AI, which is a like neat working implementation that like works very nicely, I think. Again, coming back to the log file and the SQL thing, it's amazing how powerful agents can be if you just hook them up to a SQL connection and let them retry a bunch when they get the SQL wrong. We've done some stuff with Pydantic AI, but I've seen others do it where you're effectively doing data analysis with a SQL tool. The other interesting thing is how much has come and been implemented by the community or from pull from the community. So AGUI integration, AGUI is a protocol for talking to a UI to a like chat interface, basically, but you have rich components. That was implemented by by someone else.
36:01 Speaker 02 But also some of the model implementations are either implemented or maintained or or support, you know, improved by the community. I have an awful lot of people coming and contributing to it. I think, you know, one of the unfortunate things about maintaining open sources, you often don't see the most interesting things people are doing with it because those things end up being proprietary. But I hear quite often from people. Once I found Paddle AI, suddenly I had found an agent framework I could actually bear. And now that's the only one I will use. And I hear that roughly that line from experienced engineers all over the place. And that that gives me, you know, that feels great because that's where I come from, right? I'm not a cursor type developer, you know, and start developing with cursor. I've spent many years learning it the hard way. And there are lots of other people who come from that like
36:45 Speaker 02 deep engineering experience who for whom Paddle AI resonates.
36:49 Speaker 01 Yeah, I've spoken to many, especially through this podcast, many open source maintainers and I'm not one. And I always just assume that they kind of know all the projects that are using their libraries, especially sort of the top ones. And they're like, no, I actually have no idea. Not no idea, but it's sort of, it's very hard to keep on top of the web of of things that it's being used for. State management, do you have any sort of recommendations for then where that should be managed if using Paddle AI?
37:13 Speaker 02 We have some neat examples in our demo repo of managing memory with either tools. So you have a like record memory tool and a retrieve memory tool that works surprisingly well. Or just recording all messages and then doing a bit of bit of work to like cut off some older messages when you like if you have very long running conversations going on, both of those work like fairly well. I think the fundamental, again, I come back to it, but I've said it before, but I'll keep saying it like we're not trying to give you the high level opinionated here. Is it like the, I know one of the other agent frameworks has like three different memory implementations for short term memory, long term memory, contextual memory. It's very unclear what they do under the hood. We let you do tool calls.
37:55 Speaker 02 We return you structured like Python objects as messages. You go implement the thing you want. If it's a simple demo you want to build, the simple thing will work. If it's a production application where you've got lots of nuance, those pre-built ones aren't going to work for you anyway. I think we might move a little bit more in the direction of having a like having support for storing messages easily in a database, basically an abstract base class and a few implementations for that. Because it's a common enough pattern, it makes sense. And I think we're thinking still about how we'll have embedding support soon. At the moment, there's no embedding support in Paddle AI because it honestly hasn't come up. It's one of the most upvoted issues, but it hasn't been a burning need for the most part.
38:36 Speaker 01 Is that as in like actually creating the embeddings?
38:39 Speaker 02 Yeah, like generating the embeddings API. Then if once we have that, which is relatively simple API, do we then go further and have concept of RAG and hybrid search or vector search? Or do we just say, yeah, working about it, well, here's an API for generating embeddings. How you go and implement the next phase is up to you. Yeah, I mean, the other place I I mentioned AGUI already. We also are about to have support for the cell AI elements, which is another protocol effectively for communicating with chat UIs. And so the the principle is you should be able to build a chat UI with really a few lines of JavaScript or no JavaScript at all, just using a pre-built UI. And then you can go and do your innovation within the agent, however you like in Python.
39:22 Speaker 01 And then just to kind of, I guess, tie a bow on it. Observability, I guess, of LogFire, that's the sort of maybe batteries included piece, if you want to.
39:29 Speaker 02 But again, we work really hard to follow open standards. So Pydantic AI emits standard compliant open telemetry data. A couple of us are reasonably involved in the hotel SIG for Gen AI. So we like push hotel to work the right way for Gen AI. And then we support that. And so at my last count, there are about 13 different observability platforms that support Pydantic AI one way or another. We obviously think LogFire is the best of those, but unlike some of our competitors, we're not trying to use a proprietary protocol to kind of lock you into using our one. We think that like we'll win because we have the best agent framework and the best observability platform. And we can kind of guarantee they work well together, but we have, we're not trying to stop bringing a different agent framework or bringing a different observability platform.
40:11 Speaker 01 Yeah, and I definitely see that trend with a whole bunch of platforms where ultimately they're, they are open source and they have maybe different sort of arms. But the key, I would say, part of their success is just maintain that thing as an open standard. And if somebody wants to swap out a bit, that's completely fine. But at the same time, you've got, you know, three to four bits of the ecosystem that you still know will work well together if you just want to kind of default to something.
40:38 Speaker 02 I think it's valuable if you're an enterprise that you can come and you have one company, you can come and shout at when the two don't work well together. That's the powerful bit of what we have is, you know, we control an awful lot of the stack, right? As in people on our team, although they're not directly part of Pydantic, Marcelo maintains Starlet and U vehicle, which is basically the modern networking stack for Python. And so from Pydantic to Starlet to U vehicle, to Pydantic AI, through LogFire SDK to LogFire.
41:05 Speaker 02 Most of those bits are literally under the Pydantic umbrella, and even if they're not, we're pretty involved in the ecosystem. And that is, I think, where companies of all sizes with some engineering taste, but particularly enterprises, find the value in like the one solution or the one point of contact for many different solutions.
41:21 Speaker 01 Yeah, absolutely. Being on the side shouted out on that on that basis, but that's a good place to be. So we're going to hear about something kind of exciting in a minute, I believe, as a new product in the wings. But just to kind of wrap up this, again, this, you know, I'm just the voice of the audience here in terms of LLM gateways.
41:38 Speaker 02 Yes. So we're about to release Pydantic AI Gateway. I think by the time this goes out, it should be launched. It's in particular from enterprises, a feature we just hear, like, immediate need for, like, it's the hair on fire problem right now. There seems to be no good go to solution. I mean, it makes sense, right? You're a financial services company, you're expecting to spend five million a month on OpenAI. Are you going to give everyone in the company an OpenAI key where technically they can spend five million dollars? And then some internally something running overnight and you've spent a big chunk of that, obviously you're not. And you want observability into what's going on. And that's if you only have one model. Now, what if we're doing some research and we have Anthropic, Gemini, Mistral, Grok going on?
42:23 Speaker 02 Like, it obviously makes sense to have a single platform to manage those things. And once you have that platform, it's a very useful place to do a number of things. So whether that be caching or security or fallback. And so we just kept speaking to enterprises who didn't have a good solution for this, but needed it. And so, yeah, we're about to release Pydantic AI Gateway. It will obviously have a very nice, easy integration with Pydantic AI. So you can basically set Gateway and then the provider and the model. And your one API key will then let you connect to all of those different models without having to go and put a credit card into each of them if you're if you're getting started. And yeah, we'll also we'll allow to basically we'll let you use all the big models through one gateway.
43:05 Speaker 02 The initial launch, we won't have many of the like shinier features, but they will come very soon afterwards. The caching and the fallback and the security stuff.
43:13 Speaker 01 Very exciting.
43:14 Speaker 02 Yeah, and then the actual gateway itself is open source, but they're like console, the platform for managing it is closed source and that we will sell. And part of it comes back to like, it's all very well, but like, we can make the process of getting going with building with L L M's incredibly simple. But at the moment, there was this barrier that a lot of the L L M providers are just like, their platforms are not that easy to use and understand. And we want a really nice way of allowing developers as they get started to go from zero to I have an app running with an agent in it. And I have observability very, very quickly and that makes complete sense. And obviously, one of the neat things we can do in the gateway is we can emit open telemetry from within the gateway. So if you're a large organisation and you desperately want, you definitely want to record all prompts.
43:58 Speaker 02 And you want to look for phishing or for prompt injection, you can do all of that stuff in the gateway with Logfile, which is why they kind of play well together.
44:06 Speaker 01 Yeah, and yeah, just to call out, we're recording this the third week of October. I believe it's sort of end of, end of October is the release on that one.
44:14 Speaker 02 I've got a big night ahead of me because we were hoping to get to the private beta tomorrow. I think it's now going to be Monday and then yeah, hopefully 31st of October, we'll do the public announcement and let you sign up. Put a credit card in if you want to use the models we resell or bring your own key if you want to like put your own key in and that'll be free.
44:32 Speaker 01 Yeah, so yeah, just to call out, thank you so much for coming on, given that this is your evening over on the West Coast. And as you just said, you've got a big night ahead of you. I misheard you saying you've got a big night ahead of you at the pub, but you were about to say public. So, so yeah, thank you for making the time. I thought it might be nice just to kind of round out with a little bit of Hacker News feedback, actually. Cause I think it's kind of fun when like people that have given, and there's no kind of gotchas here. This is just, I just want to, I think it's kind of interesting. You know, six months ago, someone said, you know, I found that Python AI framework strikes a perfect balance between control and abstraction. What would you say to that?
45:06 Speaker 02 I think that's exactly the kind of what, how we've tried to think about it. In particular, I mean, I remember speaking to people at the beginning of this year who would say, I don't need an agent framework. I don't want all those abstractions. The one thing that I want is the model agnosticism and be able to plug into any of the big models. Not have to go and use the OpenAI or Anthropic or Google SDK and then be stuck to them. And so to some extent, we tried to build it as model agnosticism without too much on top of it. We've added a little bit, but it's all opt in and fundamentally the agent is pretty simple, some pretty minimal behaviour on top of the standard LLM calls, but with like with that nice unification. So you can switch model in very quickly.
45:46 Speaker 01 One more, yeah, just I've been building an integration with Pydantic AI and the experience has been great. Questions usually get answered within a few hours and the team is super responsive and supportive for external contributors.
45:57 Speaker 02 Yeah, I mean, I think we take that very seriously. We care about the kind of response rate on GitHub. Even on the open source or replying on Slack, like one of us will reply to your message on public Slack. Almost always within an hour or two in most time zones. We've been there, we're developers, right? Like I'm writing code most of my day still luckily, maybe I should be doing more sales, but hey, like, and we care about that stuff and are like, because we are ourselves open source developers. That is like one of the things we care about most. We had a sales call earlier with someone from Enterprise and they were compelled by what we showed them in Log file, but really the reason they came to us was the solution they were using before had two hundred and ninety something open pull requests. There were no one ever responded and that was the thing that had actually driven them to be like, what else can we use and came to us?
46:43 Speaker 02 So I think that like responsiveness and engagement with the community is a big part of what makes us different.
46:49 Speaker 01 Awesome. Yeah. And obviously I said that no gotchas, but also why not pull out something that maybe there's someone in the audience that is saying this in their head anyway. And there's always going to be people that aren't just throwing all positive comments, but someone saying, I really wish Pydantic invested in Pydantic instead of some AI API wrapper.
47:06 Speaker 02 Fair. And I think we probably, one of the reasons we haven't been that much recently is when we made new releases of Pydantic, mostly people were annoyed that we broke things because we fixed someone else's thing. And so Pydantic is a big established library. We are now, David Hewitt, as I said, is working a lawful lot on new stuff within Pydantic. You will see big new features come out. The other thing though to say is go and look at the top one hundred most downloaded Python packages. Look for eponymous companies in that list. You will see four companies. You will see Google, Amazon, Microsoft and Pydantic.
47:40 Speaker 02 If you look in the top 25, you will see, I think, only Amazon, maybe Google and us. Now, per head, per dollar of, however you want to measure it, we are one of the most impactful companies in terms of how much open source we do. But we have to make money, right? We're a startup. We've been given money by some big VCs to go out there and make a profit. We're not a charity. I find, there was someone who worked, hilariously worked in the CTO's office at Google, who said, "Oh, I'm not sure about Pydantic now they've raised money. I'm not really sure about these open source projects that are trying to like make a profit." Saying the same thing about Astral and Ruff. He ended up deleting his comment because he obviously realised he was on the wrong side of history on that one.
48:19 Speaker 02 But like, there are a certain number of like millionaire communists, particularly in California, who would love open source to be, you know, entirely benevolent, but they get paid an awful lot of money to, by big tech companies who don't particularly contribute back. So, we subscribe to the pledge, open source pledge, so we give $2,000 per year, per developer to, yeah, to open source. That's above and beyond all the open source we do. We think that stuff really matters. I see very few of the other, like, bigger companies doing that. And I suspect the person who made that comment doesn't work for a company who does that. So, I think we do enough for open source. I'm pretty proud of what we do. And I'm pretty robust in rebutting anyone claiming that we don't do enough.
49:04 Speaker 01 Yeah, absolutely. I wanted to bring that out because, you know, I very much stand with you on that one. You know, both seeing what Pydantic does, as well as many other companies, they get the same heat, just because they switch focus a little bit to something that happens to have a commercial arm to it, and somebody gets all rubbed up the wrong way.
49:22 Speaker 02 And I'll tell you that if, in the unlikely event, Pydantic doesn't work out, and we end up shoving the company down, or being acquired by someone that people don't like, we'll get a lot more heat for it then. Well, the reason we're trying to make money is so that those things don't happen, right? Because, maybe I'm not as nice as Guido. I'm not going to maintain, and obviously, Pydantic is nothing like as big as Python itself, but like, I am not going to go and maintain like Pydantic on my own for the rest of my life, being paid, like, I was probably getting towards $40,000 a year when I was maintaining it on my own. That's not me. I'm not going to do that for the rest of my life. So these projects, the company needs to make money to support both our open source and the wider ecosystem.
49:58 Speaker 01 Absolutely. Just kind of talking about, I guess, the company today. How many people do you have in the team now? And are you hiring? Is this a good place to plug any hiring or?
50:08 Speaker 02 We will be hiring a little bit over the next few months. The blunt truth is that we like, I think that it's got easier and easier to apply for every single job you can think of. And the number of pretty poor applications we get now, whenever we put a job ad up, we're being more and more like targeted and looking for particular people. So and unfortunately, we're a small team. We don't have capacity for like junior people or interns in general. And so I'm afraid if you email me being like, I'm a big fan, I'd love to do an internship with you when I finish university. Unfortunately, I'm, I'll try and get back to you, but the answer will be no. We're always looking for like really bright, experienced engineers who have a proven track record in open source, in Python, Rust or TypeScript. But if you haven't got a like pretty impressive
50:52 Speaker 02 record in that direction, we probably aren't gonna, it's probably not gonna work with us.
50:57 Speaker 01 Yeah.
50:57 Speaker 02 But yeah, we will be hiring. We put everything on social media and would love you to apply if you match the conditions on the application. But please don't email me. Our first rule of anyone that we hire is they need to follow the hiring rules, which start with email careers at not Samuel.
51:14 Speaker 01 Yep, I've been there as both a past life owner of a company where developers are applying as well as them being a CTO and having people sort of try and get around the process. And I just politely say, please follow the process. You're not going to get anywhere just by emailing me. Unfortunately, all these stories from back in the day, oh, I guess the email address is just nonsense now, or it should be. There's a process usually for a reason. So.
51:35 Speaker 02 I'll just add one thing though. I mean, a lot of the great people we've hired have done significant stuff in open source. Now, don't think that as a three weeks into your Python career, you can go and like start using Cursor to generate pull requests on Pydantic and we'll go and hire you for loads of money. But like, we have found some incredibly talented people who probably would have been overlooked by bigger companies by finding people who have like been working away maintaining awesome Python libraries for a long time. And so I do think that if you can get into open source, if you can go and do the hard yards of building up a reputation in open source, both us and many other companies will hire you. So I do think, but it's not a quick fix. It's not like. You can't just go and like buy the right crypto coin and suddenly be a millionaire,
52:18 Speaker 02 right? It takes you five years of learning. How long does it take to get 10 years of experience? It takes 10 years and you can't really accelerate that. Arguably that AIs make that even harder. Because the discipline you need to learn it yourself when an LLM will probably get something approximately right instead is it's getting harder.
52:36 Speaker 01 Yeah, it's something we've discussed a few times. We have an SED News monthly and Sean and I have discussed this a few times, just sort of what is the, where's the tipping point between people coming in now as developers and not to in any way dissuade people or, but yeah, there is no point in just firing up cursor and then thinking that you're a programmer. Like it doesn't work that way. And it's not, we're not, or we're the old guard saying, you know, you can't come into the club. It's not that whatsoever. It's just that it's engineering is a fundamental, there's all these principles and concepts that just seem helps if you understand them before the code that's written that you're then reviewing or editing.
53:11 Speaker 02 It's a bit like, you know, whether you're flying a plane or driving a truck, like sure, you can put it into cruise control when you're going down a motorway, but when you get to that narrow lane where you need to reverse around a corner, like you still need those expertise. And in the end, sure, I use Cloucode a whole lot and it does lots of things for me that I don't want to have to go and write all of those React components. But like when it runs into some weird bug, when you need to set up exactly how you're gonna share type safety between the front end and the back end, that still requires me. And I don't think there was a, and maybe we're about to AGI, we're all redundant, but like until that point, however little time it is, you still fundamentally need a truck driver in that truck to reverse around the corner, even if they spend a bunch of their time in cruise
53:53 Speaker 02 control. And the same is true with code. Like, and in some ways, it's a multiplier, right? Like, we all have the resources of a team lead, but you still need the knowledge of a team lead to be able to deploy that team, whether it is human or AI effectively.
54:08 Speaker 01 Yeah, absolutely. So yeah, just kind of final closing question. And this is more like a personal one to you, I guess, which is more just inspiration. Like, I guess, have you got any people, whether it's in the community right now, or even, you know, living or dead, who's kind of like inspired you and does inspire you, I guess?
54:26 Speaker 02 I have to say Guido van Rossum, the creator of Python. I've met Guido a number of times now. He's he can be reasonably blunt, but he's always friendly and fun to talk to. And he is so humble. I mean, I have seen him walk into rooms where no one knows who he is, and just stand there and like, listen to what's going on. He so often describes himself as the author of PEP 482, not the like, but BDFL and the creator of Python. I'm so impressed by what he has built in Python, both as a community and as a language. He got so much stuff right long before his time in terms of realizing that it was something that programming languages are for humans to use, not for computers to use, and prioritizing the human bit. And I think the success of Python, you look at every other successful language, with the possible exception of Rust, which I'm also a big fan of, they've all been anointed somehow.
55:11 Speaker 02 They've all had a reason why they're going to win. JavaScript had the browser, Go had Google, C sharp had Microsoft, et cetera, et cetera. Python had one random Dutch guy and an amazing community. And I am ever impressed by what Python has become. And you look now, right? Like, in AI, sure, some people say TypeScript might take over. But like, it's TypeScript and Python. It's a two horse race. And Python's doing amazingly. And I am like, proud to be a part of that community. And they've had a little bit of impact on it over the years.
55:39 Speaker 01 Yeah. I mean, I have to have to say, I am more on the TypeScript side, but that's not because I dislike Python. It's just that's just the route I took in life. And I'm really impressed by how Python has, as you say, it's the leader clearly in AI programming. And it's been fascinating to kind of watch that. Well, look, it's been absolutely a pleasure to have you and feel very lucky to have you on SE Daily, especially as we've called out in an episode, this is sort of towards the end of your night, and it's not finished yet by any means. So yeah, thank you so much for coming on. And obviously, we look forward to the Pydantic AI Gateway release, which is probably going to be out by the time that this is airing. So yeah, thanks so much.
56:17 Speaker 02 No problem. Thanks so much for having me. It's been a pleasure.
Previous SED News: Bezos Returns to Building, AI’s Reality Check, and Europe’s Cloud Ambitions Next Blocking Software Supply Chain Attacks with Feross Aboukhadijeh Page updated November 6, 2026 · transcript and summary are machine-generated