AI Agents By the Bay Ep 1: Why AI is Still Software Engineering. Inside Py AI, Community, and Code
Everybody, I'm Alexi Krabro, uh, the host of the Agents by the Bay podcast, which we do with Ole Dinov. We're both co-ounders of AI by the Bay conference. And here with us, we have Samuel Culvin, the founder and CEO of Pentic, and he also was the keynote speaker opening the AI by the Bay last November. Welcome, Samuel. >> Thank you so much for having me. Great to be here. And today we're going to talk about PI AI which was a fantastic conference which was held for the first time on March 10th at check 15 in San Francisco which is the cool kids AI capital of the world and uh it was I think the first time which uh was the very strong uh message that AI is still software engineering. It was on the banner right there
I was a volunteer there. The first thing I've seen pedantic team set up was this banner. So can you tell us a little bit about uh kind of the idea of this conference and why AI for software engineer is still software engineering was the first thing you put in big letters on top of your banner. >> Yeah. Interesting. Um so we I mean I think that's been a kind of motto of ours for some time. I think for fun and profit there have been a whole bunch of companies particularly in California who have made a business out of telling you that AI is so somehow so profoundly different that we can abandon existing engineering practices that we don't need to know how to run Kubernetes because we know the difference between 03 and 01 or something some you know as if this this idea that that agents can solve everything and we don't need engineering and the reality is AIS are profoundly powerful they do crazy things that were unimaginable a few years ago but running them in production is actually harder running nonAI applications. All of the engineering challenges still exist
Plus, you have the the AI. Now, the the big change over the last six months is that coding agents can do some of that work for you. So, they can help you out with some of that stuff, but that's still engineering. Whether you're copy pasting some code from from Stack Overflow or doing the like glorified modern take on copy paste code from Stack Overflow, which is ask code or Codeex to implement it for you, it's still engineering. It's still your [ __ ] problem when it goes wrong. Are we allowed to swear on this podcast? I won't swear anymore. That's why >> I'll do it once. Okay
Um, it's still your problem when it goes wrong. And so those engineering challenges still exist. And indeed even more than the existing engineering challenges uh persist the new challenges come down to engineering. Stochasticism is not actually new. uh we just have most of us have got to lived in a world of low latency, high reliability where we can kind of ignore uh like stocastic stochasticism, variability, random error and we just have to go back to following those principles of how do we how do we work around that? how do we provide safeguards etc etc and so I I spend a lot of my time telling people that a lot of the concepts in agent development in particular are best modeled as as effectively code whether that code is written by you or an AI as in multi- aent systems >> oh do you have a multi- aent orchestration platform no I have Python code you define an agent you can call an agent in a tool if you want now you have a multi-agent delegation system you can call an agent and then depending on what result you get back from that agent, you can call one one of a number of different other agents. Now we have a multi- aent handoff system. All of these terms are designed to sell products, not uh uh not to extend our understanding and make engineering easier. And so that was that wasn't so much that that is like twinned with the reasons we organized the conference
Um >> I think that we organized the conference because we saw kind of two patches of conference. Uh and I would put scale by the bay, AI by the Bay in a different category, but like most conferences fall into two camps. There is the there are the the the open source community conferences like PONS >> which is like if you're being mood rude about it it's a bunch of tree huggers and sandals uh turning up to chat about their side project and then you have the other bunch of conferences which are to quote Adam 15 info commercials in a uh in a trench coat. >> Exactly. and and if you're not and then there's the vendor conferences which are even worse because they're the same info commercial 10 times in a row in a trench coat and so could we design something that is like real people putting stuff into production run working for commercial companies who want to discuss what what works and what doesn't but have maintain that high engineering rigor and high engineering quality and have real conversations that aren't info info commercials. >> Yes. And that was beautiful. So maybe let's like do a little bit of an overview because uh I've been fortunate to attend the first PI AI meetup that you hosted with Adam Aziz from fast MCP and other folks were like Charles from model like all the familiar characters who in uh kind of our niche slice of community we know these are the great engineering people but what struck me that you like went much further and everybody you gathered in these two tracks
They were builders, right? Like there was no [ __ ] anywhere and like it's fine to promote your startup as long as you teach people some engineering and like every single talk was like this. So, so you managed in a relatively short time to assemble really representative community of builders and engineers, right, who use Python for AI in very thoughtful ways. How did you manage to do this? Where did you find these people? How did you meet Adam? tell us like your community building uh process how how did that happen? >> So going back a bit as in you're right that we assembled the conference in a very short time. I think we agreed to do it in November but I was able to to message those people because I've been maintaining Pantics since 2017 whether people use it lots or not. I mean most people use it a fair bit. They respect me as someone who's gone and built an open source project and maintained it for years and now now runs a company. And so that is that's one part of it as in you know I had I had gone for a coffee with Guido uh a few weeks before we agreed to organize the conference. So I was able to email him and just say you know any chance you might be willing to come and talk at our conference
I think Guido doesn't generally talk at conferences anymore but he did it as a as he said to me at the speakers dinner no good deed goes unpunished. I go for coffee with you and now you make me come to your conference. Yes. >> Um >> but but so it's it's you know and and like Armen Armen and I have like some hot hot hot different hot takes on things and we disagree on a few things. Uh but like in general I think you know I have enormous respect for Armen. I think he has respect for me and so though he's able to come to our conference in a way that like some random AI startup that's been around for six months whose open source projects has got 5,000 stars from nowhere without any credibility. He's going to be like I I don't know speak for him but I think he's less likely to to come. Mhm
>> Um, same with Sebastian, right? Sebastian and I have worked together, him maintaining Fast API, me doing Pantics since >> 2019, right? Uh, we didn't meet each other until 2021 or something, but we've worked together one way or another for, you know, closing on 10 years. And so, of course, when I say do me a favor and come to my conference, >> he will. And then the other side of it is, as I say, with the exception, there are some good conferences, but there's an awful lot of [ __ ] conferences in in San Francisco. And so for those people to come to a good conference isn't always that easy. Yes. >> So when they get invited to come to a good conference and they don't have to like >> it's by invitation. It's not like please submit your CFP and see what happens. It's like I know who you are Sebastian
Obviously if you'll talk we would always have you. >> Uh that that that means people are are fairly willing to willing to come. >> Yeah. And you know I met some new folks like Nam Gavin right like I haven't heard about her honestly and she was amazing. like some people who you know is it through paid is it through the network because some some people are amazing and even I I've been here and for you know for 20 years you know about them and learn something new how did you find these people >> so ne I met I is British as well so I ran into her at the AI >> uh well she she's a British accent but yeah her family is Irish I think originally uh but they I met her at AI engineer in New York and we were we were sitting around basically criticizing or bitching about our competitors uh and all of not or not not just like all of the companies and who's who's good and who's bad and so I met her met up with her a couple of times since then when I'm in San Francisco so I said when we were having a conference she was you know top of the list of people who I said you know please come and talk no that's amazing right and so uh I want to kind of dig a bit into the engineering side right so because so first of all what struck me right like there are five events in San Francisco every single day. So you know I run Bayer AI which is the oldest continuously running meetup and AI by the bay is kind of a version of scale by the bay and data by the bay which is continuously running independent conference longest standing still and like like you described most of the conference of vendor conference come to us we'll do digital transformation and synergy for you and just buy just swipe a credit card just tap it and like things in the cloud will happen right like that's not fun so uh and I thought to me given the bunch of engineers years in the community, it would be self-evident. Like I thought like the moment they're going to post it, it's going to be sold out. But it took a bit
And so what I found is it's really difficult. It's it's it's a news to me. It's really difficult for people to understand that what you're uh describing is is the foundation. It's it's like it's it's not debatable. You have to do it or your whole freaking thing will fail. And so it's really struck me that people don't know this. So maybe what I'd like to do, I'd like to go into how you added things to paid and I'll tell you kind of my bestiz version of this and you can tell me how it actually happened. Right
So so basically and this is why you know I told everybody we invite you to keynote AI by the Bay because uh this is totally aligned with our vision how AI and distributed systems should be built right. So here's my kind of very uh personal. Yeah, if you want to like start yourself, you know, feel free. >> I agree with you. I think one of the I agree with you. I'm sort of, you know, we sold out two days before the conference, which in some ways is perfect, but kind of surprised we didn't sell out soon. I mean, obviously everyone does stuff at the last last thing. But >> as Randall Randall Monroe says, XKCD says, >> obviously uh 50% of people are below average intelligence by definition
>> Yeah. >> When people say everyone's dumb, that's not true. An average person is of average intelligence. But if you are like of course there is only 10% of people who are in the top 10% of like caring about quality again by definition. And so if you're basically >> um targeting people with taste and dedication and concern about quality, >> you are by definition targeting a subset of of the of the like engineering base. like half of engineers >> are below average ability and and those guys are like, >> you know, slopping out lang chain apps uh until they're blew in the face. Good luck to them. Like but but if you're going to go and have have something that's about taste and quality and like turns out you need to be an engineer
One of the things I'm learning is the the the marketing line, it's still engineering. You need to do the hard yards and learn the engineering is not attractive to lots of people who are earlier in their career who would like to think that they can go and build their billion dollar startup without learning any engineering. They can like claude code their way to to to fame. >> That's right. And I don't know of any single app which was by coded to be become unicorn. Right. So I mean to me this is self-evident but this is interesting because I also heard from >> maybe maybe Claude code I say Claude and anthrop I mean and you see their up see it in their uptime but like I feel like anthropic and open AI are like living experiment in how far you can get with with like vibe coding but anyway >> no at some point I wanted to invite Boris Journey to my meetup the creator of cloud code and what I found is in 2017 we were the both meetup organizers hustling together to bring community books he was leading at the TypeScript meetup Right? And then he went to meta to be the TypeScript lead. So it's not for nothing
It didn't come out of nowhere. Right? like Boris was building things with Typescript and Typescript I think very nicely links to this to my point that there are foundations of software engineering such as strongly typed things that really are important and the fact that it's not obvious to people again multiple folks in my strongly typed you know nerdy functional program community told me like the conference is amazing but you guys have a lot of work left to explain why is this better. So here's my kind of very short take and you can tell me you know if my I'm might. So like it seems to be like a very reasonable progression that paid is basically the first attempt which succeeded in bolting in a type system into Python which is what we expect from like storing the type languages which is basically properly typed then it's built in Rust. So like effectively we kind of you know put in fast and performance system and uh if you look at what happens in this agentic workflows people get data from all kind of stuff like they scrap CSVs they get text logs from Apache servers like basically like where all this data is coming from so this was a big chunk of scale by the bay that AI at scale means like you have distributed systems are pumping data into the AI so now all the CSVs all this JSON they're laying around somewhere unless You parse them into pantic object and never touch them again. You parse them, you validate them and they're done. Right? If people are not doing this, it means they're constantly exchanging blobs of text which are parsing maybe by different version of parsers and different systems which are bound to like so from the very foundation. If people are not doing this, they have no way to validate that the object is correct
They cannot serialize the serialize it quickly. And if you are agents, if your multi- aent system is a distributed system, your exchange object, they should be in a tight binary shape which you can validate. So people, that's why Google succeeded with protobuffs like that proto buff was a big thing. Again, most people like don't really use them for some reason. uh now so so again like that's kind of my vision of this like so you you build this and so it was easy for you to move into AI because you have the main foundation you have the interchangeable uh validated object which you can reason about and now it's easy for you to build pentic AI is you know agentic framework because now you exchange these things and now log fire you are logging like everybody is you know crying about observability we don't know all this agents are doing so you have the logging system so you kind of very systematically addressed you know elements of uh AI and and then you have you know the gateway so you can have different models and then you built Monty which is like an execution in in a safe environment. So it seems to me that you're repeatedly successfully hitting all the engineering steps falling one from the other and like how can it not be obvious to people that that this is what you should be doing right so like I think like we need to explain it to to the people. >> I agree with you 100%. Uh I think that the I mean the problem is that like the people who want to who people who get that get that and it's very hard to persuade the other lot
They're not listening. So it's like I mean look >> I would I would happily go to the the Langchain conference and give a talk and be like here's an alternative take. >> I offered to go to the master conference and give a talk about Python as an alternative because that was like TSC. It was like all about Typescript. I was like surely there's a world where you have an interesting Python talk. Like you know there was an amazing talk somewhere online where they invited someone to back when Jupyter notebooks were a massive thing they had a Jupyter conference and they had someone come and like roast Jupyter notebooks in one of the talks. Yes. >> And the whole room is in hysterics because everyone gets all of the problems >> and he's like I love Jupyter notebooks but here's my attempt to roast it and you know we invited Harrison to to Pi AI >> um and he he politely declined
Uh so I think that that I would love to for there to be more like you know friendly but friendly dis you know uh disagreeing agreeably between the different sides of of this debate. It seems to me the other side are not that interested in having those conversations. Going back to your point about about like type safety and constraints I totally agree with your take. My opinion is that we you know if you look at the arc of software from let's say 1990 onwards we don't need to go back into ancient history but 1990 for most of us is already ancient history um we had C++ we had Java and everything was very typed and we had Postgress and we had my SQL and so the data in the database was typed and the the language was typed and all was good and then we had Python and JavaScript come along and they were less typed and they were a lot quicker to develop with and so there was this period of expansion where we were like oh we don't need types oh this isn't necessary we can just like lob around untyped data and then MongoDB and Reddis got big and suddenly we could store stuff in our database that wasn't typed either. We just like throw JSON here, throw JSON there. Oh, we don't need we can do like gradual migrations, no downtime. Seemed like a great idea. And then the the the >> the process since about making up a number here, 2012 or 2014 has been that people were like, oh, turns out that's really [ __ ] annoying in lots of different ways
And so we've had Typescript come along as a like way of adding sanity to JavaScript. >> We've had typing in Python come along in that time and we've like got more and more types in the Python code we've written. We've had Postgress has you know like got you know it's been around for a long time but it's got ever more popular and MongoDB has be become in general excuse me less popular amongst um amongst most developers. Um, we've had like Reddis have a have an OM built with Pyantic, right, which is one of their recommended ways of using Reddus with Python. >> Um, and we've obviously had languages like Rust come along and get a lot of get a lot of attention where everything is like even more strictly typed. And so, so there has been this like like basically we've pulled back since about 2014 and we've gone back to like let's take these type unsafe systems and basically add constraints to them so we get some of the best of both worlds and so and pantic is not seinal in that it's somewhat relevant in the in the history of Python but it is basically a one of the steps along the way in terms of pantic itself pantic validation in terms of that like movement from unconstrained and and um lack of types towards towards a like runtime type system. Uh yeah, I I agree with your with your take. The other thing I would say is we are in a weird world right now with Python
>> Mhm. >> In I was speaking to Thiago no to um uh GMO from from Vel and he he was saying like in in JavaScript world it's total victory for Typescript, >> right? >> No one would ever consider starting a project in JavaScript today. If you're writing anything for that ecosystem, you write TypeScript always, >> right? Even though you have this annoying transpile step and you can't just debug TypeScript even though there's all those complexities and overheads, you would always write TypeScript. And yet we and secondly, we know that the one thing coding agents want most is type safety. We know that it is this like benign very fast way of them getting feedback on whether they are semantically correct. >> Yes, >> it is the single easiest thing you can do to make your codebase easier to use for an AI. And yet the preeminent stuff going on in Python are libraries which are either completely type unsafe like langraph and and lang and and have you know the still today for a little bit longer until we ever take them the most downloaded uh AI libraries. Um and and and it makes no sense because though you know the people who are bullish about AI, why would you be building something with something that is like inherently hard for an AI to write, >> right? >> Now to be fair, Langchain, you know, poached some of our team and and and have now used those people to go and basically copy us and become as type safe as they possibly can
Uh and you know, or moving towards greater type safety in their v1 releases. So even they see that like type safety is important. But like until now we've been in a weird world where the where the where a lot of that stuff is not type safe. >> You know it was interesting to me. So like I I'm not a great Python programmer. I like Scola or Camel Hale. I like very complicated languages. For a long time for me Python was like JavaScript
Like I'm trying to grab something and I'm I'm grasping air. Like I don't feel my types in my hands. So Pendanti gave me first of all for the first time the pleasure of having something solid. And so what I've done so I like I you know last year like I like everybody else I went on like a giant you know you know spree of like VIP coding tens of thousands of lines of code like rebuild complete like systems which I wanted to build forever and so but what I figured out I will do and it really worked very well. I told my cloud code first. So like I had to download like I did the crawler right? So I downloaded a bunch of uh data from the web. uh it was in like an old school guy kind of I know it always can fail so like I'm hoarding thing JSON objects uh and in my download directory and like now I need to represent it and load in the database so I tell cloud code model all of this uh JSON as pyic objects infer the schemas right and and build me kind of the parser so now I basically tell any vip coding project the first thing we do we model our data as pantic objects And by virtue of doing this, if we agree that this is what the data looks like, then you never have problems. And to me, how can you not do this if your multiple attempts in different web coding like some guy comes with cursor, some guy comes with plot code like unless you you properly agree, you will have subtle bugs
So it's the easiest thing, right? Like start by modeling your objects as pentic objects, you'll get efficiency, you get on the wire efficiency interchange and your system will be correct. And like so to me like you know uh like we briefly talked that you know at PYI I think like this like there are people selling protobuff registries for Kafka and like this is a big thing Kafka schemas uh not a solved problem. There are startups like B whose whole business is maintain enterprise directory of uh data models. So you know we on the one hand we will have specs but on the other hand we have to agree that this is what your data looks like because data cannot be recreated through a spec every time by different engine. data is something you have to fix and uh to me uh that's how you should write code like do you would you agree with this is it a good approach >> yeah I would agree and and I would I mean there's even more primitive things than that right like the first thing you put into I would put into my claude MD or agents MD file would be >> everything must be fully typed you must fully type things you are targeting Python 314 everything must have types and then I would say you must run type checking at the moment I mostly use base pyite you must run type checking immediately medately after you have finished a task and fix all typing errors >> and it like massively improves the experience because I'm like I don't have to worry about you know I'm going to get it back a clean file where everything is typed might have its own mistakes but like >> I'm going to get that and then the amount of time that that saves I mean >> I I would go further and say that I think more and more code will be written in languages like Rust where you get you have to do that and where the typing information is even stricter um I mean there's going to be two there's going to be just in time code, the stuff that Monty is is perfect for, or or if you want to use a slow, expensive sandbox, you can. >> And that stuff is going to be Python or JavaScript because no one, you know, if you're if you want your model to run in 300 milliseconds and maybe you're prepared for it to run for 5 seconds, you don't want to have to compile your code for 35 seconds before you can run it. Whereas with Monty, you're looking at a like one microcond boot time. You're like, "Yeah, cool
I'll pay one microcond to run some code." Um but yeah, I think in in in the code that is not just in time that lives in git and is the like the persistent state of my like application logic. I think that will be increasingly in in Rust. I know the Zigg is currently very trendy and that's the way to do it. I don't know why you would move from a type- safe language, sorry, to a memory safe language to a memory unsafe language. I don't get that, but that's the cool kids, you know, the really cool kids are doing it in Zik. >> Yeah, good. >> It's still better than JavaScript. So uh so uh I want to kind of uh uh double click on lof fire because I remember at some point you tweeted hey guys it's very nice you are like legion of the free tier of lof fire but we need to jack up I mean increase the prices because we have to pay for this infrastructure to me it was signifying the success of logf fire
Can you talk a little bit uh how did you basically come to build lockfire? Why did this take so you know people take it up and and like basically to the point where you have to really increase the prices to pay for it. It means like it's a huge uh success. How how did you how do you see people using why do startups use it and like uh what's the main advantage of using fire as observability framework? >> Yes. So I wanted to build what I would have then called nested logging and now you know is tracing formally from like 2019 onwards and I think I only bought the domain name in 2019. I really wanted to build a better way of a better print fundamentally. And the two big things I wanted was like being able to display structured objects and be able to have this nesting tracing effectively but it's a field just like logging. I could do you know uh logger.info but I would get like structured pretty structured data and I would get um tracing and I would get the capacity to go and access that data those attributes as you know in a analytical form. Mhm
>> And so when we raised money for pitantic the company, we looked around for what to go and build and we came back to like developer observability in Python is not a it's not a solved problem. That was like this AI was just starting but we weren't particularly you know we weren't doing it for AI. We were doing it for developers. >> Obviously what's happened in that time is the AI has eaten an enormous chunk of what's of the attention definitely and also of the like and and for good reason a lot of the attention in in Python or in development. And so today, Logfire is an AI observability platform, but the big difference from the others is it's a full observability platform. Logs, metrics, traces, fullel, everything you're doing at a reasonable cost with a like enormously scal enormously scalable in a way that as I understand it, the other AI observability platforms a are heenously expensive per span. So you can't send everything and two, if you do, are not scalable enough to like view those traces and scroll through them. Um, so why do people use it? I mean, I like I was looking this morning at we do a survey of people when they upgrade and I will be analytical for once rather than just like make up some stuff on a podcast
>> The number one reason people ch people say they like it is ease of use. >> You know, we come from that open source background about caring enormously about >> developer experience and and it comes back to my point at the beginning about AI is still just engineering. We we believe in trying to make things that are complicated easy not things that are easy seem more complicated than they need to be >> and in principle setting up tracing should be you know two lines of code or one line of code log fire configure and then instrument say py or fast API or whatever you're using >> right and imagine structured objects and like obviously pantic provides structured objects so like it's natural to log it using log file like so this to me like you have to have one with the other so it's a very natur >> I think you have to have one with the other I think you can um I I think you can you can get value out of uh you can get value out of logfire without using padantic and you can definitely get enormous value out of padantic without using logfire. >> They both I think they both care about DX that is the kind of spiritual origins why the spiritual origins are the same. >> I would say um the the I mean I'm I'm looking here the other the other top top reason for why people use it is that it's general and AI observability together. Yes. nothing else is that there's there's obviously the data dogs and graphers of this world which have some AI functionality but are fundamentally infra observability or that's where they come from and then you have all of the AI observability startups who are like apart from us are all we're doing is looking at your LLM stuff >> right >> and we're the only people doing doing both and then the the third bit the third reason people talk about is um the panty AI integration so there lots and lots of people are using our agent framework they want the observability and the nice integration they get for free. Now truth is we're following open standards
So Pansky is emitting standard compliant hotel open telemetry and logfire is receiving open telemetry and you can connect the two to anything else. There's a little bit in the eval space where we have to do some custom stuff but like >> we believe that if there's an open standard we should follow it >> and we are that seems like a complete another completely and utterly obvious thing. Why would you ever do anything else? And yet naming no names our competitors you know go and build their own proprietary formats whether that is for like business reasons or for knowledge reasons I don't know >> no that's awesome so I guess maybe kind of we'll come a full circle and go back to pi so like we have this foundation we share this view of you know strong types observability right like rigorous software engineering and so uh I just wonder how would you kind of maybe you can give us some highlights because for instance you had fast MCP uh with prefect as kind of co-founders you have fast API what really struck me Ben Hman whom I knew more than 10 years creator of masses right I knew him since then he basically started this company called reboot to create coherent microservices which he knows like going back decades and now he looked at durable MCP like you cannot really reboot your MCP and now he's doing MCP app so we have a combination of folks who are on the one hand like doing totally crazy things like you know general intelligence company of New York, right? On the other hand, they have like OG's like Ben kind of bringing their expertise in microservices to this agendic era. So, uh what were your highlights and how like what do you see as a theme kind of going through this pyai talks and people? >> Um honest truth, I was so busy during the day organizing and speaking to people that I didn't get to listen to that many talks. Um, so I'm really looking forward to them all going up on YouTube in a couple of weeks and actually getting to go back through and listen listen listen listen listen listen listen to them I mean uh egotistically one of the highlights for me was being on the panel with Guido that was a and Sebastian uh and Jeremiah from from Prefect that was a like um that was amazing having le uh who works with us at Pantic um sharing was great so that that was a like I guess the personal highlight for me and then in terms of talks I'm really looking forward to going and listening to for example Armen's talk on as I understand it, trying to define what's going on inside the models coming down the line. Um, I I'd listen to a bit of Jeremiah's talk on their new like um UI component toolkit for fast MCP, which is uh somewhat inspired by the fast UI work we did a couple of years ago and then ended up abandoning. Um, uh, yeah, >> like reasonable reasonable software engineering title, right? Like that sounds really really nice. Yeah
Yeah. And and the theme as I said earlier is like experienced, knowledgeable builders talking honestly about what they're doing. And and the the funny thing is we didn't do any telling people what to what you know what what they should talk about. We just we just chose the right people. >> And I think that you know the first few people will probably have given a pretty good good idea of it and then from then on um you know we had Pamela Fox from Microsoft. Uh I heard a number of people tell me how good that talk is. Again I'm looking forward to listening to it. um lots of lots of amazing talks
Um and you know like um Hamza from ZenML mentioned Zen ML but I think a lot of his stuff was was talking about more interesting concepts because you know the conference let you talk about whatever you're interested in and sure you would like talk about your your startup or the product you're building or or what what you're doing but there was definitely the freedom of like >> the freedom to go and talk about what you're interested in and not have to have it as a as a as a as an info commercial. And lastly, I suspect there were lots of people who looked at the list of speakers and were like, I got to raise my game. And so I'm not just going to go and give the like standard demo of my product. I'm going to like, you know, speaking at the same conference as as Guido and Armen and Sebastian better damn well uh you know, up my game and not just give a give a preview of my product. And so I think that helped with the quality, >> right? You know, another thing which struggled because, you know, as a volunteer, I came in early and I was sitting on the steps with with a Dutch guy from Mexico City who was waiting to be let in and I showed him how to do it and then like I met a bunch of your teammates and like they're all smart people from all over the world, right? How did you assemble this team? Because like everybody is a great engineer and like it's all distributed. How did this kind of rock band come together? um through through I think we got I got really lucky at the beginning that the first the first few people who joined David Montigue who had done some stuff on fast API and maintained paidantic uh Adrian who had done some stuff on fast API and Starlet and things like that um Marcelo obviously is like maintainer of Starlet and new vehicle and very very well known um Hassan had been doing some stuff on Django David Hwitt who was one of the first to join was obviously like very very well known for maintaining PIO3. So th those were the like very first people to join the company. And so the basically the open source caliber from the first whatever that is five people basically set the tone for for the rest of the company
And then because of that we then go and build good software like DA was a we had never met DA but he was a contributor. He was trying to build something with Padanski found a bug fixed the bug got chatting to us and joined two weeks later because of the the engineering quality. And so I think that is you know you when you start a company you kind of accidentally set a company culture. >> Um and the company culture we set was like friendly but engineering doing engineering properly and like no [ __ ] >> high bar >> high bar and and like yeah like we're kind to each other when we make mistakes but like you work around a bunch of people who are very technically competent and that like raises the bar for everyone. Um yeah and then some people who've joined who haven't like fitted into that structure or haven't worked hard enough or haven't had the ability haven't haven't haven't stayed with us and so we've like you know some of it's been deliberate and from me but most of it's like if you want to work in a team like that you you know you probably have a certain mindset and a certain work ethic. Yeah, I mean it's again it impressed me how the kind of company culture reflects the messaging of this event, right? Like it's it's very much like and so I guess we'll wrap up on the question. Obviously you did the PI AI meetups in San Francisco in London and obvious now you did this conference and I think at the end you and Adam mentioned that if you guys want the road show to come to your town talk to us. So what are the plans to bring the enlightenment of AI software engineering to cities around the world? Yes
So, I think we like we're keen to organize PYI meetups anywhere. We don't even need to need necessarily to be there, but we'll happily like contribute via via a call and via putting it on socials. Um, but but we would also love to come if we can. I think we will be having one in I think it might be Vancouver, but somewhere in in Canada later this year, a meetup. We will have more meetup. We have a meet up in London in April. We've had meetups in London before, but we'll have another one in April at the same time as like as a kind of side event to AI engineer in the evening, which I'm talking at as well. Um, and then we might have another conference late this year, maybe in London, maybe in San Francisco
I think it was uh successful enough that we would love to do another one. >> Absolutely. Well, that's awesome. You know, we'll be rooting for you, helping kind of raise awareness. Thank you so much for sharing this with us and looking forward to all the talks, you know, on YouTube and more great events. >> Thank you so much. Thanks for having me. >> Thank you very much.