For most of my career, picking the stack was the first big decision on any new project. Now that coding agents write most of the code, I think it's one of the smaller ones. If you're wondering what the best language for AI coding is, my answer is: one where an agent gets a clear pass or fail quickly, that has lots of public code to learn from, and that you can still read when you review what it wrote. Plenty of languages pass that test. The research I cite below does show real differences between languages, but almost all of them come down to feedback and tooling.
Fifteen years of picking stacks
I've been writing software for more than 15 years, and the stack changed with almost every job. At Shogun, the Y Combinator page builder where I was the first engineering hire, it was Ruby on Rails and React. At Blocks I moved a big application from Rails to Elixir and Phoenix for performance and scale. EverAI, where I was the founding engineer, ran on Rails and React with LLM, image, voice and video APIs. TurbaMedia was Node.js, TypeScript and React, and Copia was TypeScript and Python. Somewhere in between there was React Native and a few years running an agency. The full list is in the Experience section.
For most of that time the stack really did decide a lot: who you could hire, which libraries you got for free, and how fast the team could move in the first few months. Switching languages cost you real time.
What changed with agents
Now agents write a lot of the code, in whatever language the project uses. Andrej Karpathy said that within a few weeks in December 2025 he went from writing most of his code himself to having agents write almost all of it (Yahoo Tech). Simon Willison opens his Agentic Engineering Patterns guide with a chapter called "Writing code is cheap now". Armin Ronacher, who wrote Flask, put it as "the cost of coding is going down dramatically" (A Language for Agents).
My own work this year is spread across a bunch of stacks:
- Rillow, a Next.js app.
- Bundle, which I build alone: one repo with an iPhone app, an Android app for e-ink tablets, a Chrome extension, a backend and a website.
- This site, plain HTML, CSS and JavaScript with no framework and no build step, plus Shiba Land, a small platformer in three.js.
- TypeScript and Python at Copia.
In each case the platform and the product picked the language. An agent reads and writes all of them well enough that my time goes into deciding what each product should do.
The data says languages still differ
To be fair, there's decent evidence that languages aren't equal for agents.
José Valim, who created Elixir, made the strongest case for one language in Why Elixir is the best language for AI. He cites Tencent's AutoCodeBench, which compared 20 languages across more than 30 models. Across all models, 97.5% of the Elixir problems were solved by at least one model, the highest of any language, and Claude Opus 4 scored 80.3% on Elixir, ahead of C# at 74.9% and Kotlin at 72.5%. He puts it down to immutability, which keeps a function's effects visible without loading the code around it, and to stability: Elixir has been on version 1.x since 2014, so old examples still work.
GitHub's Why AI is pushing developers toward typed languages cites a 2025 study that found 94% of compilation errors in LLM-generated code were type-check failures. TypeScript also became the most used language on GitHub in August 2025, ahead of Python and JavaScript.
Armin Ronacher gets specific. He says Go works well for agents because the code is easy to grep, import cycles aren't allowed and test results are cached, and he now uses TypeScript where he used to use Python. On the other side, he finds Swift's tooling painful enough that agents struggle, and Python's significant whitespace harder for an agent to edit cleanly.
Put together, they keep pointing at the same things: fast, clear feedback, and code an agent can understand from a few files. Those come from the type checker, the compiler, the test runner and the project's conventions much more than from the syntax.
What still matters
The first thing I look at is whether an agent can check its own work. A type checker, a compiler with helpful errors, tests that run in seconds and one command that says pass or fail do more for agent output than choosing between two languages. Armin's line is "The more uniform the tooling the better", and I agree. Even this site, which has no build step at all, has a check: a thread runs the site on a local server before a push and opens the live page after.
Conventions matter for the same reason. Rails and Phoenix put files where an agent expects them, and a stable language means the examples the model learned from still compile. A codebase with five ways to do the same thing confuses an agent the same way it confuses a new hire.
The platform still matters too. An iPhone app goes through Xcode, signing and App Review whatever language you write it in, and that tooling shapes an agent's day more than the language does.
And you still own what ships. Pick something you can read well enough to review, because you'll be reading a lot more code than you write.
So what is the best language for AI coding?
For a new project, I'd go with the language the platform expects and turn on the strictest checks the team can live with. For a web app that usually means TypeScript, because its type checker catches exactly the kind of error the GitHub study found most often, and there's a huge amount of public TypeScript for models to learn from. If you love Elixir, Valim's numbers say agents do well there too. If your team already knows Rails, keep Rails and put the effort into tests. An agent can work in any of them. What it struggles with is a codebase that gives it no way to check its work.
What this means if you hire engineers
Years in one framework tell you less than they used to. An engineer who works well with agents can get productive in an unfamiliar stack quickly, because the agent already knows it. The harder skills to find are breaking a feature into tasks an agent can finish, checking the result properly and deciding what not to build. That's what I'd interview for now.
Where I still choose carefully
There's still code where the language is worth real thought: hot paths where performance is the product, native platform work, and very new frameworks with little public code. Armin's take on Zig is a good example. It changes quickly and there isn't much training data, so it works, just not as well. And a big team on a long-lived codebase gets more from consistency than from any one language feature.
For everything else, pick the stack that fits the platform, make the feedback loop fast, and spend the time you save on the product. If you want to see what that looks like day to day, I wrote up my agentic coding workflow, and my CV has the rest of my background.