It’s fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.
Using LLMs for assistance is fine, but any non-trivial contributions (code, comments, documentation, review etc.) are expected to originate from a human.
I really like this approach. It enables the use of LLMs but protects everyone else (especially reviewers) from the burdens associated with that (such as having to parse excessive LLM-written text).
When I contribute to the Crystal language, I usually use LLMs to write the first draft of my pull requests. For this reason, I do not want a complete ban on LLM-generated code.
In the past one or two weeks, several very powerful AI models from China have been released. Kimi K3 and Qwen3.8-Max are two examples. At the same time, mid-level models with surprisingly low prices have also appeared. DeepSeek V4 Flash 0731 is one of them.
I tested these models myself. I used OpenRouter together with GitHub Codespaces, and I also used Perplexity. In my tests, Kimi K3 was still not as capable as ChatGPT or Codex, and it had no clear advantage in cost. However, Kimi was willing to help with computational biology research. Claude is known for limiting its capabilities in this area. I think this difference is worth noting.
The model that impressed me most was Xiaomi’s MiMo. Its price is surprisingly low, and it can keep working on a task for a long time. The model itself is not very powerful. Even so, the final output was better than I expected.
Until now, most discussions about AI-generated code have assumed a choice among three services: Claude, Codex, or Gemini. That assumption is now starting to change. I am watching to see how this change will affect the debate about AI and open source, or whether it will affect it at all.
@kojix2 I believe the most important thing here is to understand what you are doing.
I see it in this way:
you can use AI to help you to understand the issue and to propose a solution to you (see, to you)
then, when you finally understand the scenario, it is your responsibility to create the final solution (code, comments, PR), since fully understanding it is the minimum
If you write the PR yourself and use AI to translate it, sure, no problem.
But when someone doesn’t understand the problem enough and leave the responsibility to AI to handle the final proposal (code, comment, PR) you may leave a burden over the maintainers to decypher the AI work that should be understood by the proposer.
What I personally understand is that you are responsible for what you deliver.
And delivering in a concise, human-written code, comments and PR means:
you understand what you are doing
you show respect for the maintainers by delivering it in an understandable way
AI should be a tool to help you in the process, sure, but not to replace the responsibility to fully understand what is being created.
The problem the Rust developers were having is that they were receiving thousands of bug reports and proposed solutions that were AI-generated. A lot of them were not even actual bugs. AI currently only has the capacity for a limited amount of context, and without being able to trace an entire codebase, there can be issues that look like bugs but are actually intentional behavior or misunderstandings. The Rust team does not have the resources to go through all of those reports, so they put policies in place to slow the process down.
I think a lot of people are very sensitive and can become defensive about AI because of the community’s initial knee-jerk reaction. However, any project that outright dismisses AI as a valuable tool is making a mistake. FreeBSD experienced this firsthand when AI helped identify a number of valid security flaws. Nobody wants to be the person who speaks negatively about a technology only to look foolish later when it proves useful.
I think this is a very reasonable minimum AI policy.
You let grammar checker and spell checker show you mistakes in your writing, and maybe suggest fixes.
But you write the text and are responsible for it.
The same should be the situation for programming languages.
You can have the LLM show you mistakes or suggest ways to phrase your intent, but you write the code and more importantly, you are responsible for it.
Generated code will never be as 100% understood by you compared to what you write yourself. And we all know how tiny changes can make a huge difference.
Yes, LLMs are good at finding bugs. Exactly in the same way LLMs are good at finding spelling errors or grammar mistakes. because that is what they are designed for: Comparative statistical analysis of structured text.
Everything else we currently use them for is madness. like using handgrenades to aerate your lawn. Yes, it works. but there HAS to be a better tool. (there is, don’t use handgrenades to aerate your lawn.)
AI currently only has the capacity for a limited amount of context, and without being able to trace an entire codebase, there can be issues that look like bugs but are actually intentional behavior or misunderstandings.
The same is true of a human being: at any given moment you only hold a limited slice of a system in your head, and without being able to trace through its full logic, you can mistake for a bug what is in fact intentional behavior or a misunderstanding on your part.
Since this topic is getting attention, I’ll share more of my personal opinion.
Over the past year, I’ve made a few small contributions to Crystal. I picked random neglected issues and solved them with LLMs. I was glad that with the help of LLMs, I could contribute even without deep compiler knowledge.
One part of the Rust policy is worth noting:
Most of the work of reviewing is not simply catching bugs. A great deal of it is deciding whether this direction is a good approach, whether the PR is a good idea at all. In other words, reviewing is made of decisions.
but from our perspective, the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those.
I’ve come to understand that long-stalled Crystal issues often exist at the boundaries of language semantics where consensus has not been reached. They appear to be bugs. But resolving them requires a decision based on community consensus about what kind of language Crystal should be. Crystal is a large project, and once you commit to a behavior, it must be maintained for a long time. Such decisions carry responsibility and psychological cost.
When the conversation turns to AI, we tend to lose our ability to think freely. Our emotions get tangled. Pride in the coding skills we have spent much of our lives building. Anxiety about our jobs. But if we set those aside, I think it’s somewhat arrogant to believe that humans in 2026 are still better than LLMs at “coding ability.”
But I don’t think that’s really the problem.
How do we reach community consensus on what kind of language Crystal should become? This is unrelated to LLMs. Each of us has our own taste, and we discuss what design is preferable. But this is not easy. This is the important point, yet attention focuses on LLM capabilities and the real challenge is overlooked. At least, that’s how I see it.
It’s great that LLMs empower you to help resolve such issues.
But suggesting changes without understanding them, is a problem for quality control.
The compiler is a complex piece of software and any change at one point can have unintended effects in an entirely different place. Of course it’s impossible to take everything into account. Neither a human nor an LLM can do that.
But a human can reason about a change. An LLM cannot. It does not understand what it’s doing. It just finds a patch that produces the intended change. That can be a fix for the actual problem in the correct way, but it might just be treating a symptom. Or anything in between.
Deciphering that requires a human understanding.
If you just act as meat proxy for an LLM, you shift the work of figuring all this out to the reviewers of your PR.
For trivial fixes, this might be acceptable. But then it probably shouldn’t take an LLM to write the patch in the first place
I like this policy. LLM-generated code can be such a double-edged sword. In theory, LLMs help human engineers write code faster. I get it, I get lazy or overwhelmed or just not in the mood to write the code I know I need to write. My time and energy are limited and occasionally I tell one AI tool or another (some of which I’ve written myself) to make the changes for me[1]. My day job requires a nonzero amount of this. So I get it, it’s great in theory.
In practice, though, I’ve seen far too many engineers outsourcing not just the writing of the code, but also 100% of the thinking. I’ve reviewed too many PRs where questions like “Why did you go with this approach?” were answered with “I dunno, the AI did it.” And that’s just plain disrespectful to the reviewer. Maybe folks in this thread don’t do things like that. And that’s great, that means this critique isn’t about you. But even a few people doing it can be a drain on a reviewer’s energy.
Now, there’s a huge gulf in effort between a prompt that says “implement this exact solution” and one that says “solve this problem”. In one, you’ve put some thought into the problem, possibly weighed multiple solutions, and chosen one to go through with. In the other, you’ve avoided putting more than token effort in (pun fully intended). And those two situations can be indistinguishable. Some folks will claim the implementation is their own solution when their prompt could simply have been “implement issue #X”.
And because they’re indistinguishable, some might think the little-to-no-effort approach is good, actually. I mean, if you can’t tell I didn’t put effort into it, it must be good enough, right? But it goes the other way IMO, where guiding the model through with my own very specific chosen solution and trying to do AI-generated code the “right” way still just looks like slop to a reviewer.
With a policy in place like the one proposed, if something seems like slop to the maintainers, they have a very clear boundary where the distinction between “AI-assisted” and pure slop simply doesn’t matter. Both are treated the same way because it’s just not worth having the same argument on 65 separate PRs about whether this use of AI is the good one or the bad one. It shuts that argument down entirely.
I clearly have no problem writing a lot of words and getting very specific with them. ↩︎
