告诉 HN:假装不使用 AI 让我成为了一个更好的开发者
5 分•作者: throwaway260803•3 天前
我工作在一个在线游戏开发社区,这里的文化是反对使用人工智能(AI)进行任何事情,包括编码。这个社区围绕一个开源游戏开发软件工具链以及其他用于分发、游玩、评审和讨论这些游戏的Web应用程序而建立。
过去,我曾向这个开发软件工具链提交过拉取请求(PR),但该工具链相当复杂(包含用多种编程语言编写的工具),我一直很难完全理解它,所以通常就不去尝试了。
到了2026年,我发现使用大型语言模型(LLM)来修复该工具链中的bug变得容易得多。LLM在切换编程语言、添加调试跟踪以追踪bug在各层之间的流动、生成自动化测试以重现bug,以及正确修复bug方面都毫无问题。
当然,问题就来了:我该如何说服团队合并一个包含完全由LLM生成的代码的PR,因为这明显违反了他们的政策?
我选择的答案是:我撒谎,说代码是我写的。
但是,为了让这个谎言“站得住脚”,我首先会让LLM详细解释bug修复过程,然后我会非常仔细地审查生成的代码(确保它的写法和我自己写的一模一样,尤其是注释),最后我会亲手编写所有的提交信息和PR描述。
我发现这是一种极具教育意义的方法。我学到了很多关于工具链中编程语言的知识,以及开源游戏开发工具的内部工作原理。在很多情况下,我更深入的理解让我能够真正地审查LLM的代码,发现生成代码中的问题,然后LLM会进行修复。
我确信,如果我只是点击一个按钮让LLM生成提交信息和PR描述,我永远不会发现这些问题。而且我显然也不会学到这么多东西。
我无法以自己的名义写下关于这件事的内容,但我现在真心推荐使用LLM来提交开源PR,但绝不要使用LLM来生成提交信息或PR描述。就好像是你自己写的代码一样,即使开源项目明确允许LLM生成的PR。
如果你对代码的理解不足以写出提交信息或PR描述,可以请LLM为你生成一个,但之后要用你自己的话从头开始重写。这部分是为了让描述不带有AI生成的痕迹,也是为了确保你充分理解代码的功能以及为什么这是正确的解决方案。
假装代码是我的代码,迫使我深入学习代码,直到我能够完全掌握它。我为我所做的撒谎感到羞愧,但我为通过这样做所学到的知识和取得的成就感到自豪。
查看原文
I work in an online game-development community where the culture is opposed to using AI for anything, even coding. The community is built around an open-source game-development software toolchain, as well as other web apps for distributing, playing, reviewing, and discussing those games.<p>I've filed PRs against the dev software toolchain in the past, but the toolchain is pretty complicated, (including tools written in multiple programming languages) and it's always been extremely difficult to wrap my head around it, so I usually didn't bother.<p>In 2026, it's been way, way easier for me to fix bugs in that toolchain using LLMs. LLMs have no problem switching between programming languages, adding debug tracing to trace the flow of a bug through each layer, generating automated tests to reproduce the bug, and then fixing the bug correctly.<p>Of course, the problem then is: how would I convince the team to merge a PR containing code that was entirely LLM generated, when that's explicitly against their policy?<p>The answer I've picked: I lie and say I wrote the code.<p>But, to <i>sell</i> the lie, I first ask the LLM to explain the bug fix in detail, then I review the generated code very carefully (making sure it's written exactly the way I would have written it, especially the comments), and then I write all commit messages and the PR description entirely by hand.<p>I've found this to be an tremendously educational approach. I've learned a <i>lot</i> about the programming languages in the toolchain, and about the inner workings of the open-source game-dev tools. In many cases, my deeper understanding has allowed me to <i>truly</i> review the LLM's code, finding problems in the generated code, which the LLM then fixes.<p>I'm certain that if I'd just clicked a button and had the LLM generate the commit message + PR description, I never would have found those issues. And I obviously would never have learned as much.<p>I can't write anything about this under my own name, but I now genuinely recommend using LLMs to file open-source PRs, but never using the LLM to generate commit messages or PR descriptions. Pretend as if you wrote the code yourself, even if the open-source project explicitly permits LLM-generated PRs.<p>If you don't understand the code well enough to write the commit message or the PR description, ask the LLM to generate one for you, but then rewrite it from scratch in your own terms. This is partly so the description doesn't have that smell of AI slop, but also to ensure you understand the code well enough to explain what it does and why this code is the right approach.<p>Pretending that the code is really my code forces me to learn the code well enough to own it. I'm ashamed of lying about what I've done, but I'm proud of what I've learned and accomplished by doing so.