背景：AI 时代流行的一句话
随着大模型席卷软件行业，一种论调越来越常见：「LLM 可能很会写代码，但软件从来不是难的部分」「写代码很容易，难的是弄清楚该写什么」。这篇来自 senko.net 的博客文章认为，这类说法是对全体程序员的严重冒犯，在 Hacker News 上引发了 345 条评论的热烈争论（526 分）。
核心观点：如果写代码容易，如何解释这些现象？
作者用一连串反问拆解「写代码容易」的论调：如果写代码真的容易，为什么程序员多年来一直供不应求、薪酬高昂（甚至在经济繁荣之前）？为什么在 AI 出现之前就有那么多压力、过劳和职业倦怠？为什么公司追逐「10倍天才程序员」、用 LeetCode 面试筛选候选人？如果刚毕业的初级工程师就能轻松产出，何必如此？
如果写代码容易，为什么会有《代码整洁之道》《程序员修炼之道》这类经典？《计算机程序设计艺术》是轻松的夏日读物吗？SICP 是咖啡桌书吗？为什么会有编程训练营、甚至整门大学学位？如果写代码容易，为什么 John Carmack 被奉为传奇、Fabrice Bellard 被视为天才？为什么人们会对 AI 抄袭自己的代码感到愤怒——仿佛把心血倾注在无足轻重的事情上？以及最尖锐的一问：如果写代码容易，为什么软件还是这么 Bug 缠身？
反过来：如果「搞清楚做什么」才是难的部分……
作者同样驳斥了另一面。如果决定做什么才是难点，为什么产品经理看起来如此平庸？为什么没有为他们设立严格的 10 轮面试？为什么市场研究员、可用性专家、客户成功人员没有被当作摇滚明星？如果理解客户更难，为什么业务分析师被看作「表格填手」？如果实现很容易、发现需求更难，为什么销售为签单向客户承诺新功能时，程序员会大为不满——他们可是找到了真正的付费需求啊？
技术分析：没有「中位数程序员」，写代码本就是一门手艺
作者指出，另一种流行说法是「软件开发的大部分工作是跟利益相关者沟通、理解客户需求、明确优先级」。但现实中，极少有程序员喜欢跟利益相关者打交道，「明确优先级」在多数人那里就是「告诉我做什么，别每两天变一次」。一些开发者自称「我不写代码，我解决客户问题」，转头却大谈 monad、内存安全、DRY 原则——他们对客户的理解不过是虚构的「用户画像」。
作者的结论是两者都要：既要有对「构建什么」的深刻理解，也要有对「如何构建」的精湛手艺。大声宣称「代码很简单」或者相反的「代码是无法自动化的艺术」，都是把头埋进沙子里。真正不变的事实是：软件会越来越复杂，维护永远存在，位腐烂（bit-rot）和熵是常态，抽象之塔越建越高；而程序员这个职业从诞生起就在颠覆自己的行业——打孔卡、汇编、COBOL、C/C++ 内存大战，都已成为历史。适应之道是保持好奇与批判、投资理解相邻领域（UX、客户访谈、商业策略），同时扎实掌握底层知识（指针、递归、内存层次、网络协议）。
社区反响
HN 评论呈现多元立场。有人赞同：「试试读一个大型 C 代码库再说」；有评论区分了「建造者」（把产品交付出来、视代码为麻烦的中间步骤）与「工程师」（视编程本身为事业）两类人；也有人引用 Lamport 的说法：「把你的想法编码成编程语言很容易，难的是意识到你的想法是坏的」——写代码不等于编程。还有人一针见血：「这句话恰恰来自程序员自己，经理和高管从不说这话，这是程序员在侮辱自己」。反方则认为：「写代码不再难了，难度降到了厨师级别」，或者「代码难不难取决于你是谁——对 John Carmack 来说，代码就是最难的部分」。争论本身折射出 AI 冲击下程序员身份认同的普遍焦虑。
原文：“Code was never the hard part” is an insult to all programmers
HN 讨论：news.ycombinator.com/item?id=49222189