This is great, and I think this is the right way to use AI: treat it as a pair programming partner and learn from it. As the human learns and becomes better at both programming and the domain in question (eg. a Ruby JIT compiler), the role of the AI partner shifts: at the beginning it's explaining basic concepts and generating/validating smaller snippets of code; in later stages the conversations focus on advanced topics and the AI is used to generate larger portions of code, which now the human is more confident to review to spot bugs.
Agree. My team and I were just discussing that the biggest productivity unlock from AI in the dev workflow is that it enables people to more easily break out of their box. If you're an expert backend developer, you may not see huge lift when you write backend code. But when you need to do work on infrastructure or front-end, you can now much more easily unblock yourself. This unlocks a lot of productivity, and frankly, makes the work a lot more enjoyable.
I think AI will push programming languages in the direction of stronger hindly milner type type checking. Haskell is brutally hard to learn but with enough of a data set to learn from, its the perfect target language for a coding agent. its high level, can be formally verified using well known algos and a language server could easily be connected with the ai agent via some mcp interface.
IMO, Haskell is less helpful for an LLM because of its advanced language features. The LLM is reasoning about the language textually. Since Haskell is very tense, the LLM would need a very strong model of how the language works.
I think languages with more minimal features and really good compile time errors would work well with LLMs. In particular, I've heard multiple people say how good LLMs are at generating Go.
Personally, I like languages with type inference so this wouldn't be my preference.
I’ve been enjoying doing a bunch of assembly language programming - something I never had the experience of or capability to learn to competence or time to learn previously.
Counter point: AI makes mainstream languages (for which a lot of data exists in the training data) even more popular because those are the languages it knows best (ie, has the least rate of errors in) regardless of them being typed or not (in fact, many are dynamic, like Python, JS, Ruby).
The end result? Non-mainstream languages don't get much easier to get into because average Joe isn't already proficient in them to catch AI's bugs.
People often forget the bitter lesson of machine learning which plagues transformer models as well.
Most people who work in non-mainstream languages are, to some extent, making a statement. They care more about X than mere "popularity". (Sometimes X is money, hence why I still have Anki flashcards in rotation on OCaml, Intersystems Cache and Powershell.)
If they do want "popularity" then the counter-counter-point is that it should be easier to get than ever. Just have one proficient person write a lot of idiomatic, relatively isolatable code, and then have an AI generate terabytes upon terabytes of public domain licensed variations and combinations on that code. If you make programming in the small a breeze, people will flock to your language, and then they can discover how to program in the large with it on their own time.
Yes, I worry that we're in for an age of stagnation, where people are hesitant to adopt radically new languages or libraries or frameworks because the models will all be bad at them, and that disadvantage will swamp any benefit you might get from adopting an improved language/library/framework.
Alternatively every new release will have to come with an MCP for its documentation and any other aspects that might make it easier for an LLM to talk about it and use it accurately.
I was thinking the same the other day. No need for high-level languages anymore. AI, assumming it will get better and replace humans coders. has eliminated the labour constraint. Moores law death will no longer be a problem as performance gains are realised in software. The days of bloated electron apps are finally behind us.
true. doing pair programming with AI for last 10 months I got my skills from zero to sufficient profficiency (not expert yet) in totally new language — Swift. entry barrier is much lower now. research advanced topics is much faster. typing code (unit tests, etc.) is much faster. code review is automated. it is indeed makes barrier for new languages and tools lower.
We learn natural languages by listening and trying things to see what responses we get. Some people have tried to learn programming the same way too. They'd just randomly try stuff, see if it compiles then see if it gives what they were expecting when they run it. I've seen it with my own eyes. These are the worst programmers in existence.
I fear that this LLM stuff is turning this up 11. Now you're not even just doing trial and error with the compiler, it's trial and error with the LLM and you don't even understand what it's output. Writing C or assembly without fully reasoning about what's going on is going to be a really bad time... No, the LLM does not have a working model of computer memory, it's a language model, that's it.
I've noticed this at work where I use Python frameworks like Flask/FastAPI/Django and Go, which has the standard library handlers but within that people are much less likely to follow specific patterns and where there are various composable bits as add ons.
If you ask an LLM to generate a Go handler for a REST endpoint, it often does something a bit out of step with the rest of the code base. If I do it in Python, it's more idiomatic.
> The real breakthrough came when I stopped thinking of AI as a code generator and started treating it as a pairing partner with complementary skills.
I think this is the most important thing mentioned in the post. In order for the AI to actually help you with languages you don't know you have to question its solutions. I have noticed that asking questions like why are we doing it like this and what will happen in the x,y,z scenario, really helps.
I wonder, are some programming languages more suitable for AI coding agents (or, rather LLMs) than the others? For example, are heavy on syntax languages at disadvantage? Is being verbose a good thing or a bad thing?
P.S. Maybe we will finally see M-expressions for Lisp developed some day? :)
I don't think I've ever seen an experienced software engineer struggling to adapt to a new language.
I have worked in many, many languages in the past and I've always found it incredibly easy to switch, to the point where you're able to contribute right away and be efficient after a few hours.
I recently had to do some updates on a Kotlin project, having never used it (and not used Java in a few years either), and there was absolutely no barrier.
I wanted to test Gemini's code generation so I asked it for a bash script iterating through an array of directory names and executing a command for each one.
It got it wrong. The command was generated outside of the for, and never updated inside the loop effectively making it useless.
Luckily I know bash so I spotted it immediately. But I wonder how it's "removing programming language barriers" when one that does not know its output language can not spot even such a glaring issue.
I’ve done similar tools with Go and haven’t had any issues.
One goes through a tree of dirs, finds zip files with images, unzips, benchmarks which image format is the most compact and creates a new zip with that.
What about the part of programming and software development that relies on programmatic/systemic thinking? How much is the language syntax itself part of any 'program' solution?
46 comments
[ 2.1 ms ] story [ 67.6 ms ] threadI think languages with more minimal features and really good compile time errors would work well with LLMs. In particular, I've heard multiple people say how good LLMs are at generating Go.
Personally, I like languages with type inference so this wouldn't be my preference.
The end result? Non-mainstream languages don't get much easier to get into because average Joe isn't already proficient in them to catch AI's bugs.
People often forget the bitter lesson of machine learning which plagues transformer models as well.
Strong typing drastically reduces hallucinations and wtf bugs that slip through code review.
So it’ll probably be the strongly typed languages that receive the proportionally greatest boost in popularity from LLM-assisted coding.
If they do want "popularity" then the counter-counter-point is that it should be easier to get than ever. Just have one proficient person write a lot of idiomatic, relatively isolatable code, and then have an AI generate terabytes upon terabytes of public domain licensed variations and combinations on that code. If you make programming in the small a breeze, people will flock to your language, and then they can discover how to program in the large with it on their own time.
Alternatively every new release will have to come with an MCP for its documentation and any other aspects that might make it easier for an LLM to talk about it and use it accurately.
I still spend a few days studying Rust to grasp the basic things.
It almost never misses on explaining how certain syntax works.
I fear that this LLM stuff is turning this up 11. Now you're not even just doing trial and error with the compiler, it's trial and error with the LLM and you don't even understand what it's output. Writing C or assembly without fully reasoning about what's going on is going to be a really bad time... No, the LLM does not have a working model of computer memory, it's a language model, that's it.
If you ask an LLM to generate a Go handler for a REST endpoint, it often does something a bit out of step with the rest of the code base. If I do it in Python, it's more idiomatic.
I think this is the most important thing mentioned in the post. In order for the AI to actually help you with languages you don't know you have to question its solutions. I have noticed that asking questions like why are we doing it like this and what will happen in the x,y,z scenario, really helps.
P.S. Maybe we will finally see M-expressions for Lisp developed some day? :)
I have worked in many, many languages in the past and I've always found it incredibly easy to switch, to the point where you're able to contribute right away and be efficient after a few hours.
I recently had to do some updates on a Kotlin project, having never used it (and not used Java in a few years either), and there was absolutely no barrier.
It got it wrong. The command was generated outside of the for, and never updated inside the loop effectively making it useless.
Luckily I know bash so I spotted it immediately. But I wonder how it's "removing programming language barriers" when one that does not know its output language can not spot even such a glaring issue.
I’ve done similar tools with Go and haven’t had any issues.
One goes through a tree of dirs, finds zip files with images, unzips, benchmarks which image format is the most compact and creates a new zip with that.
Got it right the first go (hehe pun)
AI code review helps you catch issues you've forgotten about and eliminates the repetitive work
These tools are helping developers create quality software - not replace them