Chris Kiehl：让 AI 做软件，不必让自己放弃编程的乐趣

Chris Kiehl 在 10 月 17 日的文章里谈到一种压力：当模型能很快产出程序，亲手写一个小东西似乎也需要证明效率。他承认工作的商业逻辑已经变化，却不接受把生活里的所有活动都按交付速度评价。自己慢慢写一个有 bug 的打砖块游戏，仍然可以令人快乐，即使模型一次就能生成类似作品。

这种快乐也包括没有立即用途的求知。他折腾 Java 类型、Agda 和递归模式，困难不一定马上变成产品价值，理解可能要过很久才派上用场。文章不是拒绝 AI：他在脚注里也说，喜欢让模型做出一些自己完全不读代码的小应用。因此他的主张更接近允许不同目标并存，而不是为某一种工具使用方式划定道德高低。

HN 评论补上了工作场景的痛点。esafak 认为，爱好当然可以继续，但许多人担心的是有报酬的工作失去乐趣；kentm 则说，工作原本就有负面部分，只是正面的创造体验曾经抵消它。若自动化先拿走这些正面部分，留下检查和杂务，问题就不只是下班后找个爱好。

可信度 65 · 重要性 85 · 新颖度 78

技术与主题

个人随笔；正文和脚注分别说明手写编程与模型制作应用都能带来乐趣。

忠实转述（非原句）：他喜欢慢慢理解一些暂时不知道用途的概念，也喜欢用模型快速做不打算读源码的应用。外部关于效率的声音不应替他决定什么活动值得享受。

回应原帖：原帖讨论

HN 同文讨论，区分自由选择的爱好与付费工作。

忠实转述（非原句）：他认为继续业余编程并没有争议；更难处理的是，有人不再享受自己赖以谋生的那份工作。把问题移到下班之后，无法完全回应这种担忧。

回应原帖：原帖讨论

HN 评论者对工作体验的解释，并非就业调查。

忠实转述（非原句）：他并不认为过去工作只有快乐，而是说过去的正面体验能够抵消烦恼；如果工具拿走正面部分，原有杂务仍在，一部分人就会觉得这份工作不再值得。

这篇文章提供了一种区分：交付一个可用软件、理解一个困难概念、享受亲手构造的过程，可以是不同目标。选择让模型代写还是自己动手，应先知道此刻要得到什么。只比较完成时间，无法替喜欢学习的人回答“这次过程是否值得”。

评论中的不同意见也让讨论更完整。作者能够选择业余活动，并不意味着受雇开发者能自行决定工作如何分配。如果团队只看产出，却把人的任务逐步收缩成审查机器生成内容，满足感下降可能影响学习、主动性与留任。这是值得调查的机制，不是这些评论已经证明的普遍趋势。

对个人，保留一块可以慢慢理解和试错的工作有实际意义；对团队，则可以问成员希望保留哪些设计与实现责任，再观察工具引入后任务结构怎样变化。文章和评论提供的是具体声音，不能据此推断所有程序员讨厌 AI，也不必强迫每一种兴趣证明经济回报。