Why Go Might Be a Better Language Than Python for AI Agent Development
Flask Creator Armin Ronacher: “AI Agents Perform Much Better on Go Than on Python”
Armin Ronacher — the creator of Flask, one of Python’s most iconic web frameworks — recently made a confession that shocked the Python community. His AI startup’s codebase is now 90% AI-generated, and the core backend isn’t written in Python. It’s written in Go.
This isn’t a theoretical preference. It’s a conclusion he reached after measuring real results. And the reason isn’t what you’d expect.
The Experiment No One Expected
In a recent podcast interview, Armin shared something that should make every tech lead pause:
“I did actual testing… I found that AI Agents perform much better on Go than on Python.”
Coming from the man who built Flask, this isn’t an anti-Python rant. Armin still uses Python — for machine learning, data processing, and infrastructure management with Pulumi. He explicitly states: “Whether you like it or not, Python will be part of your stack.”
But for his company’s core services? He chose Go. And the quality of AI code generation was a decisive factor.
Why AI “Gets” Go Better Than Python
The answer lies in a deceptively simple observation. As Armin puts it:
“Because the abstractions are very thin, it (AI) can understand the code better.”
Let me break down what this means in practice.
Go has no magic. There are no metaclasses, no decorator chains, no multiple inheritance hierarchies. When an AI agent reads Go code, what it sees is what it gets. The type system is explicit. Error handling is verbose but predictable. If a struct has a method, any interface requiring that method is automatically satisfied — no registration, no configuration.
Armin explains:
“Go also has this concept… similar to duck typing in Python where you can, if something has a method doSomething, then it will conform to an interface that has doSomething. The AI doesn’t have to understand complex type hierarchies. It doesn’t have to understand subclassing. It’s just like, if the thing is there and it can call it, it can probably call it.”
The result? Optimal AI-generated Go code looks almost identical to human-written Go code. The gap between “what AI produces” and “what good Go code looks like” is remarkably small.
Python’s Hidden Tax on AI Agents
Python’s problem isn’t performance — it’s fragmentation.
Armin identifies three layers of friction that confuse AI agents:
1. Competing ecosystems and coding styles
“Django people write code very differently than Flask people, than machine learning people. And so the AI cannot really tell that apart. It’s exposed to a lot of different competing styles of Python code.”
When you don’t steer the agent strongly enough, it switches between styles mid-project. One function looks like Django, the next like FastAPI, the third like a data science notebook.
2. The typing chaos
Python has type hints, but enforcement is inconsistent. Armin points out that mypy, pyright (Microsoft's), and ty (Astral's) all behave differently. The AI gets confused because the rules change depending on which type checker you're using — and sometimes the AI doesn't even know which one you're using.
3. The packaging nightmare
“Sometimes it wants to use pip even though I already told it to use uv, just because the corpus has so much pip in it.”
With seven different packaging solutions in Python, the AI frequently picks the wrong one. It recalls patterns from its training data that conflict with your project setup.
Armin frames this beautifully:
“The cost of having seven different packaging solutions in Python is high. But we for many years got away by saying, ‘well, you just need to read this and this is your problem.’ But it’s not really your problem — it’s everybody’s problem. It’s like a tax on the ecosystem.”
The Conveyor Belt of Infinite Interns
This is perhaps Armin’s most powerful mental model for understanding AI agents.
He credits his colleague Lukasz with this analogy: AI agents aren’t like interns who learn. They’re a conveyor belt of infinite interns — each one fresh, each one starting from zero.
“One of the benefits of having a different intern all the time is that you can throw a virtual person at a problem from scratch. They have never seen it. And so it can measure how good does a completely new intern work on this project.”
This reframing changes everything. If every “intern” starts fresh, then your ecosystem’s accessibility becomes directly measurable. And Python’s ecosystem, by this metric, is measurably less accessible than Go’s.
Why? Because when a new Go “intern” shows up, there’s essentially one way to structure a web service, one way to handle errors, one way to manage dependencies. The intern can be productive immediately.
When a new Python “intern” shows up, it faces: pip or uv or poetry or conda? Django or Flask or FastAPI? async or sync? mypy or pyright? The intern wastes cycles on decisions that have nothing to do with the actual problem.
The Anti-Abstraction Revolution
There’s a deeper principle at work here that goes beyond Go vs. Python.
Armin references Cal Henderson — former CTO of Flickr and Slack — who advocated writing SQL directly rather than using ORMs. The reasoning? ORMs eventually hit their limits, and then you’re stuck rewriting in SQL anyway.
This was always a hard sell. Developers love abstractions. But AI changes the equation:
“Nobody likes writing SQL. That’s why we have ORMs. But now that an agent can write SQL for me, the cost of SQL is not nearly as high anymore.”
The pattern is clear: AI makes low-abstraction code cheaper to write, while high-abstraction code remains expensive for AI to reason about.
This is why Go — a language that was sometimes criticized for being “too simple” — turns out to be perfectly positioned for the AI era. Its lack of abstraction layers isn’t a weakness. It’s exactly what makes AI agents productive.
What I’ve Observed
I work primarily in Go, and my own experience aligns with Armin’s findings.
When I use Claude Code on my Go projects, the generated code is usually correct on the first try — or close enough that the compiler catches the remaining issues instantly. The feedback loop is tight: write → compile → fix type errors → done.
With Python projects, I find myself spending more time steering the agent than actually building. “No, use uv, not pip." "No, this project uses pydantic v2, not v1." "No, don't add async here, this isn't an async codebase." Each correction is small, but they accumulate into significant friction.
This isn’t Python’s fault as a language. It’s the cost of a rich, diverse ecosystem that evolved organically over decades. But in the age of AI agents, that diversity becomes a tax.
The Implications for Your Tech Stack
Armin’s decision logic is worth studying:
- Python remains irreplaceable for ML/data science, data processing, and certain infrastructure tasks. Don’t abandon it.
- For core backend services — especially in a startup where AI agents do most of the coding — Go’s simplicity translates directly into higher AI productivity.
- Rust is for “Rust-shaped problems” — binary data processing, databases, load balancers, high-performance Python extensions. But its compilation speed and ownership model create too much friction for rapid iteration.
- AI code generation quality is now a legitimate criterion in tech stack evaluation. If your “army of interns” is 30% more productive in one language, that compounds over time.
The Bigger Picture
Here’s what I find most fascinating about Armin’s perspective. He’s not making a religious argument. He still writes Python. He’s about to reintroduce Rust via PyO3 bindings. He uses TypeScript for frontend work.
The point isn’t that Go is the “best” language. The point is that the criteria for choosing a language have fundamentally changed.
In the pre-AI era, we optimized for human expressiveness — how quickly can a developer write elegant code? In the AI era, we increasingly need to optimize for machine readability — how easily can an AI agent understand, generate, and verify code in this language?
Go was never designed to be “LLM-friendly.” But its design philosophy — simplicity, explicitness, minimal abstraction — accidentally made it one of the most AI-friendly languages in existence.
The AI revolution isn’t just about what models can generate. It’s about which ecosystems make generation reliable.
And reliability, as any engineer knows, is what ships products.
