I just got back from PyCon US. It was delightful; I saw old friends, met new ones, gave a tutorial on decorators, and spoke at the education summit. I’m a PyCon US sponsor, which means that I also had a booth, giving out T-shirts, books, stickers, and flyers about the LernerPython platform.
Of course, the topic on everyone’s mind was AI. From the education summit (where my talk was about “vibe teaching”) to the new AI track to hallway conversations, I don’t think that 10 minutes passed without someone raising the topic. Everyone is simultaneously excited, confused, and worried.
As I’ve written elsewhere, I believe that agentic coding (aka AI coding, aka “vibe coding”) isn’t the future. It’s the present. This raises lots of legitimate questions, from where agentic coding is (and isn’t) appropriate, how best to configure it to ensure it produces quality software, the increasingly large budgets that AI tokens are demanding, the privacy and security of data sent to commercial LLMs, and how we’ll train the next generation of software developers.
These are all legitimate and important questions. But I’ve been thinking about another question: How relevant is Python to the future of agentic coding?
It might seem absurd to worry about the future of Python. After all, Python is enormously popular and important among everyone working with data. Data analysis, data engineering, and machine learning are all largely implemented using Python. Between the standard library and PyPI, Python offers an almost embarrassingly large treasure trove of packages that handle everything from data to calendars to package delivery. The community of Python coders, including contributors to the language and third-party packages, is huge, and continues to grow. And because Python has been around so long, there is a great deal of online Python code that LLMs can use in their training.
In other words: AI is implemented using Python. Lots of people are using Python. It’s easy for LLMs to produce Python. Which is good, both for AI (which has more experience/training to draw on) and good for the people reading and examining the code.
But over the last few weeks, I’ve started to wonder about several things.
- Why ask AI to write its output in a dynamic language with relatively slow execution (i.e., Python)?
- In order for AI to write in Python, someone needs to be maintaining the language, standard library, and popular packages on PyPI. Who will do that, when the “customer” will be AI?
- Who will learn Python, if coding will go through AI?
I want to go through each of these, describing where things currently stand and where they might go.
Why output Python?
Back when I was in college, it was already common to write code in a compiled language. But there were still smart, experienced engineers whose assembly language skills were better than what any compiler could output. So sure, you would use a compiler for day-to-day tasks. But if you really needed tight, elegant code, you handed it to one of those super-amazing engineers.
By the time I graduated, compilers had improved significantly, and were able to write code better than any human. Knowing this, chip manufacturers changed their instruction sets, knowing that they were now providing a target for compilers, not for human coders.
I feel like we’re going through a similar process now. I believe that my Python code is still more elegant, readable, maintainable, efficient, and idiomatic than what AI produces. But I’m an above-average Python coder with 30 years of experience. Besides, within a few years, AI’s Python will be better than mine. Even now, I find that it often doesn’t matter: Even if Claude’s Python is only 80 percent as good as mine, it’s still more than good enough for most purposes, because it’s able to write code and tests far faster than I can.
But why am I asking Claude to write Python anyway? I’ve often said that Python is the perfect language for an age in which computers are cheap and humans are expensive. But that statement assumes that humans are doing the coding. If computers are cheap and also doing the coding, then the equation shifts. Now humans are doing the engineering, but not the coding. And if that’s the case, why am I having Claude write Python?
Most obviously, I’m thinking that we could have AI output Rust, rather than Python. Rust executes at the same speed as C, which is already an advantage over Python. But it also has a famously safe, strict paradigm for managing memory, while providing modern facilities like threads. And its compiler is famously strict, dramatically reducing the potential for memory and security problems.
Of course, Rust isn’t the only option; Wes McKinney, who developed the Pandas library, has lately been touting the programs he’s writing in Go, even though he doesn’t know Go. He writes, in his blog (https://wesmckinney.com/blog/agent-ergonomics/), “I have been building a lot of new software in Go. Except that I’ve never actually written a line of Go in my life. What is going on?” And McKinney isn’t alone; other well-known developers are now writing code in languages they don’t know. It’s as striking as a Poet Laureate of the United States writing poetry in a language they don’t speak.
I don’t think that people will be using AI to switch their entire codebase from Python to Rust in the near future. But the amount of new Python code might, sooner rather than later, slow down to a trickle, as people realize the output language doesn’t matter to AI.
This might, by the way, cause some other issues: AI is able to produce excellent Python because it has a large and constantly growing corpus of Python on which to draw. If people write less and less Python, then will AI continue to know and write it well? Will we keep writing Python just to ensure that AI is fed with sufficient data? That could end up in a negative feedback loop in which less human Python leads to worse agent Python, which leads to people switching from Python, which leads to even less human Python.
Who will maintain the Python ecosystem?
As for my second concern, I’ll hope and assume that the open-source community will continue to demonstrate its power, size, and diversity, and will continue to develop and improve Python. But that’s not a given. After all, part of the motivation for working on open-source projects is the knowledge that you’re helping a large number of people. But that’s wrapped up with those people knowing what packages they’re using. Will people be motivated to contribute to a library that even developers don’t know exists, because agents are doing the coding?
This is a potential problem, but it’s also a potential opportunity: There are a lot of worries about how young software engineers, fresh out of school, will be able to get jobs. If agentic coding is only possible (or effective) if you have experience writing software, and companies are only hiring people with agentic coding experience, then new graduates will have a tough time finding work. Indeed, we’re already seeing that happen to some degree.
Open-source projects could provide such young engineers with a chance to work on something important and useful, while benefiting from the interactions and constructive criticism that are a cornerstone of the open-source world. Someone who contributes to an open-source project for even a few months, participating in development decisions and learning at the feet of veteran engineers, will be in a good position to code — manually or with AI.
In grad school, I learned about “social-learning theory,” which posits that we don’t measure someone’s learning by giving them a test, but rather by seeing how central their role is. A newcomer to a field performs smaller, less important tasks. As they gain knowledge, they can take on larger and more important and central tasks — including mentoring less-experienced newcomers.
Open source has long demonstrated this social-learning approach. In the age of AI, it might provide a critical training ground, bridging the gap between university programs in computer science and the commercial world. I expect that over time, universities will change their educational approach, including agentic coding in how and what they teach. But large institutions move slowly, and they aren’t yet providing the skills that graduates need.
At PyCon US, several speakers warned that AI is already causing trouble for open source. AI bots are submitting pull requests and patches at a rate that maintainers cannot handle, and are causing burnout. AI is also finding security problems (some, but not all, hallucinated) that demand attention, vetting, and fixes. What happens to the humans in the mix? Where should and will we provide judgment? We can expect the use of agents to vet and triage PRs to grow. But no longer is the bottleneck on pull requests the number of human users, as some projects have found out the hard way.
Who will learn Python?
In a world where all coding is agentic, and where we are asking the agents to produce Rust, we might ask a deep and more disturbing question: Why learn Python at all? What’s the point of learning a programming language that an increasingly small group of people will be writing and using?
First: I don’t think that Python is about to disappear. Too many organizations and people depend on it, and the cost of switching away from Python would be overwhelming. For now, at least, the cost would be too much for too many organizations, especially places with only one or two people on their software team. COBOL is still around, in part because people cannot move away from it. You could argue that Python will stick around for similar reasons — but whereas people really love Python, you don’t have a lot of people singing the praises of COBOL’s elegance and flexibility. For that reason alone, people will continue to use Python.
But you might legitimately ask that if we’ll now be programming via agents, and if the agents will be writing code for us, then what’s the point of learning Python? If anything, maybe we should be learning Rust.
I continue to believe that agentic coding is like a chainsaw, extremely powerful in the hands of experts and dangerous in the hands of novices. If you’re going to write code with agents, then you have to know how to write code on your own. And Python is, hands down, the best and easiest way for people to learn to program, while remaining practical and modern.
It might seem weird for us to teach beginners Python, knowing that they’ll then have agents output other, faster languages. I see an analogy here with Chinese: Many people don’t realize this, but children in China first learn Latin characters, which they use to spell out Chinese phonetically, using a system called “pinyin.” They then use their knowledge of Latin characters to learn Chinese characters, whose pronunciation isn’t obvious from the characters themselves.
Python could similarly be a way to introduce programming concepts, even for people who will be writing Rust via agents. (Call it “Pynyin,” maybe?) We’ll teach them Python, have them use those Python skills to build up experience working on open source, and then send them into the big, wide world, where they’ll be effective software engineers, even if they never hand-write code ever again.
Python has a future. But in a world of agentic coding, it might be increasingly for teaching the basics of software engineering and providing AI with high-quality training data, rather than for direct coding of applications. It’s still worth learning and knowing Python — but it’s also worth doubling down on basic software-engineering principles, which we’ll increasingly be using to instruct and judge AI agents.