The Peterman Pod - OpenAI Eng & Dev Tools Founder: How Software Engineering Is Changing | Charlie Marsh

Episode Date: June 22, 2026

Charlie Marsh is the founder of Astral, the Python devtool startup that was acquired by OpenAI. I inteviewed him about how software engineering is changing and learnings from starting his own company as an engineer.• My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/• The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-donePodcast links:• YouTube: https://youtu.be/Iw65FD4MGgs• Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835• Transcript: https://www.developing.dev/p/openai-eng-and-dev-tools-founderThank you to this episode's sponsor for supporting my work:• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/Timestamps:(00:00) Intro(00:40) Origin story(06:04) The front page of Hacker News(14:35) Why he chose Rust(20:10) Full codebase migration from Zig to Rust(28:40) LLM generated code and open source(35:34) Performance optimizations(44:54) Optimization with AI and combating slop(01:02:08) Learnings as an eng starting a company(01:17:55) Top technical talk recommendation(01:18:56) Advice for his younger self(01:22:00) OutroWhere to find Charlie:• LinkedIn: https://www.linkedin.com/in/marshcharles/• GitHub: https://github.com/charliermarsh• X/Twitter: https://x.com/charliermarshWhere to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpetermanReferenced in this episode:• Python tooling could be much, much faster: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster• The coolest PR he's ever seen: https://github.com/astral-sh/uv/pull/789• Andrew Kelley’s data-oriented design talk: https://www.youtube.com/watch?v=IroPQ150F6c• Ruff: https://github.com/astral-sh/ruff• uv: https://github.com/astral-sh/uv• ty: https://github.com/astral-sh/ty• Salsa: https://github.com/salsa-rs/salsa

It's such an interesting time to be building software because things are just changing so fast. This is Charlie Marsh, founder of Astral, the Python DevTool startup that was acquired by OpenAI, and I interviewed him about how software engineering is changing. Now it's like when you put up a PR, I actually have to review it really closely because you're not like writing it anymore. It's like the agent. The cost of putting up a plausible PR has gone to zero, while the cost to like review has remained the same. if they're building so heavily with agents, like to what degree do they need to understand

different parts of the code? I do think it would be like really hard to be an early career software engineer right now. Here's the full episode. What was the space like when you were first getting into building these dev tools? Like, why did you think it could be better? Before I started Astrol,

I was at a computational biology company and I was like the second engineer. I had no bio background and no like ML background and so I was building all the software systems to do machine learning and so that was like all Python so I was like learning Python and we had some Go and some Rust

and so I just worked across lots of different ecosystems and you know I think Python at the time like when I was in that position I we were trying to do a lot as a small team so we had like a very I mean not compared to large code bases but we had a comparatively large

code base and it was really a small group of us that were software engineers trying to serve the rest of the team, whether they were like machine learning researchers or scientists. So I had kind of like worked across a bunch of different ecosystems, seeing a lot of the tooling. And now I was like working on Python. And we kept trying to get lots of leverage out of the tools, whether it was like the type checker or the linter or the package manager. Like things were scaling up. We were a small team. We wanted to have like really good static analysis, really good tooling. And we kept running into like limitations around it. I mean, I think there were some, I kind of like looked at the Python ecosystem and I just

didn't see the same amount of like experimentation that I saw in other ecosystems. Like in the web ecosystem, there were a lot of things going on that seemed pretty crazy. And there was a very intense focus on perform. I don't know about very intense, but there was more of a focus on performance. And that started with like ES build and then, which was in Go. And then you, had like SWC and Rust and then you know, Bun and Dino and all these other tools that came around. And this idea that you could have native tooling for JavaScript was like became very accepted, especially as applications became bigger and people were doing like more and more stuff on their machine. And that wasn't really happening in Python.

And so that to me was kind of like the key question was like why can't we have that? because I was seeing all the stuff that was happening in web, and I had done some rust, I'd done some go, I'd like seen these different tool chains and like how they work with the experiences, like the user experience, right, mostly in those cases. And then I saw Python and it was like, we had a smaller set of tools.

There were lots of interesting ideas from other ecosystems that I didn't see represented. And they were really all written in Python. And so that to me was kind of like the interesting question. And it was the first, it was sort of like the first thing I asked when I started working on this. Like when I released Ruff, the title of the blog post was something like Python tooling could be like much, much faster. And for me, it was really like, this is a hypothesis. Like, could Python tooling be much faster?

And then I built a prototype. And then that prototype was like, yes, I think it could be. You wrote a post kind of like exploring my Pai or publishing your results, using my pie. And the date on that, like nine days later, you publish the post, that one that you mentioned. Like, it could be so much faster. Oh, that's funny. I didn't even realize that. Yeah, that those were so close together. Did you build that proof of concept in those nine days? Yeah, I wrote that, I wrote that blog post about basically type checking at scale because I was trying to think of what are things that I learned that people haven't written much about. And then I started

with building a linter because I thought it would be much easier. I think it actually is a lot easier than building a type checker. We're now building a type checker, and we have a type checker. And so I can say that I think building a type checker is much harder. But I started with a linter because I thought it would let me like prove a lot of the same ideas, but in a smaller form factor. Like building a startup or just building like a tool, you want to try to like get something into people's hands that they can actually use

and that actually proves out value, like, as quickly as possible. And also that lets you iterate very quickly. And a linter weirdly ended up being, like, kind of the perfect form factor for it, because it has, like, a pretty simple core, but it's, you know, then you have, like, tons and tons of rules, right? And so it's, like, extensible in a lot of different ways. But people can get value very quickly from a small core plus, like, some number of rules. And so we were able to, like, get something out there.

and then like, iterate and like ship like more rules and more functionality and people could like use it alongside other tools. Like it was useful immediately, which I think is extremely helpful as opposed to something like, I mean, actually the type checker would be a good example. Like a type checker that's like 75% done like isn't very useful. Same with the package manager. Like these things have to be, I mean, there are ways like I think I would challenge those as like blanket statements.

But the point is it's hard. to ship something iteratively that's like still useful to users. And I think that's like one of the key properties and actually like building momentum as like a tool or something else. When you posted that writing, what was the reception? I mean the blog post itself, like I published it and then it was on Hacker News and it got tweeted about a lot and it just created some, you know, some amount of excitement and interest around it. And those things, I mean, especially being on the front page of Hacker News, I have a lot of

thoughts about. I mean, it's certainly not, it's like some percent luck and then some percent skill. And it is like a helpful thing, but not a requisite to success. And it also doesn't like guarantee success just because you got something on the front page of Hacker News. Like, it's great if you can, but there's a lot of randomness to it. I do think, though, that, well, maybe a couple things. So one, after that happened, like, some people started actually paying attention to the project. And so I really tried to, like, capitalize on that by, basically by being, like, very engaged. And so when people would file issues, I would, like, aggressively try to, like, acknowledge the issue as quickly as possible, fix it and ship a release.

like if you can do that within one day it's like a very very powerful loop like you gain supporters and like create more momentum around the project and there were also a couple like high profile people in the ecosystem that started paying attention to the project like Sebastian Ramirez who did fast

does fast API and you know a bunch of other things and he's been a great supporter of our projects too but like early on he was like oh this is interesting I'd like to use it and I was like I basically asked myself well what would you take for him to use it and then I just like tried to do all those things So I tried to capitalize on that.

I think the other is though, I do think a lot about like developer marketing. And it's sort of like a dirty word or like a dirty expression. Like I think like a lot of engineers like want technical products and tools to just like win on their merits. Like the best technical solution should just be the one that like wins and grows. but I actually, I mean, I have this sort of like stupid hypothesis that there's all these like, there's like thousands of like really amazing projects on GitHub that like basically don't know how to market themselves. And so never like never get discovered and never go anywhere.

And I don't actually know if that's true. But it's like sort of how I feel about a lot of technical work where it's like it's actually worth looking at a project like rough. And when I think about like what to put in the blog post, or this extends to like what to put in the read me or like what to put in the you don't need like a million emojis and like and like a million screenshots of like everything what you need is like okay someone's gonna like land on this page and I have like 10 seconds to get them interested in what I'm doing and help them understand like why it might matter to them and like why it's useful and so like that was like that's like the key idea that I try to bring basically to everything I'm I mean, it's a little bit depressing because it's like, okay, I only have like 10, but like people, people really don't have like, like, this is like the attention economy, right? It's like, it's same thing with a blog post. Like, um, ironically, I used to look at a lot of the open AI blog posts when I was at spring and we were trying to, we were doing like machine learning in bio and we were trying to publish material to like explain what we do. But, but we had all these interesting insights. Like we looked at the open AI blog post, especially like the dolly ones, like the older ones, like the older. ones and we were all we were like wow that's an amazing blog post because if you read none of the text you still understand what they did and you're still impressed by it like if someone just goes on

the page they leave with an impression and they have some understanding and I was like wow that's like a really amazing thing and so when I write blog post now I'm like if someone just lands on this page I have to be prepared for the for the large number of people who will only read maybe the TLDR, maybe look at the first image, maybe read the headline. Some people will read the full thing, and so I should care painstakingly about every word and everything it says, but most people will read like almost none of it. And so again, sorry, it's a little bit, like, it's a little bit depressing, but like, I do think it's worth thinking about your audience and like how do you, how do you explain to them, like why they should care about what you're doing in a way that's honest and genuine,

like not like, not like deceptive. But you do have to think hard about how do you communicate like why something matters to people very quickly. Could you give an example of like what you did in your case? I think like for rough specifically, we had a really good graph of the benchmarks that we put in the blog post and that like when it was like on Twitter. And like that that was like a priceless graph basically. Sorry, not in terms of like monetary value. I just mean in terms of like attention, right?

It was like, oh, that's like that's like really obvious. Like what's happening there. I think graphs of benchmarks can be like a really powerful thing. All benchmarks are bad and wrong in some way. And so there's a lot like, there's a lot more to like say about that. Like, but, um,

but I do think like having a visual hook that explains people why they should care and like what something is. Um, and having a really strong tagline like I would have to look back at what we had, but we were like, okay, we're going to be like compatible with your existing stuff. And much faster.

and that's kind of it. And it's like, okay, well, if it's compatible and it's much faster, like that was like, I was like, why should you care? Like, it can be orders of magnitude faster and it'll give you the same experience. You try to convey that like as quickly as possible. Right. And even the, I mean, that blog post header,

I mean, Python tooling should could be much faster, should be much faster. Yeah, yeah. It's a little provocative, I guess. Yeah. I mean, I'm pretty against like clickbait or, like trying to be misleading and like anything that we do like we we we basically want to want to balance like creating like effective like effectively communicating like the most

interesting pieces to people but you have to do it in a way that like you believe is like true and authentic um like you could lie about a bunch of stuff and like post interesting things that are like clearly provocative but like I don't know to me that's just like why would I ever do that that's like such a losing battle what what What do you think about, I mean, so you have that graph. Yeah. I don't know if the, I see this a lot, though, where the axis is not zeroed. Oh, yeah.

So it's, you know, it's all within the range of like 50 to 60. That's just chart crimes. Yeah. Chart crimes, yeah. I don't. I wouldn't do that. Yeah. Yeah.

I do think, like, benchmarks are pretty complicated and controversial, though. And maybe most people don't even see this controversy, but like I do because it's like, it's just very hard. performance is very nuanced. And, you know, like, you know, you have to think about, like, okay, with caching or without caching, those are, like, pretty different. Or, like, depending on the project that you're running on, the performance characteristics will be, like, totally different. And, like, we see this, like, in UV, this is really hard because, like, sometimes, you know,

UV is really fast. but sometimes your package install is actually bottlenecked on like a C++ build that's like totally out of band. And it's like, okay, well, so how do you like accurate? It's like, I mean, it's sort of impossible to like accurately capture like all of the different scenarios. And so, but it's also like a disservice to users like not to try to communicate to them like the importance or like a real representation of like what will the difference in performance. look like and why does it matter? And so you have to balance those things, which I think is actually quite hard. And a lot of people tend to get it wrong. And maybe we've gotten it wrong a few times, too. I'm like, I'm happy to accept that. But I do think it's more complicated than people think.

But it's also, I think, a huge disservice not to include like some way to try to convey to people quickly, like, what things feel like. I think one of the things I'm most interested in is, like, you mentioned that graph. I see that graph and, like, you know, the engineer in me. is like how did you make it so much faster? And one of the things in the tagline is Python DevTooling written in Rust. And so I guess one of the first thing I'm curious about is why did you choose Rust and what are the pros and cons of that? I would say I largely chose Rust for that project because of hype.

Like I don't think at the time I was that informed about a lot of the technical tradeoffs between those different ecosystems. systems. And I hadn't really done a lot of systems programming. And so that's like the honest answer is like I was seeing it in a lot of places and it was growing a lot. And people said it was like it appeared to be sort of like an accessible way to write. My impression was that it was an accessible way to write high performance software. And so I started for that reason. In hindsight, I think it was an amazing decision. And I would. absolutely not do it differently and I think it was like the best choice for what we're building.

And now I have a lot more experience writing rust but but it is funny because like I I do sort of think that if I had tried to write this in like C or C++ plus plus I think I probably would have given up because I find those even now I find those ecosystems much more like intimidating hard to access, hard to learn. I have often felt that like one of the great or like underrated advantages of Rust is basically like the tooling. Because like you drop in and you use cargo and that's how you do like everything. And if you clone, this isn't always true, but like, you know, there are exceptions as projects

get sufficiently advanced. But like if there's like a crate out there that we use and maybe I want to submit a PR to it, I'm like extremely confident that I can clone it and figure out how to run and build it without having to do like any work. Like being able to just clone and run like cargo run or cargo build or cargo test, that's actually like really amazing. Especially for someone like me who was like new to systems programming and I didn't want to have to figure out like my whole like C++ plus like tool chain and like build system like all this stuff. Rust was like opinionated about all of these things. And so there were a lot of things that were hard to learn. but I was allowed to like basically I was allowed to spend my time focusing on the things

that like actually should be hard to learn as opposed to like all the other basically all the bullshit that like you don't want to spend time on like how do I get this thing to actually like build and run and blah blah I think it has been an extremely good bet for us like it's scaled very well with the project and I mean we at opening I too are like we use a lot of Rust and they're like betting heavily on Rust and then you know me as someone who builds software for uh builds developer tools like tries to build software for people to build software I'm like very bullish on Rust um uh like it's grown um enormously and I think it will actually just like keep growing enormously um at the same time like I said this at the start

I've never been someone who's like super dogmatic about ecosystems like I think that like all those ecosystems have like lots of redeeming qualities like I think what's happening in Zig is like very interesting and like I wish I had more time to like go deep on it and like develop more nuanced opinions about like what it does better like I'm sure it does a bunch of things better than rust and there are I'm sure there are things for Russ to learn from that ecosystem similarly people have a ton of success building stuff and go I think that's great too I think like I think all this stuff is great but I have loved like using Rust and I have complaints about it, but I view those complaints as like things that we should improve, especially as like

the way we build software changes with with al-LMs. So if it sounds like you're saying C and C++ today, you would not consider them because their tooling is insufficient, but ZIG, Russ, and Go are all, you know, some spectrum of tradeoffs or different things. Yeah, I mean, I think I think a lot of people would disagree with me, but like I don't really understand. like why, unless there are like very specific technical reasons, or you're working with existing software, like basically I don't really know why I would start a net new project in C or C++ was. I certainly would not, like, at a personal level.

I guess if they're like the ecosystems you know really well, like that's, then it makes a lot of sense to do it. But if I was like a new programmer like looking to learn systems, or if I knew those languages equally well. Like I guess I just don't understand like why I would do that, which I'm sure I'll get like roasted for. But I, but I just don't really care.

Like now I actually care about a lot of things that Russ gives me that I didn't care about as much before, like memory safety. I don't think I even understood or cared about what memory safety was when I started working on rough, to be honest with you. And now I like, I think it's like a pretty amazing thing. It's like, you know, memory, I want to build things that are like safe, that don't crash on users that are really fast, really performant.

that don't have to make compromises, basically. And, like, I feel like I can do that in Rust. And so for me, it's like, I don't know, it's kind of like the perfect language. I mean, it's not the perfect language, but it is my favorite language to use right now. In today's world, it's not unreasonable that you could almost completely transpile or convert your existing code base into any language of your choice.

Yeah. Like I saw, I think it was on Bun. I forgot. I think it was Zig to Rust. Yes. like all in one go. So like if you studied some other language and you thought it was better, you could totally rewrite everything from Rust into, I don't know, ZIG or Go.

Would you ever consider doing that for the dev tools that you've built, for instance? Yeah. It's such an interesting time to be building software because things are changing. This is not a novel comment, but things are just changing like so fast. I didn't I didn't really program with agents at all until like Christmas like December break basically of this year and or last year rather and like that's really not that long ago like I mean I was like using cursor and stuff but like I wasn't like now like I have an edited code in an editor in a very long time like I everything I do goes through codex and like even if it's like small edits I'm just prompting and kind of like it's like it's it's completely different. And that's not that long of the time, right? And so I don't know what's going to look like in six months, hard to say. But so the reason that I mentioned that is like I think Bunn, like doing that rewrite,

it's like I wouldn't do that right now. But I'm actually like, I'm glad that they are like pushing, that they are experimenting and pushing the envelope of like what's possible. And you're doing it in the face of like a lot. lot of criticism and it will be interesting to see how it plays out for users because I think a few different things I thought about is like oh reasons not to do that like one is okay maybe you don't understand the code anymore right like if the code got completely rewritten quote unquote then as a human like you may not understand any of the code anymore and that can be a big problem

I think there are mitigating factors around that which are like they tried to do a very direct transpilation, quote unquote. I mean, it's not exactly a transpilation, but they tried to do like very one-to-one. And so that hopefully helps with like understanding all the abstractions. If they're building so heavily with agents, like does it even matter? Like to what degree do they need to understand different parts of the code? I actually don't know the answer to that, which is where my everything's changing so quickly comes from. It's like, it's actually a little bit hard for me to say right now how much that actually matters anymore of if they did transpile the whole code base, like, how well do they need to understand things at different levels

of abstraction? Like, they should, you know, it's actually a very, like, I think, a complicated question. So one reason is, like, how well were you understand the code? That's a confusing. The other is, like, you're kind of trading, like, when you do a rewrite like that, you're trading known issues for, like, new unknown issues. Like, imagine you merge that and it closes, like 50 open issues on GitHub in a literal sense. Okay, that's great.

But you may have now caused like 50 new issues that didn't exist before that you don't know about. Because your test suite is, even a great test suite, is only like an approximation of like your program's correctness. There's like Hiram's law, which is like anything, I'll get the phrasing wrong. But I mean, the gist is basically any like implementation detail in your software, someone eventually becomes to rely on that. And so even things that aren't encoded as behavior become part of your API, whether you like it or not, which is a scary thought. But basically that means that even if you pass your whole test suite, there's probably like lots of behavior that was like implicitly encoded in your program that's like changed. And the unfortunate thing is you end up pushing that onto users. Like they are the ones that have to run into that and then report it and figure out what went wrong.

And so that's like that's like my main area of concern with an automated rewrite. I actually trust the models enough that I. I would consider allowing them to do it. But the scarier thing for me is basically, what's the impact for users? Like how do you, and how do you roll that out safely? So, I don't know.

It's kind of a, we're not going to, like, we don't have anything plans to do that for any of our own projects, but it is like an interesting question. I mean, I think maybe like the third piece that I do think about, especially right now where like everything's changing so quickly. And there's, you know, basically the spectrum.

term of how you write software has like gotten like way wider. This is a terrible analogy, but there's like so many different ways to build software now. Like there's like the true like Andre Carpathie definition of vibe coding where you're like don't look at the code at all. All the way to like, you know, don't use LLMs and blah, blah. There's like a lot of different stuff in between. And I actually think that like right now I have pretty different approaches to different projects in terms of what I do. Like we, like I built, you know, a tool last week that was, it's basically personal software. It's like a custom rust linter to help us enforce certain things in our projects that

I've like always wanted to enforce but didn't fit into existing tools. And I didn't read any of the code. Like GPT-55 did the whole thing. And, and it's like, okay, I can have a really different standard for that than UV. Because that project, we are the only users. It's easy to tell if it's correct or not, you know, not to go too deep into the weeds on like what the project does, but like we know if the output is like incorrect. And there's no other users. UV is relied on by millions of, you know, millions of engineers and like all the, like every

single company. And so it's like we want to be really careful. about what we ship there and how. But there's a lot of room right now, I think, for exploring how we build software. You do have to be careful, what project are you working on and what responsibility do you have to users?

And that's not meant to be a sub-tweet on what Bun did. It's just like how I think about how do we want to push the envelope in different places. Right. I mean, to me, that just reminds me of the pre-LM trade-off,

like navigating the, I guess, the risk of the code change. and how much you verify it because if it's not risky, like it's an internal dev tool that only you and I are using. Yeah, yeah, yeah, yeah. Maybe I just ship it with, I just say stamp it. It's don't worry about it. It's not going to break anything.

But if it's, you know, the critical thing that's blocking customers from checking out or something, maybe we have two people reviewing it and there's like a lot of checks in that part of the code base. So it feels like the similar. similar spectrum is just now like there's a new level of trying less which is not just like a human doesn't even interact with it you just you know ship it and maybe you just stamp it and no one ever even looked at it right um whereas before at least to have written it a human would have had to yes yeah yeah yeah i mean i think well okay a lot of reactions to that so one i guess like the

other thing I would just say quickly about Bunn is like sometimes I go over to their repo and it's like it's just so different than our repo and it's very interesting to look at because if you look at like basically the number one contributor is like the Robo Bun bot and sometimes you'll click on PRs by humans and there's like human accounts talking back and forth but it's clear that all the comments were written by agents and you're like wow this is like very interesting and so I look at that but my perspective on that is basically like okay I'm glad that people are like that they are like experimenting with like different ways to like build software like I don't know that I'm ready to do that but like but like I do think that like a lot of basically a lot of things are

going to change and I think it's very interesting to be experimenting so I'm glad that they are experimenting with things is my sorry is my like conclusion there do you block like if people are just submitting a full agent stuff on your repos we do yeah so we have an AI policy now which isn't intended to be like anti-AI, but it's really like intended to because I mean, we develop like very heavily with LLMs. Like that is true.

But it's more intended to be like how do we how do we like retain like useful contributions while filtering out like net negative interactions from the repo? Because like a contributor coming in and posting a comment that their agent wrote, and then we asked them a question, and then they just paste the agent response back.

There's very little value in that, right? Like, we could just, like, ask the question to the agent, right? And so the things, like, we want to attain the things that are useful from, like, human contributors, which is, like, you know, like insight, like ways to reproduce, like, the information we would need to, like, plug it into our agent because there's no point in just, like, having a conversation with an LLM, on a GitHub issue, right?

Like it doesn't really do anything for us. And so we, you know, our policy is roughly, you should, you should like, you need to like understand, like what you're pacing in or what you are submitting, right? Which sounds like a low bar, but it's not. And- How do you police that? If we can't tell and it is agent written,

then I guess that's fine, right? but at least right now there are just lots of tells and like you know being way more thorough than a human would ever be including way too much detail way more formatting using terminology that a human wouldn't use like inventing random jargon tons of links like I guess the broad sign would be like putting in way more effort in ways that aren't necessary in a way that a human wouldn't is like almost always agent authored but it's been yeah it's been challenging i mean i think the hard thing zig has a much more strict lm policy which is like no lLM written code or no lm assisted code at all in the project which is very different than us i mean like all of my PRs now are our

lLM written right all i'm written um and they had a blog post about this idea of like i they called it something along the lines of like contributor poker where it's like you're kind of trying to place like bets on contributors, like historically in open source, when a contributor came around, they might be new to the project, but they could show signs of promise or like they're really engaged or really interested in like you give them feedback. They take the feedback and they fix up their PR. And then the next time they put up PR, they've learned from that feedback, right? It's the same way as like mentoring a new engineer who joins your team. It's like they learn from feedback. It compounds. They get better. And then they can actually mentor someone else in the future, right?

And so you're making investments in people in a way. It's the same for open source. It's like you want to, I thought about this law historically. It's like you want to like invest in good contributors who are going to grow to help others and be maintainers in their own right. That's kind of gone if for PRs, especially that are written by agents because people don't really learn anything. Like someone can put up a PR that's written by an agent and you leave comments and then they take your comments and put them into the agent and then update the PR and then update the PR and then. merge it and it's like there's no compounding feedback. And so I actually do like understand that perspective a lot of like the contract between like maintainers and contributors is like pretty

different now. And you know, relatedly, again, not a novel insight, but the cost of putting up a plausible PR has gone to zero while the cost to like review and vet a plausible PR has remained the same and is very high, like, especially for the projects that we work on where, you know, I'm not trying to, like, overstate it. They're just, like, hard projects. Like, Ti is our type checker. Probably hardest project I've worked on technically to, like, get a change merged because of the, like, complexity in the architecture, but also, like, the problem space. Like, it's just very, very hard. And so if someone puts up a plausible PR to Ti, it might take them two minutes and then it could take us, you know, an hour to understand it. And so it's created like

very poor dynamics in open source. And I don't know how we've solved that. I think it will like continue to get worse until hopefully it gets better in some way. Like we find ways to solve this. But it's certainly something we've experienced in our projects. Right. It sounds like review is becoming more and more of a bottleneck. Is for that bun rewrite, do you? Do you know if it was human, like humans read that code or that was just kind of? No, I don't think it was human reviewed. So it's just Yolo rewrite the whole thing? Yeah, I mean, in a way.

I think it's like, I think they did have, and I'm excited for like at least at time of recording, quote unquote, you know, Jared hasn't published the blog post yet, which is like, I mean, he keeps making jokes about how like the blog post taking way longer than the rewrite. But I'm actually really interested in the blog post because I think they did have a pretty, like, sophisticated. approach to like how the rewrite worked, which will be interesting to read about. Like, it wasn't just like they had one prompt that was like rewrite this in rest. It was like they tried to have at least my impression from looking at the PR is like there were, there were actually like different phases of the rewrite and like each file had to go through like a couple different phases that had like ways to validate whether it was correct or not. So the answer is no though. I like I don't think a human was reading like significant amounts of that code like it's just not possible basically what if we

we both agreed today that zigg was objectively better than rust and then someone on your team said you know i can do this rewrite into zig would would you block it if i think i would block it i think um i don't know whether i'd be right to do so but i think like we as a team like aren't there yet um And maybe we will get there and that's how we will feel eventually. But like right now, I think we just feel like right now there's still a lot of value in like deeply understanding like our code and our tool chain and like the ecosystem. And so I would say we don't want to do that. But it might depend on the project. I don't know.

All the things that you built, they're like an order of magnitude faster than what was available at the time. how much of a difference did Rust make on that graph? So it depends a bit on the project. I think in a rough, a lot of it was just Rust. And then over time, I think we've improved on that a lot. Because you can even look at the history of the project. like the project I mean hopefully no one like

hopefully this is still true but like basically over time the project gets faster and sometimes that regresses but like you know you basically maybe I put it differently you could write

rough you know in like a couple different ways all in Rust and they could have really different performance characteristics so that's just to say that like I generally think of Rust

is like the the floor or the that sort of like the baseline performance that you get is going to be significantly better. But you still have to, you still get a lot more out of like thinking deeply about performance and design. Like if you take the same program in Rust and in Python, like exact same implementation to the closest approximation you can get,

like the Rust one will be faster. But you can then take that program and you can probably optimize it another like 10x. I don't know about 10X. But my point is even within being written in Rust, there's like a ton of room for how to make things, more performant, how to write really performance software. And like, again, when I started working on rough, part of my goal was to learn Rust.

And so I did write a lot of like bad code, which is fine. Like I shipped something out that was really helpful to people. But it's gotten a lot better, I think, over time. And like, we've made it more and more performant. I think in UV there was more sort of like architectural innovation beyond just being in Rust, especially because UV, like, so as a package manager, you're doing a ton of I.O, like, downloading and, you know, downloading files over the network, unzipping things, like writing them to disk, moving them around. The Linter doesn't have to do as much of that. I mean, it has to read all your

files, but there's, there's not, like, a huge amount of I.O. The package manager is, like, mostly I.O. It's like, and then you're trying to do things, like, very efficiently. So there, it was more, I mean, Rust was important, but I do think that in UV there's more, you know, architectural things that we did or like ways that we thought a lot about performance. Like the design of the cache is like very, very intentional and makes it so that like repeated installs of the same package on your machine are like near instant because of the way that we like lay out the cache and the way that we install from the cash into your projects. It basically means that if you've installed a package before,

installing it again is extremely cheap. And both in terms of disk space and time. And so that's like a very different design than any of the other like Python package managers had. So again, it kind of depends on the project. I do tend to think that like whether you're writing code in Rust or in Python, there's like always room to like be thinking about performance. Like you can always make things faster or slower.

Like even if you're writing, in Python, like, you can still make things like much, much faster by, like, thinking harder about performance and design. So it's some mix, but it depends on the project. Open AI, Anthropic, Cursor, and Versal all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies, there's all these requirements you need to meet. There's SSO, there's SCIM, there's ARBAC,

There's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast. Over the course of the project, do you have a top few things that were implemented in the project that were technically challenging or most interesting to you?

I really like this optimization that Andrew on our team, who goes by burnt sushi, he's the author of Rip Grap and a bunch of other things. He's like really amazing engineer. He did this really cool optimization around how we represent versions. It's pretty cool. I mean, basically, like, if you think about resolving and installing, like, a very complex Python project, we, we, it turns out that we have to, like, parse and create lots of versions, like, as in 1.0.0.2, like, we just, like, version objects within the program. Like, we end up parsing and creating a lot of those. And it turns out that actually, like, allocating that memory was expensive, given, like, the scale, like, the number of times we were doing it. And he came up with a representation where we can represent like 90-something percent of versions with a single U-64 integer, so it's just like way more efficient. And the benchmarks around that and the implementation were very cool.

It's like one of the coolest PRs I've read, I think. In TY, which our type checker, there's a lot of like very interesting performance work that's happening, especially to make it incremental. So, like, TY is designed to be a type checker and a language server. And the whole system is, like, highly incremental. So the idea there is, like, if you're in a text editor and you open up, like, one file, you don't necessarily want to, like, have to type check your entire project, like all your dependencies, every file in the project, just to get analysis for that file.

Like, because you don't need to. So how do you make that work? That's like that's sort of like That would be like lazy You want to be lazy But the other piece to that is like If you have a file open And you edit it

Or you have like two files open You edit one of them You only want to recompute Like exactly what you need to re-compute Like you don't want to have to go And re-type check like the entire code base again Especially because maybe you're working In a big project like PyTorch

And it's like you have two files open You edit one of them You don't want it to like And then you say you don't want it to take like two seconds to like retype check the project and like give you a new analysis. So the whole system is built around queries, which is pretty interesting. This is more of like a macro design thing. But we built it on top of a framework called salsa, which is also what Rust Analyzer uses,

which is like the popular Rust language server. And now we've intentionally or inadvertently become like very large contributors to Salsa. But the whole the whole system is. built around that, which has been like very interesting architecturally. Interesting. So it's, it's lazy, so it doesn't type check the whole code base and it's incremental. Yeah, the incremental part is the thing that's hard because you kind of need a way to basically like it needs to be able to model kind of like a dependency graph of like everything that's happening in the code. And so then when you change something, we want to just like

flow the data back through all the different pieces, like only the pieces that into the run. Yeah. So that took a lot of work. But it has come to together and I've been doing a lot of optimization lately with codex because it tends to be very good at especially at like micro optimizations like if I'm like in TY in particular we also need to think a lot about memory not just speed because if you work on a very large project like you don't want it to take like many, many, many gigabytes of, you know, just to, like, run your language server. Like, ideally, you want it to be, like, relatively efficient. So, like, I spend a lot of time now kind of, like, continuously optimizing, like, memory usage and performance. And I can just set a

goal that's, like, try to reduce memory, like, salsa memory by, like, 1% on this project. And, like, you can't do, like, these things that you might, like, try to do. And it's very good at just, like, coming up with, like, very reasonable things. And so, I don't know, I find that very cool because it's kind of like you can almost have like continuously, I won't say self-optimizing. That's like a grandiose, but you can kind of be like continuously like just like optimizing your software. So I've been enjoying that a lot. But, but most of those are like, yeah, trying to find ways to like represent things that take a blessed memory or trying to come up with. like sometimes it's like trying to come with broader redesigns to like fix pathological performance.

That one optimization with the version numbering and seeing that you can limit it just to like a U-64, if you think back to some of these more creative optimizations that were done, that was in the human era. Do you think if you just, I don't know, ran codex and you're like, hey, just don't break things, but lower, do you have faith that it would come up with that? or is that kind of a step above? That's a very interesting question. If you just, at least in my experience,

like if you just ask these things to reduce memory or performance by some, you know, moderate percentage, it will typically come up with things around the edges as opposed to like larger redesigns or reconsiderations. But you can get to those larger redesigns if you prompt and collaborate with the agent. And so if you sort of ask like, well, like, should we be thinking a bit bigger about like why we have to represent the data this way?

Like you can you can get to like bigger ideas and so that might be an idea that you could have gotten to with prompting if you were like you know, okay let's start by like profiling and figure out where we're spending a lot of time and then maybe the you know would eventually come back to you and say like we're spending a lot of time in like version parsing and like version like version drop and version allocation and like blah blah and we'd be like okay well like how could we represent these like more compactly and we're probably sort of start by finding micro-optimizations in the representation of like, well, this field, like, you can find these two fields to, like, save a few bites, like, blah, blah, but I think if you kept pushing it, like, it's possible it would get there. But that's not the thing it's going to come up with by default. Mitchell Hashimoto, who was, like, one of the Hashikort founders, who works on Ghostie. He had a post that was insightful, I thought, last week or this weekend, about a renderer he wrote where it was like a really terrible renderer.

I'll probably butcher the tweet, but it was like, it was a really terrible renderer. And then he hadn't, like, intentionally. And then he had an LM like optimize it and it made it like 10 times faster. And he's like, great, right? Actually, no, like my handwritten version was like a hundred times faster. And it's like, you know, like you lose, if you're not like using your brain to like think about from first principles,

like how fast should it be and like how should the system work? Like then you just like ship all this. He's like accumulated like, I mean, I won't necessarily call it slop, but it's like, you just ship these, like, things and you're like, yeah, oh, my God, I made it 10 times faster, but really it should be like a hundred times faster. And so I think, I don't know, it shouldn't be controversial. There's still a lot of room for, like, using your brain. Right? I'm like, but I do think it's like, I struggle with this stuff a lot. I mean, like, I'm changing how I write software a lot. And, you know, I've had people on my team, like, because I'm using agents a lot. And, and also was, you know, to some degree trying to, like, push our team to like use agents more. I mean, I mean, some of that for me came from a place of like, we build tools for software engineers and a lot of our users are now using agents. And so if we like, if everything good that we do, that's an exaggeration, but if everything

good that we do comes from like understanding our users very well and like how they work, then like we should probably be like using agents that we understand like what it's like to build software with them so that we can build better tools for our users. That was part of my motivation. And part of it was just kind of seeing how it can change, like, how you work. And I don't know. I think I'm shipping a lot more. But it has been like, it has been like a difficult process.

Like I've had people on the team tell me, which I think is great that they tell me this. But they're like, oh, it used to be the case that like whenever you put up a PR, I could like review it pretty minimally because I had a lot of confidence in it and like your work. and now it's like when you put up a PR, I actually have to review it really closely because you're not like writing it anymore. It's like the agent. And I was like, wow, that's like very interesting. They're completely right, which is, and like,

and the same thing happens to me. It's like if I go to sleep and then wake up in the morning and look at one of the PRs I put up and I'm like, wait, this is terrible. You know what I mean? It's like you can, it's just, it is easy to trick yourself into like basically believing work that,

isn't at the same standard as what you would do before. And I don't think, I think we have, we don't really know what to do with that. Um, and I'm kind of learning and getting better. And like, I mean, this was, I think I'm doing a lot better job now than I was in like, probably, you know, like February or something where I was like, I was like, like, you know, fully agent. And I'm like, now I'm like a little bit more like, um, but so my point is like, that was like a pair of powerful kind of like moment for me when someone's on the team said that. And I was like, wow, like you're right. And I, and I, and I see that. And other people on the teams work too.

Like it's not just limited to me, but it's like, you know, it really does throw a lot of things on their head. If you generate pure slop, that's easy. But I think there's this gray area where you generate partially AI slop or it's, you know, it's acceptable, but it's not at the bar that you used to have. Do you, what are the tactics that you've used on the team that have worked for combating this kind of gray area AI slop? I'd like to get to a world. We're not here, and I don't know if we'll ever get there. I'd like to get to a world where if you put up a PR and it's all green, then the odds of it getting merged are like extremely high, right?

Because that would mean that like you have automated verification for like most of what matters. And we have a lot of that in our projects and we've tried to add more over time. And I think it's helpful. Like we have like in TY especially we have T.Y. Especially we have tons of like benchmarks like that run under Valgrind like through Codspeed like on every PR.

So we get like and that includes memory. So we benchmark like memory usage and simulation time and wall time like on every PR. And then we also have a really big suite of ecosystem tests. So basically every time you put up a PR, we run before and after on like a bunch of projects in the ecosystem and then we create this report of the diff of all the diagnostics,

like the errors that got removed and added and everything. So we have like over time, we've tried to do like more and more. These are important, honestly, even before we had agents. Like these were like we basically couldn't build without these things. But the point is like, I want to have like more automated verification and try to get better at that. And that includes things too. Like we basically assume now. that anyone on the team that puts up a PR has already run that through Codex review like probably several times.

And that's basically an assumption. I mean, we could automate that process. Codex review is just an agent reviewing the code and double checking? Yeah, it's just running codex and then just doing slash review. I see. That's it. Yeah, it's not that fancy. I mean, it's not, sorry, it's not that sophisticated, but it's just like, because now it's like if a contributor puts up a PR,

that's the first thing that we do. Right. Because it tends to find good things. You know, I think the things that I've, so like basically I think one bucket is like how do you create more like automated systems that just help get things, make sure things are right. And that also includes things like trying to improve your like agents.md file over time. Like if there are things, if there's feedback you're giving in a review that the agent's not respecting, try to find a way to help the agent learn that even learn.

skills, like we have some shared skills on the team, stuff like that. None of this stuff is very sophisticated, by the way. It's like pretty simple. The other piece is like how do I make sure that I put in the work to ensure that I'm creating a good PR? And so for me, that's like I really should understand. Again, it sounds like a really not, it really sounds like a low bar, but I should understand like each line in the PR. I know, it's crazy. But also, I do try to review each PR myself in the GitHub UI.

This is something I've always found really helpful. Like, if you actually just, like, open up your PR and click files and read through it as if you were a reviewer, you tend to find things that you would miss if you were just looking at your local diff. I find that very useful. And then the other is trying to, like, encode. skill, I guess this is a little bit more in the first category, but trying to encode skills, or trying to encode in skills, things I can continue consistently getting wrong, that the agent is getting wrong. Like I had, like a recent example would be, I found that I was often getting

feedback on PRs that was of the form what, you know, this condition here, there's like if statement, what cases is this intended to catch? Because if I commented out, all the test pass. And so I was like, okay, I should probably have a pass before I put up any PR where I have the agent like go through and check like are these conditions still relevant or are they left over from a priority factor or something else. So I don't know. I'm not, I'm still learning, but those are some of the things I've been doing. Yeah, it's again, I think it's like a, it's a pretty hard time to be like building software. But I felt for a long time or I had a fear that AI was going to make us more productive,

but that programming would be like a lot less fun. Because I just like love, I just like love programming. And I was like, oh, now I'm going to have to spend all my time, like, reviewing code and like prompting this like idiot agent to like, that's like keeps getting things wrong and like, but ultimately like is probably more productive. I actually feel way better about that right now. than I did like a few months ago. And I don't, I don't exactly know why.

Like, I think, I think it's because, well, I think the agents getting better and the tooling getting better and me getting more comfortable with it is one factor. I think the other is, um, I've grown to appreciate more of the, the kinds of things that like working with agents has unlocked. Like the cost of running an experiment is incredibly low. There's so many things I've wanted to try. or like questions I've wanted to answer that I can now answer like almost instantly.

Like I like a sort of a dumb example. We UV and UV everything is snapshot tested. So like basically all of our testing is effectively running UV and verifying the output. That's how we test like basically the entire program. And so that means we have a lot of tests. That means we have a lot of test output. and the test output is it actually ends up in the test files. So we have Rust files, like we have a file called like lock.RS that tests all our UV lock.

It's all our UV lock tests. And it's very, very long, in part because it has all the lock output snapshoted in the test. And I was like, hmm, like, what if we stored the snapshots in separate files? Like, would that somehow make our like compiles faster? because then you don't have, technically that's like rust code. And so it's like, would that all disappear and like would that make like our builds faster

or blah, blah, blah. And I'd always want to do that, but it's kind of like, to do that experiment as a human would be like extremely painful because you have to convert all of this test. And I just had an agent to do it in the background while I did a bunch of other things.

I got a bunch of data on it. And the answer is no. But it's like, you know what I mean? Like I mean, sorry. The answer is a little bit more nuanced. It actually does have a good impact if, if you're just iterating on the snapshot outputs,

you no longer have to recompel your program at all because the outputs are stored somewhere else. Anyway, that's the thing that makes a difference on. But my point is I'm just like running experience like that all day, like trying things that were like used to be hard, like used to cost a lot to answer. The work of then going from that to like production, there's still like real work there.

But so, you know, I think one piece is the tools and the agent is getting better. The other is things that I just wouldn't have been able to do before that I can now do like incredibly easily. And then and the third is I think I'm more and more realizing that like a lot of the value I get from building software is not, is retained. Because some of it is like thinking hard about like the not, it doesn't have to be typing out the code, but it's like thinking hard about like the layout of a data structure. A lot of it is merging a PR that closes a user issue. I get a lot of satisfaction from actually like fixing and improving something. It's not necessarily just from typing out the code. So I do feel for people a lot who feel like they're losing something by like working with agents

because I do feel that myself. But I feel better now than I did a few months ago about my, like what it's like to work as a software engineer with agents. You mentioned in the like one of the performance optimization example. You said, if you just unleash codex, it kind of does this local optimizations, and it's very good at that. But it's not great at kind of like some of the, I mean, today it's more human ingenuity of like system level optimizations. And it kind of reminded me of this tweet that you had. You said, it says, I'm slightly concerned by how much garbage I would be churning out if I was trying to use these tools without significant software engineering experience. Yeah.

I remain concerned about that. Yeah. It reminds me, and similar to what the Mitchell Hashimoto tweet that you said, it was like there's a very big difference between Codex go and do this versus, you know, you are like wielding it like this tool and you're kind of like prodding in the right direction. Yeah. Yeah, I was curious to your thoughts on that because it seemed like it went pretty viral and I think a lot of people are thinking about that. Like being a great software engineer,

is like, like, more, like, useful than ever. Like, I don't, like, it's, you know, it's still the case that I think that the people on our team who are, like, the strongest, like, software, have the strongest engineering skills are, like, the most effective, like, even at using agents. And, you know, it's funny because there's a lot of talk about, like, token maxing. I don't know if you're familiar with this, right? Yeah. the idea of like should you have a leaderboard for example this is getting tweeted about a lot

companies that have token leaderboards and it's like how do you like creates a terrible incentives to just like use as much tokens as possible and it's funny because we do uh that does get tracked or sorry there's not a leaderboard but like token usage is something you can like look up for example you know internally I mean and um it's interesting to look at because I don't care like who on the team is using the most tokens like and there are people on the team who are like I'm like actively trying not to care about that, like being where I am on the token leaderboard, which I think is like great. Like I don't care.

Like they don't have like, they should just do like do a great job. And like that's fine. I don't care if they use a lot of tokens or not. But it is interesting to look at the token leaderboard because some of the people in the team who are most productive are like using like a lot of tokens. Right. It's like like there is like a correlation. I'm not saying it's causal, but I'm saying like I do think that a lot of great engineers like are able to like use agents for effectively and like to hopefully to like multiply their skills. So I I do think it would be like

really hard to be an early career software engineer right now and I'm not spending that much time with early career engineers right now just based on like at Astral we're just a very small team and we tended to hire very senior but it's it is sort of hard for me to think about like what what would we like how would I learn basically like what would the iteration loop be um I would be like learning from codex I guess um as opposed to uh like um the other way around basically I mean like like a lot of the times I'm actually like instructing codex right and like trying to correct it and priding a safeguard on it or opus or whatever you're using. And so, yeah, I think I just don't know, like, where you would get,

it would just be way too easy to fall prey to, like, a lot of the bad things that happen when you use agents. You built this proof of concept in Rust, and it was really well received, but why did you start a company around it and how did the, like, the raising go and all that? What was the motivation there? Yeah, yeah. So I left Spring. I was actually convinced to leave by a friend who, a very close friend who left META around the same time. And he was like, we should start a company together. And I was like, okay, fine.

I mean, it wasn't quite, you know, that simple. But I did, you know, I left. And then we kind of went into the, you know, the quote unquote idea maze of like, what do we want to build? Like, we went into it not knowing what we wanted to build. And we spent a bunch of time exploring the Venn diagram of ideas. ideas of like there were things he was interested in that I thought was were not interesting and vice versa. And there was some stuff in the middle. And we spent time exploring the stuff in the

middle. But then in all my spare time, I was working on like developer tools. And because that's what I thought was really interesting. And he, it wasn't quite like a fit for him, basically. But around then I was working on rough. I was working on a couple other projects that you can see in my GitHub that are like, I don't know, probably not as interesting. But they were like, I was like, experimenting with like lots of different things at the time. I was pretty interested in WebAssembly. I wrote a sort of like a CICD toolkit in TypeScript. It's sort of like you wrote pipelines in TypeScript and it transpiled them to Docker and I was like, oh, this could be cool. I don't know. I was like building a lot of stuff. And at that point in time, I decided I wanted to start developing

relationships with investors, but that I wasn't ready to raise money because I didn't know what I was actually going to build. And so my thinking was, I'm going to try to get connected to some people who like to invest in this kind of stuff with an eye towards reaching back out to them in like three to six months and being like, hey, we had a great conversation. Now I'm working on X. So that was my thinking. So I got connected to a couple investors who invest in like software infrastructure and developer tools. And I had some good conversations. And then like the problem is things just can move really quickly. And so I didn't actually expect to like start raising so soon. But I effectively got convinced and at the same time, Ruff was growing a lot. And so I effectively

got convinced that there was enough there to start a company, which is a very interesting process. I was like, I don't quite know how this becomes a company, but I was effectively convinced that there was enough there to build a company, which is interesting. By the investors? Yeah. Yeah. Yeah. Which I'm grateful for. The other thing I was convinced of was, which is funny, is if I hated it, I could stop in like six months. It's like, if you decide it's not for you, you could like give the money back. The investor said that. Yes, which I actually think was brilliant because like I was probably never going to do that.

But it did make me feel like there was less pressure. So, sorry, very weird round about details. but basically, like, I was, like, working on rough more, like, full-time eventually. And then it was kind of like, I would say, collaborative with, like, the potential early investors where it was like, we would just have, like, long conversations about, like, my ideas. And then it basically become clear that it was like, there's enough here. Like you and I, like, wrote out kind of like a product roadmap, which honestly, like, a lot of it stayed true to, like, what we ended up building, what we've ended up building so far at least.

And from there, basically became like, yeah, we want to fund you, like, here are the terms that we would do. And I was like, oh, wow, okay. So I guess this is happening. So it was just interesting, and I had never done anything like this before. I mean, I was just, you know, an IC software engineer my whole career. And then I suddenly I was like starting a company. And it's funny because I actually think.

like the decision to like go all in and like start the company wasn't that stressful. I actually think a lot of the stress came later as the company started to succeed because at the beginning I had I kind of had nothing to lose. But then as the company started to succeed, you know, I was like, oh wow, like the company's kind of working. Like what's going to happen from here? And I had a team of 20 people who were depending on me. And so, I don't know, just for me as a founder, it was like, I'm pretty like risk averse, but I actually found that starting the company was an easier, it was, it was an easier decision than maybe some of the stressful things that came later to navigate. But it happened very quickly and sort of unintentionally and in a symbiotic way

with investors, which was, which I hadn't really anticipated. I didn't expect it. I didn't expect the investors I mean because I thought the founders hungry for the fundraising and go please fund me but the investors were like please do this I think it can happen a million different ways yeah and like

actually I mean we did three fundraises we did a series A and a series B we actually never even announced the series A or the series B they were I mean they were announced in the acquisition blog post but we sort of complicated it's like we

we basically just never got around to it. Why don't you guys publish it? Because isn't that good marketing for talent? It's good marketing, but basically, like, there kept being, like,

reasons that we, like, wanted to wait a little bit. And it's also, like, to me, it always felt like a lot of work. And then I was like,

it just never, honestly just never felt like the most important thing because we were, like, building a lot of stuff. And, like,

the company was going well. And I was like, I don't, we don't need the marketing. We did finally, planned to announce it, but then we got bought, so it didn't happen. But, but each of those, each of those fundraisers was, um, uh, was like preemptive, basically, like, like initiated by investors, um, which was, uh, which is like, uh, I mean, it's like fortunate because like the company

was like going well and people wanted to invest. Um, but it was also just like a funny position to for me to be in, I guess. Um, uh, I think I, uh, I think I, uh, I think I was just always a little bit conservative, and I wasn't super aggressive about trying to go out and raise money. But we were lucky enough to be building things that people really had a lot of confidence in, or had a lot of belief in. That probably gave you a lot of negotiating leverage, because one of the best position you'd be in is that you're willing to walk away. You don't need it. And by definition, you didn't even come there to begin with. They came to you and please take the money.

That's true. Yeah, yeah. I wouldn't say I'm a great negotiator, but yeah, I guess at least I had a strong hand. But we were very lucky with investors. We had amazing investors, like super supportive and really like aligned with how I wanted to build the company. Like never any conflict, never any like pressure to do anything specific. Like just support. And maybe the only thing, maybe the only piece of consistent. feedback is that I could have been more aggressive. But I don't know. Just in terms of like scaling, growing and doing more. But I liked the way that we operated. And yeah, we just had such good, we had such good experiences with our investors too. So I felt lucky about that because it can easily go the other way.

I imagine if someone invests there's a promise of future revenue. But how does this company make money? Because you guys give away your software for free, right? Yeah. We launched a commercial product in. like August of last year. And it was sort of, it was called PYX. It was kind of like a hosted counterpart to UV. So like a lot of our, a lot of UV users will purchase like a private registry software instead of using the public registries either for like security or maybe they need to

publish their own private artifacts, things like that. And we basically built our own private registry that had some first class support for UV. And, It let us solve a bunch of problems that we saw, you know, in our issue tracker around users using other solutions. Also, it let us build something really fast because we, like, vertically integrated the client and the server. There were, like, special things they could do to be, like, really fast and really easy to use and all that. And we spent a while selling that. And our revenue actually grew, like, pretty well. I mean, it wasn't like, I think in this era of AI, you're constantly hearing about fastest company to go to,

hundred million in revenue and things like that. It wasn't, it didn't look like that. But we were definitely able to sell this to like some big enterprises. And I mean, the cool thing was we had very good, because we built the open source and everyone was using our open source, we had a really good funnel. Like, like we had a small number of extremely high quality customers, is the way I would put it. So the general idea for like how we wanted to make money was keep, like build open source and like the tooling. The tooling remains like free open source, like entirely non-commercial.

And then we build software that's kind of like the natural next thing you need when you're using our tooling. So if you're using UV, there are probably solved problem, there are likely problems we can solve for you with like a private registry. And then the funnel is like people using UV,

they have these problems and then we sell them the registry. And the registry was meant to be like one piece of a platform of like a bunch of different things we sell like a Python cloud. So that's what we were like building towards. I mean, part of the cool thing about the acquisition is we'll be able to take parts of that

platform and make it basically freely available. Like we did, just as an example, a big part of that was we did a lot of, like in Python, you know, there's a big part of the community that uses Python with GPUs, like Pi Torch and then there's like a whole ecosystem around Pi Torch of like software that kind of like builds against Pi Torch. And we that's for a variety of reasons, the ergonomics around that are not great. Like it can be kind of hard to work with, hard to install, hard to get hard to install the right version.

Depends on the GPU that you have and like what version of Kuta you have installed and like all this stuff. And so we kind of tried to solve that in a certain way where we built. our own distribution, you could think of it, kind of like a Linux distribution. Like we pre-built a lot of things like that that all worked together and made that available to customers. And so now we can actually take that and just make that like freely available to everyone because we're no longer, we no longer are trying to build like an independent business.

We're just trying to build great tools that like grow a broader ecosystem. So I mean, more to come on that. But that's been kind of like one cool thing that I'm excited about. As a first time founder, especially with the engineering background, Was there anything that kind of like a surprising learning or something where you would share that with someone if they were an engineer and they were going down that founder path? There are so many different ways to do it. Like I'm actually like not a huge fan of people giving startup advice in general because so much of this industry is like survivorship bias of like you could give the exact same advice to like, you know, like basically you can go to like two talks and people give you like two. like incredibly successful founders give you like completely contradictory advice and you're like I don't

really know what to do. And I tend to view that as like you've got to figure out what's true to you. And so, you know, like there's all these decisions you have to make like in person versus remote, right? Like have a principle and like stick to it. Like either one can be great. Like we built the whole company remotely. It went super well. Like it was great. Do I think there are benefits to being a person? Of course. Would I have been able to hire the team that we put together if we were in person? Absolutely not. And so, like, you know, there are tradeoffs to all these things. You just have to like be principled and figure out, like, what's, what resonates with you. Um, you know, like, uh, and there's, there's like a million of those decisions that you have to think through.

I feel fortunate in a lot of the ways I got to run the company. Like I, I tried to spend, like, very minimal time fundraising and with investors. And I tried to optimize for investors I really trusted as opposed to trying to talk to a billion different investors and like pit them all against each other to get the best terms. Like my my goal was always like find a partner that I really trust and get good terms and then move quickly to spend as little time on fundraising as possible. And so, you know, think about, think about what you care about and focus on that. There's no right answer to a lot of this stuff. I got a lot of advice to get a co-founder when I first started the company. And I basically ignored that. I mean, I like, well, sorry, I did ignore it because I didn't

get a co-founder, I guess. But like I, for me, it was kind of like, um, uh, I kind of knew they were right, probably, but I didn't really have someone in mind. I didn't want to force it. And so I just didn't. And, um, you know, over time, I felt like it would have been helpful to have someone to, uh, that's kind of like in, like in the trenches with you in the same way. Um, but, you know, you find other ways to, um, to compensate for it. Like, um, um, um, to compensate for it. Like, um, um, um, um, I don't know. I lean on my wife a lot, probably more than I, you know, more than I should. Probably more open with my employees than I otherwise would be, which is, I think,

which can be good or bad, but it's like I share a lot with, you know, with the early team, like, especially when you advice on things. Try to build a network of, like, other founders, especially here in New York. I have, like, a pretty good group of, there's like six or seven of us. We try to get dinner twice a year. It doesn't sound like a lot, but everyone's busy. Yeah, yeah, yeah. And that's been like a really, yeah, that's been like a really helpful like support system.

So you just find other ways to compensate. But yeah, it's, I don't know. There's no, I really don't, I really think there's not one right way to do it. Yeah. And it extends everywhere. I mean, like also, I don't know, everyone on X is talking about like, you know, like, should everyone in your company be working seven days a week, this kind of thing. and it's like, I don't know.

Like, we just built a very different company and we were able to do it. Like, that was not, I mean, I work basically all the time. And that's a choice I made. And that I'm, like, very happy with. But I don't expect people on the team to work all the time. And I want it to be a company where, you know, you can be highly, highly successful working normal hours,

but also where you're rewarded for, you know, your output and your performance. And I try to keep all those things in sync. But, like, again, there's no one right way to do it. There's no one right way to do it. Like other companies, that is their culture and that's what they want to do. And like, sure, whatever. Like, if that's what you sign out for, like, just make sure that you're honest about, like, what you're doing.

So I don't know. I just think figure out what you care about. And in my opinion, don't focus too much on how you think you should be doing things. Think about how you want to be doing things and what actually fits with how you want to work. What's your top book recommendation, whether technical, or maybe something that helped you as a founder. I don't read a lot of, like, technical material. I have definitely watched a few talks

that were very influential to me, which is a little bit different. What are those talks? The Zig creator, Andrew Kelly, had a really good talk about, like, data-oriented design that, like, I learned a lot from. I mean, even apart from learning things, it sort of inspired me to, like,

look at software quite differently. And so I think about that talk a lot. Interesting. Yeah. things like that. It's really good. Yeah, it's about, well, I haven't watched it in a while, so I'm probably mess it up, but it's like a lot of it's about basically design decisions they made in like the Zig compiler and just like thinking about like memory and allocation and all this stuff. And I was like, I watched that when I was pretty early in my career of like systems programming.

And I was like, wow, like these people really care about what they're doing. And I was like, that's cool. Yeah. Yeah. And the last question is, If you could go back to the beginning of your career, like right when you graduated college, what advice would you give yourself knowing what you know now? I don't know. It's so hard to give myself advice without feeling like I have all this hindsight bias, you know?

I mean, I think, I guess there are some things where I'd basically like tell myself that it is the right decision and I shouldn't worry so much, but it's hard to know how that would have played out, you know, if I did it a thousand times over. But for example, like I think when I left school and I went to work at Khan Academy.

Part of me was definitely like, wow, should I be taking more of like a big tech job? And am I going to really regret not having that experience or like, or like, I mean, the like, the Khan Academy like pay was good, but it was like the big tech pay was certainly like better. And I was seeing my friends get like huge bonuses and like all this stuff. And I was like, I felt sort of insecure about should I be doing that. And I think it actually, you know, in the long term,

really paid off. Like I think, I mean, maybe it would have been great, but like the experience I had was really what I wanted and I thought I made that decision for the right reason. So I think some of these things are like, I don't know. Everything happens for a reason, you know? And it's like, have some faith in like what you're doing for the right, you know, for the, if you're making decisions based on principles,

like I think it can work out. When we started this conversation, you said, you know, the reason you got into what you, got into is because you tried all these different ecosystems and you had a a broader perspective. I imagine if you went to Google and you just kind of, I don't know, use Google's closed thing and then you might not have had the same insight. Yeah. And, you know, I think about this with Spring too, because Spring, like I was there for four and a half years and then I left right as they decided to do like, you know, like a pivot and then they ended up like joining Genentec.

but we had set out to build like this kind of crazy drug discovery company. We were focused on aging and it was all with like computer vision. It was like very, very ambitious what we were trying to do. Yeah, yeah. And then afterwards I was like, oh, like the company didn't like it didn't have like the huge exit or like the huge. You know, we didn't achieve like all of our dreams. Like did I waste all my time? And ultimately I was like, no because I learned by being an early employee even and like seeing all these stages.

I learned so much about around my own company and also all the technical learnings that I rolled into my own company. So again, I feel weird giving this advice because it's like everything has worked out really well. But I feel like there are moments in time where I kind of doubted some of my career decisions and then in hindsight,

like you can only connect the dots looking backwards. Like everything kind of added up to finding the thing I really love, which is like building tools and feeding into that. Awesome. Well, thank you so much for your time. Charlie. I really appreciate it. Yeah, thank you. No, it's super fun. Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment.

Guests like Barbara Liskov, Mike Stonebreaker, Mark Brooker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype it's a split keyboard so there's two sides this is in the case but yeah we launched on kickstarter and we hit our goal within eight hours of launching i really appreciate it if you were one of the people who grabbed one of the early units we're now working on the long journey of building the tooling now and so if you still want to pick one up i've left the late pledges open on kick starter so you can grab one there i'll put a link in the description thank you again for

watching the podcast and i'll see you in the next episode