A software engineer’s quiet manifesto about choosing Go over Rust and Python for AI-assisted coding has struck a nerve in developer communities, reigniting a debate about which programming languages are best suited for the age of large language models writing code alongside humans. The argument isn’t about syntax preferences or performance benchmarks. It’s about something more fundamental: which languages does AI actually write well?
The term “vibe coding” — coined by Andrej Karpathy earlier this year to describe the practice of letting AI generate most of your code while you steer at a high level — has moved from Twitter joke to legitimate methodology faster than most anticipated. And as developers increasingly rely on tools like Claude, GPT-4, and GitHub Copilot to produce working software, a new selection pressure is being applied to programming languages. Not which language is fastest. Not which has the best type system. Which one does the AI get right most often?
That’s the core thesis advanced by Theo Carlin in a recent essay on Lifelog, titled “Why I Vibe in Go, Not Rust or Python.” His argument is deceptively simple: Go’s design philosophy — explicit, minimal, boring — makes it the ideal target language for LLM-generated code. Python is too loose. Rust is too complex. Go sits in a sweet spot that AI models can reliably hit.
The Case Against Python and Rust in an AI-First Workflow
Carlin’s critique of Python for vibe coding isn’t that it’s a bad language. It’s that Python’s flexibility becomes a liability when an AI is writing it. Python’s dynamic typing means LLMs can produce code that looks correct, passes a cursory review, and then fails at runtime in ways that are difficult to trace. The absence of compilation means errors surface late. And Python’s vast standard library, combined with its enormous third-party package universe, means the AI has too many ways to solve any given problem — many of them subtly wrong or outdated.
“The AI will happily import a library that was last updated in 2019,” Carlin writes, describing a common frustration. Python’s permissiveness, which makes it beloved for prototyping and data science, turns into a trap when the human in the loop is reviewing code at speed rather than writing it character by character.
Rust presents the opposite problem. Its ownership model, lifetime annotations, and borrow checker create a language that is extraordinarily safe — but extraordinarily difficult for current LLMs to generate correctly. Carlin describes sessions where AI-generated Rust code would fail to compile repeatedly, with the model getting stuck in loops trying to satisfy the borrow checker. Each fix introduced new errors. The human operator, supposedly freed from low-level concerns by vibe coding, ended up doing more debugging than if they’d written the code themselves.
This tracks with broader observations in the developer community. Rust’s compile-time guarantees are its greatest strength for human programmers who internalize its mental model over months or years. But LLMs don’t internalize mental models. They predict token sequences. And Rust’s strict constraints mean the space of valid token sequences is narrow and unforgiving.
Go, by contrast, was designed from the outset to be simple. Its creators at Google — Rob Pike, Ken Thompson, and Robert Griesemer — deliberately excluded features like generics (until recently), inheritance, and exceptions. The language has one way to do most things. Error handling is explicit and repetitive. The type system is static but straightforward. There’s a single canonical formatting tool. And critically, Go compiles fast and produces clear error messages.
For AI-generated code, these properties are gold. The LLM produces Go code that compiles on the first try more often. When it doesn’t compile, the error messages are specific enough that the AI can fix them in one iteration. The limited surface area of the language means fewer opportunities for the model to hallucinate nonexistent APIs or misuse obscure features. And Go’s explicit error handling — often criticized by human programmers as verbose — turns out to be exactly the kind of structured, predictable pattern that LLMs reproduce well.
Carlin’s essay is persuasive in part because it’s pragmatic rather than tribal. He isn’t arguing Go is the best language. He’s arguing it’s the best language for this specific workflow.
A Broader Industry Reckoning With AI-Compatible Design
The implications extend well beyond one developer’s preferences. If the vibe coding thesis holds — if AI-assisted development continues its rapid adoption trajectory — then language design itself may need to evolve in response to a new primary user: the machine.
This is already happening in adjacent spaces. Anthropic, OpenAI, and Google have all invested in improving their models’ code generation capabilities, with benchmarks like SWE-bench and HumanEval tracking progress. But the benchmarks themselves reveal an asymmetry. Models consistently score higher on Python tasks, partly because training data skews heavily toward Python, and partly because Python’s forgiving runtime lets partially correct code still execute. Go benchmarks tend to be stricter — the code compiles or it doesn’t — but the code that does compile is more likely to be correct.
Recent discussions on X (formerly Twitter) have amplified this debate. Multiple developers have posted comparisons of AI-generated code quality across languages, with Go frequently cited as producing the most “production-ready” output from a single prompt. One thread from a senior engineer at a major cloud provider noted that their team had switched internal tooling projects from Python to Go specifically because AI pair programming was more effective. Not faster. More reliable.
The counterarguments are real. Python’s dominance in machine learning, data analysis, and scripting means it isn’t going anywhere. Its training data advantage in LLMs is self-reinforcing — more Python code in the training set means better Python generation, which means more people use AI to write Python, which produces more training data. Rust advocates argue that the borrow checker failures are a feature, not a bug: if the AI can’t write safe Rust, that’s the AI’s problem to solve, and the resulting code will be safer when it does compile.
But Carlin and others pushing the Go-for-vibe-coding position aren’t making a theoretical argument. They’re making a practical one. Right now, today, with the models available in mid-2025, Go produces the best ratio of AI-generated code that works on first pass to code that requires human intervention. And for developers whose goal is velocity — shipping working software quickly by collaborating with an AI — that ratio is what matters.
There’s a deeper philosophical question lurking here too. Programming languages have always been interfaces between human intent and machine execution. If AI becomes the primary author of code, with humans serving as editors and architects, then the relevant interface shifts. The language needs to be legible to both the AI writing it and the human reviewing it. Go’s simplicity serves both audiences. Python is legible to humans but treacherous for AI to get exactly right. Rust is safe for machines to execute but hard for AI to produce.
Some language designers are already paying attention. Proposals for new languages and language features increasingly reference “AI-friendliness” as a design criterion. The Go team’s recent additions — generics in Go 1.18, iterators in Go 1.23 — have been notably conservative, adding capability without sacrificing the simplicity that makes the language predictable. Whether this was intentional positioning for the AI era or simply adherence to Go’s original philosophy, the effect is the same.
The vibe coding movement is still young. Its practitioners are disproportionately indie developers, startup engineers, and side-project builders — people optimizing for speed over ceremony. But enterprise adoption is accelerating. Companies are building internal tools, microservices, and CLI applications using AI-assisted workflows, and the language choice for those projects increasingly reflects not just team expertise but AI compatibility.
Go isn’t perfect for this. Its error handling remains verbose. Its lack of sum types makes certain patterns awkward. Its garbage collector introduces latency that disqualifies it from some real-time applications. But perfection isn’t the point. Fitness for purpose is. And for the specific purpose of collaborating with an LLM to produce working, deployable, maintainable code — Go is winning.
The question isn’t whether vibe coding is legitimate. Millions of developers have already answered that. The question is whether the languages we use will adapt to this new reality, or whether new languages will emerge that are designed from scratch for human-AI collaboration. Either way, Go’s accidental head start — born from a philosophy of simplicity that predates the current AI moment by fifteen years — looks increasingly like foresight.
WebProNews is an iEntry Publication