"AI optimization is 10 times faster, but handwriting can actually be 100 times faster!" Author of the top Python tool: AI spam PR is destroying the open source community

He rewrote half of Python with Rust, but now he feels suffocated in the age of AI agents.

Charlie Marsh, whose company was recently acquired by OpenAI for hundreds of millions of dollars, recently opened up about his coding anxiety on a tech podcast.

Charlie is the founder of Astral, the high-speed Python toolchain behind Ruff and uv, and has since joined OpenAI's Codex agent team. As a top engineer who built one of the most hardcore open source tools in the ecosystem, he admits he hasn't written code by hand in an editor for a long time now, and relies entirely on prompts to let AI do the work for him.

But this came with an awkward tradeoff — a member of his team told him directly: Charlie, when you submitted PRs before, we could approve them after a quick glance; now we have to be 100% focused when reviewing, because this code was auto-generated by you with AI.

This obsession with efficiency and better tools has run through Charlie's entire entrepreneurial journey. Before founding Astral, he was just an ordinary engineer at a biotech company. Fed up with the slowness of vanilla Python tooling, he decided to teach himself systems programming. He admits he chose Rust almost entirely because of the hype back then; he didn't even understand what memory safety was. But relying on minimalist logic and an obsession for extreme speed, his high-speed analysis tool went viral on Hacker News overnight.

His acquisition by OpenAI this year actually came about because large models are increasingly moving into physical engineering and agent development, and OpenAI desperately needs his team's deep expertise in compilers and high-speed toolchains to underpin the core logic of large model code generation.

In this conversation with Ryan Peterman, host of The Peterman Pod, Charlie discussed the real dilemmas engineers face in the age of AI agents: for example, the hidden unknown crash risk behind automated codebase rewrites, and how marketing capability determines whether an open source project lives or dies. In his view, when AI generates code at scale, the core focus of programmers' work must fundamentally shift. Below are extremely authentic industry insights Charlie shared based on his first-hand development experience:

AI has brought the barrier to submitting a PR down to zero, but the cost of human review hasn't decreased at all. In the past, when new contributors submitted code to open source projects, it was a personal growth process of "receiving feedback, fixing errors, and writing better code next time". But now, anyone can use AI to generate a seemingly working pull request in just two seconds. Maintainers have to spend an hour manually debugging, while the submitter learns nothing from the process. This is breaking the healthy growth contract that open source communities were built on.

Automatically refactoring an entire codebase with AI is gambling with unknown crashes by trading known bugs for them. Although large models can automatically rewrite an entire large codebase into another language (such as Bun switching from Zig to Rust) and even pass all tests, test suites can only ever prove correctness under specific scenarios. Automatic rewrites easily change "implicit code behaviors" that are not covered by tests (per Hyrum's Law), and ultimately leave unknown bugs for real end users to encounter.

Thousands of amazing open source projects are rotting in the corners of GitHub just because their creators don't know how to market them. Many programmers arrogantly believe "if the code is good, people will use it naturally". But the reality is, this is an era of extreme attention scarcity. You only have 10 seconds to grab a reader's attention on your README page. Excellent tools that don't understand developer marketing are destined to never be discovered by the world.

Why Can't Python Toolchains Be As Fast As JavaScript's?

Host: When you first started working on these developer tools, what was the state of the field? Why did you feel it could be done better?

Charlie Marsh: Before founding Astral, I worked at a computational biology company, and I was the second engineer there. I don't have a background in biology or machine learning, so I was responsible for building all the software systems needed for our machine learning work. Back then almost everything we did was Python, so that's how I learned Python along the way.

Later we also used Go and Rust. So I actually got to experience many different ecosystems first-hand. I felt that back then, as a small Python team, we wanted to build so many things. Our codebase — of course it can't compare to massive enterprise codebases — but it was already pretty large for us, and there were only a few engineers actually writing software and supporting the whole team. The rest of the team were mostly machine learning researchers or scientists.

So I got to experience many different ecosystems and tried many different tools, and I was working with Python at that time. We were always trying to squeeze as much leverage as possible out of our tools, whether it was type checkers, linters, or package managers. As the project grew and our team was small, we really wanted great static analysis and a great toolchain, but we kept hitting all kinds of limitations over and over again.

I think, to some extent, when I looked at the Python ecosystem back then, I felt it didn't have nearly as much experimentation as other ecosystems, especially the web ecosystem. A lot of pretty crazy innovative things were happening over there, and people cared a lot more about performance. First there was ESBuild, written in Go; then SWC in Rust, then Bun, Deno, and a whole slew of other tools that followed. So the idea that "JavaScript can have a native toolchain" became more and more widely accepted, especially as applications grew larger and developers were doing more and more work on their local machines.

But that shift never really happened in the Python world. So for me, the core question was: why can't Python do this? Because I had seen what happened in the web world, I had written Rust and Go, I understood how these toolchains worked, and I knew what the user experience generally looked like.

Then when I looked back at Python, I saw there were far fewer tools, many interesting ideas from other ecosystems just weren't implemented here. And almost all existing tools were written in Python itself. So to me, that was a really interesting question to explore.

That was almost the first question I asked myself when I started this project. When Ruff first launched, my blog post was titled something like "Python tooling can be much, much faster". To me, it was really just a hypothesis: can Python tooling be a lot faster? Then I built a prototype, and the prototype answered: yes, I think it absolutely can.

Host: You wrote an article back then about researching MyPy, publishing your results based on work on MyPy. And only about nine days after that article came out, you published the article you just mentioned saying Python tools can be much faster.

Charlie Marsh: That's pretty funny, I didn't even realize those two events were that close together.

Host: Was the proof of concept built entirely in those nine days?

Charlie Marsh: Yeah. That first blog post I wrote was mostly about large-scale type checking, because I was thinking: what things did I learn that other people rarely write about? Then I decided to build a linter first, because I thought that would be much easier. I still think that today: it really is a lot easier than building a type checker. We're working on a type checker now, and we already have one, so I can say this for sure: building a type checker is much harder.

But I built a linter first because it let me validate a lot of the same core ideas in a much smaller package. Whether you're building a startup or a tool, you want to get something that people can actually use and that proves its value into users' hands as quickly as possible; and you also want it to enable fast iteration.

Strangely enough, the linter ended up being almost a perfect product shape. The core is simple, but you can add so, so many rules, right? So it's scalable across so many dimensions, and users can get value quickly with a small core plus rules. That's really all you need.

So we got it out really quickly, kept iterating, adding more rules and more features. Users can also use it alongside their existing tools. It was immediately useful, which I think is really important. By contrast, a type checker is a perfect counterexample: A type checker that's only 75% complete isn't really that useful at all. The same goes for package managers.

These kinds of products often have to be — well, I don't want to say this too absolutely, there are many cases that challenge this take — but the point is, products like this are much harder to ship incrementally while remaining usable. And I believe that ability to ship incrementally is one of the key properties to actually build momentum, whether you're building a tool or anything else.

Host: After you published that article, how was the response?

Charlie Marsh: The blog post itself hit the front page of Hacker News after I posted it, got shared widely on Twitter, and overall it generated a lot of excitement and interest.

I have a lot of thoughts about this kind of outcome, especially getting on the Hacker News front page. It's part luck, part skill, of course. It definitely helps, but it's by no means a requirement for success. Conversely, getting on the front page doesn't guarantee you success. It's great if you get it, but there's so much randomness in it.

But I do think a few things are really important. First, after this happened, people actually started noticing the project. So I worked really hard to catch that wave of attention, stayed as engaged as possible. For example, if someone opened an issue, I would really actively triage the problem, fix it, and ship a release as fast as I could. If you can close that loop in one day, it creates a really, really strong feedback loop. Other people will become your supporters and bring more momentum to the project.

Also, some influential people in the ecosystem started noticing the project, like Sebastian Ramirez — creator of FastAPI and many other great tools. He's been a really great supporter of our project from the very early days. Early on he said "oh this is interesting, I want to try it". And I basically asked myself: what do we need to get done to make him actually use it? Then I worked hard to deliver on those things. So we really did try to maximize that momentum.

But another thing I think about a lot is that I actually think about "developer marketing" all the time. The term is kind of a dirty word, or sounds unseemly. I think a lot of engineers want to believe that technical products and tools win purely on their own merits. It's like the best technical solution should naturally win and grow organically.

But I actually have this kind of simple hypothesis: there are probably thousands of amazing projects on GitHub that just never learned how to market themselves, so they were never discovered, never got out into the world. I don't know if that's 100% true, but that's how I feel about a lot of technical work.

So when I think about what to write in a blog post or what to put in a README, I don't think it's about stuffing a million emojis or a million screenshots. What really matters is: Okay, someone just landed on this page, and I only have about 10 seconds to get them interested in what I'm building, and help them understand why this matters to them and why it's useful. So that's almost the core idea I bring to everything I do now.

Of course, that's kind of depressing, because it means I only have 10 seconds — but that's just the truth, people really don't have that much attention to give. It's the attention economy, right? It's the same for blog posts. Coincidentally, back when I was doing computational biology at Spring, we also wanted to publish content to explain what we were doing. We had a lot of really interesting insights, so we looked at OpenAI's blog posts, especially the early ones for DALL·E. We thought: wow, this is such incredible blog writing, because even if you don't read a single line of the body text, you still understand what they built, and you still come away impressed. Even someone who just clicks onto the page by accident leaves with an impression and some understanding. I thought back then: wow, that's really amazing.

So now when I write a blog post, I think: if someone just lands on the page, I have to be ready, because most people will only read the TL;DR, or look at the first image, or just read the title. Of course, some people will read the whole thing, so I should polish every word and every sentence carefully, but most people will barely read anything.

So, sorry again, this sounds kind of depressing. But I really do think it's worth it to carefully think about your audience, and think about how you can sincerely and honestly tell them why they should care about what you're building. It's not misleading, it's not a trick, but you really do have to think hard about how to communicate why this matters to other people in a very short amount of time.

Host: Can you give an example from your own work?

Charlie Marsh: For Ruff, I think we put a really great benchmark graph in the blog post, and that graph ended up going viral on Twitter. Basically, that graph was invaluable — sorry, not invaluable in the monetary sense, I mean it's almost irreplaceable when it comes to grabbing attention. Because people can immediately see what's going on, it's crystal clear.

I think benchmark graphs are really powerful. Of course, all benchmarks are imperfect in some way, they all have some error, so there's a lot more to say about that. But I really do think if you can have a visual hook that lets people quickly understand why they should care and what this is, plus a really powerful tagline — our core message back then was just that we're compatible with your existing setup and way faster, that's almost all we needed.

Then you can drill down: okay, if it's compatible and way faster, why should you care? Because it can be orders of magnitude faster, and still give you the exact same experience. You need to communicate that as quickly as possible, right?

Host: Even the title of that blog post, "Python tooling could be much faster", is pretty provocative in itself.

Charlie Marsh: Yeah. But I've actually always been against clickbait, or any kind of misleading expression. What you really want to do is communicate the most interesting part to other people as effectively as possible, on the premise that what you're saying is something you believe, it's true and sincere.

You can of course hype it up, post really eye-catching, inflammatory stuff, but I don't know. For me, that's just a losing battle. I don't even understand why I would do that.

Host: What do you think about the other common issue — like you have that graph, but I often see charts where the axes don't start at zero.

Charlie Marsh: Oh right.

Host: So the whole range is just from 50 to —

Charlie Marsh: Chart crime. Yeah, chart crime. I don't do that.

But I do think benchmarks themselves are a really complex and often controversial topic. Most people don't really feel that controversy, but I do, because performance is really nuanced. You have to consider so many things: cached vs uncached runs, those two cases are completely different. Or which project you run it on, the performance characteristics are totally different.

We've experienced that a lot with