Programming language matters much more for AI-driven development
How programming language choice impacts the productivity of your AI-powered teams and what you can do about it
A bit over a year ago when I first began to roll out GitHub Copilot to my teams I noticed something odd: AI was seeing much better adoption with some teams over others: TypeScript, Javascript, SQL, and Terraform users found particularly fast adoption. Why would this be? After some developer interviews it turned the developers using the other languages we had in play, Haskell, Elm and Go, didn’t find the AI nearly as useful.
More recently I found a similar pattern, this time with Claude 3.5 and 3.7 via Continue.dev, the AI was substantially better at TypeScript and Python over C#. I began to see these same differences with my own use in Cursor as well across the C#-Python boundary.
This type of chart has always had substance for technology leaders, but the implication now is much more profound. Once upon a time your language choice would have impact on your ability to hire, the tooling/library ecosystem available to you, and the developer community you would find yourself in. Now this chart also indicates how well AI functions for your engineers. The productivity landscape is shifting radically.
Clearly if C#, the fifth most popular language for new code on GitHub, can’t hold a candle to the most popular languages today in terms of AI-efficiency with what are largely thought to be the best tools (Cursor and Claude). What chance do other programming languages have?
An AI’s effectiveness with a particular language isn’t directly just proportional to it’s popularity, however it is a reasonable proxy. What actually matters in how much total training data was used in the model training, and additionally if the AI companies fine-tuned on training data to make the model better in those specific cases. Javascript and Python have the advantage of a whole lot of public projects that can be leveraged to train AI, and Python in particular has been a well known target for fine tuning. Further, recency matters as well. If you care about the AI using the newer programming language features and using them well, along with newer libraries, the AI needs to be seeing data that reflects those changes.
To repeat for emphasis, the implication is clear: You should be paying careful attention to what languages your teams are adopting for what uses right now.
Some Caveats
It can still be worth it to use whatever you or your team is proficient in. The AI generation capability for Python, Javascript and TypeScript still isn’t close to perfect. You still need to iterate and debug, especially in complex code. There’s still room if you’re great at a language to go faster than with AI in contexts where the code isn’t repetitive. However, it’s now clearly at the point where a developer will almost certainly be slower than someone of equal skill using an AI-friendly language with AI because they can nearly one-shot entire pages of code.
Some languages are still worth it for doing the things they excel at. For example: the powerful memory safety of Rust for systems programming, or the incredible domain modeling power of Haskell or OCaml. You can write your low level interface in Rust and gain a lot of safety benefit. You can also write your must-be-correct domain model in a type safe language and be sure that illegal states are not representable. Then, on top of that solid core, you can interface with that specialized code in an AI-friendly language and potentially get the best of both worlds.
AI is still useful for other languages. In the example above, I know many a AI wielding C# dev using code completions and explanations quite effectively. It’s particularly in the cases of “one-shotting” large amounts of code, or doing large rewrites, that this capability matters.
Is it’s possible in a few years as the AI keeps getting better language choice won’t matter anymore. Potentially AI a few years out will be nearly always correct in basically anything given a manual or a short list of examples. However, this level of AI would also be close to not needing a human to drive it. The AI keeps getting better, and all recent research seems to indicate that they will continue to do so, however it’s not clear exactly what that will look like in practice.
What Can Tech Leaders do?
The most obvious thing you can do is slowly pivot your teams toward AI-friendly languages:
If you have a distributed architecture build that next service in an AI-friendly language and see what happens. You very likely already have people on your teams that know these languages. Even if you somehow don’t they’re extremely easy to pick up by someone skilled and powered by AI.
As my C# friend above, you can start with introducing end-to-end tests with Python or TypeScript. This current generation of AI really shines at API work and I have seen it save teams time in practice. This is also an area where an AI-powered junior might have an outsized impact
It’s still unlikely to be worth converting your legacy code, but potentially you could make your feature quickly via an API into an AI friendly language instead of within your existing service or monolith. Consider the classic strangler (fig) pattern. Of course, deciding if doing this is a good idea depends on so many factors it could easily be its own article.
Or it may be entirely reasonable to wait it out. Depending on your size and context this might be the best choice. If you have stable software without much change, why upset the working status quo? It’s possible (maybe even likely) that in a few years the AI will be good enough to own the system entirely by itself no matter the language.