Hello,
I was wondering what is the general stance of Nim on LLMs, especially "vibe coding", as I see that it seems to be pretty popular in these forums, which is honestly scary. LLMs for coding are known to cause more bugs, more problems, and a huge technical debt, and while Nim is a great language, I must admit that I do not want to really get too enthusiastic and involved in it, if it's going to be contaminated with low quality, error-prone, ethically dubious code.
Obviously I'm expecting a big opposite reaction since a lot of people here like to "vibe code", but I can't really pretend that I'm fine with it, so I decided to just be blunt. But this is a real question, I would strongly appreciate a honest answer, even though I feel like I already know what it's going to be.
Thanks!
I use it as a code-generator, giving me the massive amounts of code I need to bring Nimony the feature-parity with Nim 2. To make Nim 3 a reality sooner. I try hard to ensure the code is close to how I would have written it by hand. The code always uses my own algorithms and designs.
IMO that does not make it "ethically dubious code".
As for my personal opinion on LLMs and AI in general -- can't wait until the real costs emerge so that we go back to much more manual coding.
LMs for coding are known to cause more bugs, more problems, and huge technical debt.
I was going to ask for a source on that, but since I know there probably aren't any recent ones, I won't bother. LLMs are perfectly capable of producing original work, not just derivatives, but I think we're still figuring out how to talk about that.
It's going to be contaminated with low-quality, error-prone, ethically dubious code.
Ultimately, that responsibility falls on the creator. If someone isn't producing quality software, regardless of how they built it, I'm not sure it makes sense to put all the blame on the LLM. The tool can make mistakes, but the person using it is still responsible for the result.
Also, isn't the effort to create high-quality, standardized, and verified instructions for LLMs part of building an ecosystem that produces better code? That's one of the reasons I made https://github.com/planetis-m/skills public and free to use.
It's also worth remembering that software development has always benefited from contributions from people with different backgrounds, including many without formal CS degrees. Most projects don't reject contributors outright because their first submission isn't perfect; they review, discuss, and improve it.
I'm also optimistic that the AI bubble will burst, for all our sakes. I have other skills outside of software that I enjoy and that aren't likely to be replaced anytime soon.
I don't know what exact kind of sources you'd like, but just on wikipedia (https://en.wikipedia.org/wiki/Vibe_coding#Criticism) most sources seem to date from 2025 and 2026, which isn't really old.
I mean, when you think about it, LLMs producing code come from absorbing without understanding public code, which itself is often full of errors (especially if you take into account all the low-quality or test repositories on Github and such, that were probably used as training data but that no human would refer to as a reference in code quality). And if an LLM struggles not telling people to commit suicide, I don't see how it would reliably create complex code structures.
I understand that you can always check the produced code, but it doesn't just add a level of effort, it also makes you less knowledgeable about your own code.
And of course, the perfect amazing dev might end up scanning the produced code so well that they understand every tiny detail of it and avoid all bugs, but what is the percentage of devs like that, compared to the average? Vibe coding becoming more common, also makes people who don't have such a mastery of programming, overestimate the quality of the code produced and this can only end up in wasted efforts or in a disaster. So in the end I worry about something like Nim "encouraging" vibe coding, because in the long run it just risks contaminating the language with a lot of low-quality contributions, which can easily poison and kill an open source project.
Ultimately, that responsibility falls on the creator. If someone isn't producing quality software, regardless of how they built it, I'm not sure it makes sense to put all the blame on the LLM. The tool can make mistakes, but the person using it is still responsible for the result.
Exactly 100%! The term "vibe" coding implies little to no oversight by an experienced dev. For example, most of what @araq is making wouldn't fit the idea of "vibe coding".
We don't have a common term yet for "LLM enhanced" coding -- likely it'll just become part of normal programming. The rush of the latest eternal September of vibe coders will be over and we'll find a new balance. Especially as @araq pointed out, the economics will become apparent too.
I was going to ask for a source on that, but since I know there probably aren't any recent ones,
Additionally what was true six months ago for flagship models has changed. The quality of output from GTP-5.5 and Claude Opus 4.8 when combined with their agentic tools is pretty amazing if still formulaic.
They still need guiding, but they often handle corner cases I would've missed. They're pretty good at refactoring code to simplify it, which previously was a huge limitation.
Also, isn't the effort to create high-quality, standardized, and verified instructions for LLMs part of building an ecosystem that produces better code? That's one of the reasons I made https://github.com/planetis-m/skills public and free to use.
Thanks! These have been useful and helped generate more idiomatic Nim code that takes less work to fix up.
Obviously I'm expecting a big opposite reaction since a lot of people here like to "vibe code", but I can't really pretend that I'm fine with it, so I decided to just be blunt.
I believe much of this reaction is our field's reaction to change. Few people enjoy change, and us software devs can be surprisingly Luddite.
However I doubt software developer jobs are going away. In the US software dev jobs are already starting to rise again, slowly but steadily.
The ethical part I was mentioning was more about the environmental concerns caused by AIs, as well as the companies that profit from it. It is a separate issue from code quality and the like.
As the creator of the language, you're not concerned by an increase in low-quality contributions, pull requests, libraries, etc, that would make the language lose a good part of its community and growth? Even if you use it carefully, I doubt that the majority does, and there is definitely a problem of overconfidence in LLM-generated code from people who lack the technical knowledge to fix it. If producing "good looking" code is much, much easier than reviewing it, wouldn't that risk "clogging" pull requests for example?
The ethical part, "since the 'invention' of fire humankind has solved every problem by using more energy". To visualise that, take all tax incomes of the country you live in away and replace them by one single tax on energy, high enough to generate the same income. A part of Araq's cost.
Other ethical part, act and ask for forgiveness later. Read steal. Also never ask. Well there is one thing very interesting in (big) business, the lack of ethics. There's only one goal, make more profit now, regardless. (the main reason why you should never have business people run a country. Ethics is a number one priority there) Also costs, but more hidden.
It's a tool and you have to use it in a proper way. That can also be ethics, but its dealt with by politicians, who have no clue. It's a tool you have to learn to use in a meaning full way. As a woodworker, when I throw a piece of wood towards my table saw, I do not expect there suddenly is a chair. (I mainly use hand tools, the table saw is almost jobless) Abuse is cost. Abuse as a weapon is cost.
As you see I have power tools in my work shop. Yes I use LLM's. They are great for researching things by quickly prototyping ideas. "I" bolted SQLite on a little raytracer and it is amazing what you can do with the database in preparing a very large render and what you can do in post production. Rebuild the image from the database and change the colour of a light source.
Maybe it's not such a big deal. Code has a git repo. bad code can get improved if the overarching idea or goal is valuable, needed or just an exciting innovation to test and experiment with.
Since code can get improved with pull requests, or cloning it and enhancing it, at least i don't see it as such a big issue.
As the creator of the language, you're not concerned by an increase in low-quality contributions, pull requests, libraries, etc, that would make the language lose a good part of its community and growth? Even if you use it carefully, I doubt that the majority does, and there is definitely a problem of overconfidence in LLM-generated code from people who lack the technical knowledge to fix it. If producing "good looking" code is much, much easier than reviewing it, wouldn't that risk "clogging" pull requests for example?
No, I'm not concerned about that at all. This problem has many potential solutions:
The problem is also nothing new. Already does the PR queue tend to get longer and longer and it's hard to keep up. Already contributions are of questionable quality. Already ever merged PR implies code I didn't write myself, making the codebase harder to navigate. By comparison, AI PRs get better and better and tend to not randomly unrelated stuff...