Python is Dead
Click bait title? CLICK AND FIND OUT!
Last month I wrote a dynamic malware analysis tool in Rust. About 20,000 lines of it. Process management, threading, memory management, the whole stack. I don’t know Rust.
I was using AI agents, which you probably guessed, but here’s the part you wouldn’t guess: it was easier than writing Python. I write Python with agents every day, and it’s a constant fight — the same kind of fight I used to have managing junior engineers, except junior engineers eventually learn. You babysit types because the language won’t. You remind the agent about edge cases it’s already forgotten. It sneaks in bugs that hide until runtime because nothing in the language stops them. You’re basically the compiler that Python doesn’t have, except you’re a human, so you miss things.
With Rust, the actual compiler did the babysitting. The agent could be sloppy and the language wouldn’t let the sloppiness ship. I spent my time on architecture and design instead of playing whack-a-mole with None values and silent type mismatches.
The reason I’d used Python for a decade wasn’t because Python is a great language. It’s because I had limitations that Python was kind enough to work around, and I’d just outsourced those limitations to something that doesn’t have them.
Python isn’t a great language. Python is a great accommodation.
Trade-Offs from the Before Time
Python made trade-offs that were completely rational when humans were writing the code. But that was way long ago, in the before time (about 2-3 months ago).
Python made typing optional, because a human fighting TypeVar and Protocol for twenty minutes on a prototype they’ll rewrite in a week will quit and go use JavaScript. This leads to all sorts of bugs that could have been caught with a type check getting caught by your customers in production instead. Python made itself interpreted, because humans want to change a line and see the result immediately, no compile step, instant gratification. The cost is that your code runs 10x to 100x slower than C and entire classes of errors hide until that exact line executes in production. Typos, wrong argument counts, references to variables that don’t exist. They’re there. They’re just waiting for the right customer to trigger them.
Python chose duck typing, because humans don’t want to declare interfaces for every object relationship. The cost is that you rename a method during a refactor and nothing breaks until six weeks later when a user hits the forgotten code path (ask me how I know) and your monitoring page lights up. Python added the GIL, because humans shouldn’t have to think about thread safety for simple scripts. The cost is that true parallelism is basically impossible and you’re leaving most of your CPU cores idle.
Every one of these trade-offs is the same bet from a different angle: make the developer’s life easier right now, and hope the bill doesn’t come due too badly later. It’s a labor contract written for a workforce that gets frustrated, forgets things, and has the working memory of a goldfish with a computer science degree.
The Python community knows the bill comes due. That’s why they’ve spent the last decade bolting the safety back on. Type hints, mypy, Pydantic, runtime type checking, stricter linters, --strict modes everywhere. They’re retrofitting the guarantees that Python’s designers chose to strip out thirty years ago. This is the tell. When you spend a decade trying to add back what you removed, the original removal was a trade-off, not a feature.
The problem is that the developer Python was designed for just got replaced.
A Different Species of Programmer
Imagine you run a factory and you replace your entire human workforce with robots overnight. The robots don’t trip, don’t get tired, don’t pull the wrong lever, and can hold the entire operations manual in memory. Suddenly your wide aisles are wasted floor space, your color-coded controls are solving a problem that doesn’t exist, and your mandatory break times are just downtime. You didn’t build a bad factory. You built a factory for humans, and the workers changed.
Python is that factory.
Humans can hold about seven things in working memory, which is why Python lets you skip type annotations. AI agents hold the entire codebase in context (with summaries, RAG, etc), every type, every function signature, every dependency relationship at once. Asking them to annotate types is like asking the robot to read the warning sign it doesn’t need.
The Rust compiler is famous for rejecting your code 47 times before you get the lifetime annotations right. Humans experience this as demoralizing. Some quit. Some see the light and become fever-eyed Rust zealots who can’t wait to tell you their project uses Rust so you know it’s good. Python chose to never yell at you, and that was a real competitive advantage when the person doing the typing had feelings about being yelled at. You can reject an agent’s code a thousand times and it’ll cheerfully rewrite it without posting a rant on Hacker News about toxic compiler culture.
Python didn’t lose anything. It’s exactly the language it was last year. But last year the person paying for its trade-offs was you, and you were expensive enough that the trade-offs made sense. Now the person paying is a thing that costs pennies per hour and never gets frustrated. Speed, safety, compile-time guarantees, provable correctness — everything Python traded away to be kind to you is back on the table.
Appropriately Hyped
A colleague of mine, somewhat new to trad-programming, very hip to AI, started writing Rust with agents. His verdict: “appropriately hyped.” He’s English, so this is high praise.
Rust’s trade-offs are the inverse of Python’s. Where Python relaxes constraints to save human effort, Rust imposes them to guarantee correctness. The joke in the Rust community is that the language has a “wall” — the point where the borrow checker makes you question your career choices. When the person paying the price is an AI agent, the wall doesn’t exist. A borrow checker is just a well-specified set of rules, and agents are very good at following rules (better than the humans writing them, frankly).
I mentioned that agents sneak bugs into Python constantly. The same agents write buggy Rust too, hallucinating function signatures and inventing lifetimes that make no sense. The difference is that the compiler catches it before shipping, while Python lets it through and waits for your customers to find it.
The obvious objection: “But the ecosystem. The entire machine learning world runs on Python, and you can’t pip install your way out of that.” Ecosystems follow labor, though. They always have. The ML world was C++ before it was Python, and MATLAB and Fortran before that. Libraries get rewritten when the workforce moves. Mojo (💕🔥) was the most interesting attempt to thread the needle. It’s a Python superset that added performance, built by people who genuinely knew how to design languages, not some frustrated developer’s weekend project. It was the right answer to the wrong question. A faster horse in 1905, built by an excellent stable.
You’re Writing HR Policy
When you pick a programming language for a project, you’re not making a technology decision. You’re setting labor policy for your workforce.
Python’s policy says hire anyone, require minimal training, accept high defect rates, catch problems in production, and move fast. This is startup HR. Rust’s policy says invest in onboarding, demand near-zero defect rates, catch problems before deployment, and build things once. This is aerospace HR.
When humans were the labor force, Python’s policy made sense for most software. AI flips both sides of the equation. The cost of labor drops to nearly zero while the cost of mistakes stays exactly the same. A production crash still costs customers, a security vulnerability still costs reputation. When labor is cheap and mistakes are expensive, the rational policy is to make the worker prove correctness upfront.
Python still makes sense for throwaway scripts and data exploration where correctness doesn’t matter. The scratchpad isn’t going anywhere. But production software that runs while you sleep and breaks when nobody’s watching? Python’s policy is the wrong one for a workforce of machines.
The Machine Stops
That’s the near-term picture: stricter policies, agents writing the code humans used to write. Not necessarily Rust — Go, Zig, and anything else with a real type system and compile-time checks gets the same tailwind. Rust just happens to have the strictest compiler and the most to gain when “strict” stops being a cost. Reasonable, predictable, already happening.
The longer-term picture gets weird, because Rust is still a language built for human hands. It just happens to suit agents better than Python does. A language designed for agents would look nothing like either one.
Programming started close to the machine. Assembly was dense, efficient, and hostile to human readers. We spent fifty years climbing the abstraction ladder, trading machine efficiency for human readability at every step: C, then C++, then Java, then Python. Each rung made code friendlier to human eyes and more wasteful from the machine’s perspective. Now the reader isn’t human anymore. We’re climbing back down.
There’s recent research showing that Chinese is more efficient than English for LLMs because Mandarin packs more meaning per token. One character carries what takes an entire English word (Mandarin has been doing compression that programmers think they invented). If token density matters for natural language, it matters even more for programming languages, where context windows are the hard constraint on how much of a program an agent can reason about at once. An AI-first language would optimize along axes that never mattered when humans were reading and writing the code.
Token density. Expand to wide Unicode. Every variable name could be a single glyph, every complex syntax structure a single character. Agents attend to more code in the same context window, hold more of the program in working memory at once.
Formal verifiability. Move beyond type checking to compile-time proofs. The compiler doesn’t just check that your types line up; it proves that your function terminates, your memory is freed, and your invariants hold.
Declared effects. Every function explicitly states what it reads, writes, and depends on, machine-enforced. Agents reason about any function in isolation without tracing side effects through the whole program. Humans gave up on this because it was too verbose. Agents wouldn’t care.
Parallel-native execution. Every operation is assumed concurrent unless explicitly sequenced. Humans think sequentially because we experience time linearly. Every language we’ve built defaults to sequential execution with parallelism bolted on. Agents don’t share that limitation.
Structural editing. Agents already think in structure, not text, but they’re forced to output text files because that’s what our languages are. A language designed for agents might not have a text representation at all — just an AST that agents manipulate directly, rendered into something human-readable only when a human asks to see it.
That last axis is the one that should make you uncomfortable, because it means code humans can barely read. Languages where humans are second-class citizens for comprehension. What the Python community calls “Pythonic code” is really code shaped for human eyes, and “The Zen of Python” is a style guide for a species that can’t hold more than seven things in its head. The entire software craftsmanship movement, every “best practice” about clean naming and small functions and DRY, was cognitive ergonomics for human readers. The CNC machine doesn’t need ergonomic handles.
I’m already there, partly. I read code mostly during reviews and architecture discussions now. When I’m building, I describe what I want, the agent writes it, and I verify the behavior. I don’t read every line any more than a VP of Engineering reads every line their team writes. This is fine, until something goes wrong that the agent can’t fix, and you’re staring at code you can’t read in a language you don’t speak, trying to debug a system you’ve been supervising but never understood. That’s a terrifying sentence and I wrote it about myself. Forster wrote this story in 1909. It didn’t end well, but I’m less of a pessimist, and I wasn’t writing this story over 100 years ago.
The field is moving too fast for strong predictions, but these optimization axes seem reasonable.
Python was a brilliant answer to a real problem: humans are slow, forgetful, and impatient, and they needed a language that forgave all three. It’s not that Python got worse. It’s that the bottleneck Python was designed for has been upgraded.
Language choice was always about the bottleneck. The bottleneck was you.