生于反抗，或是为何业余编程社区抵制 LLM 的使用

生于反抗，或是为何业余编程社区抵制 LLM 的使用
Born Against, or why hobby programming communities are against LLM usage

原始链接: https://blog.fogus.me/llm/born-against.html

小众编程爱好者社区——例如那些致力于操作系统开发、模拟器制作和代码高尔夫的群体——对使用大语言模型（LLM）的态度日益抵触。尽管这些群体常因历史上存在的“把关”行为而受诟病，但他们对人工智能的抵制源于一种根本性的哲学分歧。在这些领域中，价值并不在于最终运行的软件，而在于掌握复杂领域知识那段艰苦且漫长的过程。从业者通过多年展现出的好奇心、分享优雅的代码以及展示深刻的见解来赢得尊重。在这些爱好者眼中，大语言模型被视为一种绕过学习过程的“作弊”行为。作者认为，虽然大语言模型可以作为专家强大的助力工具，但在这些社区中，它们却取代了技艺本身。通过自动化生成代码，大语言模型剥夺了开发者原本试图获取的经验。归根结底，这些小众群体将编程的“如何”与“为何”置于产出之上，并将人工智能驱动的捷径视为偏离了他们追求的本质。

近期 Hacker News 上关于“天生反感”（Born Against）的讨论，凸显了软件社区内部在大型语言模型（LLM）使用问题上日益加深的鸿沟。这场辩论的核心在于两种相互冲突的编程哲学： * **“工匠派”（钻研者）：** 对这些人来说，编程是一种爱好，也是一个自我精进的过程。他们看重像“数独”一样亲手解决问题和构建系统的挑战。对他们而言，LLM 是一种破坏性的力量，剥夺了工艺的乐趣，就像机器生产的餐食取代了厨师的劳动。他们担心随着“氛围编码”（vibe coding）成为常态，他们辛苦磨练的技能价值和社区标准会被稀释。 * **“结果导向派”（务实者）：** 许多开发者，尤其是那些专注于产出的人，将 LLM 视为强大的工具。它消除了繁琐的样板代码，使他们能够构建以往因时间和资源限制而无法实现的东西。他们认为，重点应该在于最终产品的实用性，而非过程的“手工”属性。这种紧张关系之所以持续存在，是因为 LLM 挑战了技术社区中固有的社会地位和准入门槛。虽然有些人预见未来仍会有“定制化”的手写代码，但另一些人则认为，由人工智能辅助的通用化开发是必然的前进方向。

Born Against, or why hobby programming communities are aggressively against LLM usage

I came across a GH thread related to chess engine development that made me think of why hobby programming communities are increasingly hostile toward LLM development. While the thread doesn’t give a lot of insight into answering the question, it prompted me to think about it a bit. I’ve seen similar sentiments expressed in other niche hobby programming communities like OSDev, LangDev, TxtDev, EmuDev, RLDev, the demoscene, and code golfers. The general consensus seems to be that the knowledge that these communities work in is hard-fought and the use of LLMs is a form of missing the point entirely. In these communities (keep in mind that there is an implicit “not all…” throughout) the process of mastering a difficult field itself is the product, and something that runs is generally a nice-to-have.

Further, I’ve noticed that even in the instances where there was earnest early engagement with LLMs in some of these niche communities, the well was quickly poisoned by a combination of a lack of a deep understanding by the LLM practitioners, and a vitriolic subset of those communities that view the LLM enterprise as a form of cheating. Granted these communities have, in general, historically been characterized by feverish gatekeeping and painstakingly slow progress, so it makes sense that there might be a desire to grab some easy cachet by bursting onto the scene like the Kool-Aid man. OH YEAH…. OH NO!

In traditional niche dev circles, respect is earned slowly through years of activity in their respective fora, sharing elegant code, displays of genuine curiosity, and through sharing deep domain knowledge along the way. At the end of the day, these communities don’t care if your code works at all, but instead care that you know why and how it works. To me, an LLM functions best as a force multiplier, not a surrogate. In the hands of an expert who already understands a domain deeply, it could act like a lever. But in these niche communities, the entire exercise is in the learning. Using an LLM to generate the finished piece doesn’t make us craftsmen; it just robs us of the craft.

:F

This is the latest in my evolving thoughts on LLMs. Also see: LLMe and Mind the van Emden Gap

生于反抗，或是为何业余编程社区抵制 LLM 的使用 Born Against, or why hobby programming communities are against LLM usage

生于反抗，或是为何业余编程社区抵制 LLM 的使用
Born Against, or why hobby programming communities are against LLM usage