有人说，“大语言模型或许很擅长写代码，但软件开发的难点从来都不在这里。”还有人说，“写代码很容易，真正困难的是弄清楚该写什么。”
如果你靠代码吃饭，听到这句话什么感受？
2026 年，信奉这种观点的人越来越多。最近一篇长文在开发者社区引爆争论，作者逐条反驳，直斥其为“对全世界程序员的严重侮辱”。评论区撕裂成两派，吵得不可开交。
与此同时，另一件事正在发生。Anthropic 准备让 Claude Code 默认启用 Auto Mode——AI 自主判断操作风险，不再事事请示人类，因为他们认为数据已经显示出“人类靠不住”。
一边是程序员的尊严之争。那篇长文之所以引发共鸣，是因为它戳中了许多人说不出的憋屈——写了十年代码，突然被人告知“你干的活儿不值钱”。另一边是 AI 正在接管人类决策的现实，趋势似乎不可阻挡。两件事同时发生，恰好是当下程序员处境最真实的写照。下面就是那篇引爆社区的长文，值得每个靠代码吃饭的人读一遍。
引爆争议的原文：
软件开发行业正经历一场剧烈变革。没有人知道这场 AI 革命最终将走向何方，但可以确定的是，它将改变工作与生活的许多方面，编程也不例外。
最近，我经常听到这样的说法：“大语言模型或许很擅长写代码，但软件开发的难点从来都不在写代码。”还有人说：“写代码很容易，真正困难的是弄清楚该写什么。”
在我看来，这种说法是对全世界程序员的严重侮辱。
写代码真的很容易？
如果写代码很容易，为什么程序员长期供不应求，多年来一直拿着高薪？为什么早在 AI 动辄生成数千行代码之前，程序员就已经承受着巨大的工作压力，长期加班，甚至陷入职业倦怠？为什么公司还要四处寻找所谓的“10 倍程序员”“编程忍者”和“明星工程师”，再用 LeetCode 式面试层层筛选？既然写代码这么容易，找个刚毕业的大学生来写不就行了吗？
如果写代码很容易，为什么我们会有《代码整洁之道》和《程序员修炼之道》这样厚得能拿来挡门的书？《计算机程序设计艺术》难道是适合暑假消遣的轻松读物？SICP 难道是一本摆在茶几上装饰门面的画册？为什么还有专门教编程的训练营，甚至整套大学学位课程？
如果写代码很容易，传奇程序员卡马克（John Carmack）的成就难道只是因为碰巧赶上了好时候、站在了合适的位置？我们为什么会把 Fabrice Bellard （因 FFmpeg、QEMU 等项目而闻名业内）视为天才？
如果写代码很容易，为什么人们会因为 AI 或其他人复制自己的代码而愤怒？既然这件事如此微不足道，他们为什么表现得像是为这些代码投入了汗水、灵魂和大量时间？
如果写代码很容易，为什么现在有那么多人觉得，自己的身份认同和职业意义正在被剥夺？
如果写代码很容易，为什么软件里还有这么多该死的 Bug？
如果弄清楚该做什么才是难点……
如果决定做什么才是最难的部分，为什么那么多产品经理看起来仍然一头雾水？为什么公司没有为他们设置严格的十轮面试？为什么他们的薪水没有超过开发者？
如果决定做什么才是最难的部分，为什么市场研究人员、可用性专家，甚至客户成功人员，没有被软件公司视为明星人才？如果“理解客户”更难，为什么业务分析师还常常被轻视为只会写文档、做表格的人？
如果实现功能很容易，找到真实需求更难，那么销售人员为了签下订单，擅自向客户承诺一项新功能时，程序员为什么还会生气？他们明明已经找到了一个真实存在、有人愿意付费的需求！
如果编程很容易，为什么大家不都做十个不同版本的程序，看看哪个效果最好呢？
根本不存在所谓的“典型程序员”
还有一句老生常谈的话：“软件开发的大部分工作，都是与利益相关方沟通、理解客户需求，以及明确工作优先级。”
在我的职业生涯中，我接触过许多程序员，其中很少有人愿意和利益相关方沟通，更不用说直接面对客户。自由职业者和创业者算是例外，尤其是软件开发公司的创始人。至于“明确工作优先级”，通常可以翻译成一句话：“直接告诉我该做什么，然后别每隔两天就变一次。”
有些软件开发者确实会说：“我不写代码，我解决客户的问题。”可一转身，他们又开始大谈单子、内存安全和 DRY 原则。他们对客户的理解来自一个凭空编出来的“用户画像”，甚至连 affordance（可供性）和 allowance（零花钱）都分不清，还以为前者是父母周末给你出去玩的零用钱。
还有一些人会说：“软件开发就是构建理论。”在他们看来，程序实际上是一种证明，这里指的是数学证明；每一次代码提交都应该讲述一个完整的故事；如果有人只是通过 FTP 上传一个 PHP 文件，就解决了客户的问题，那简直是大逆不道。
我并不是说，没有开发者能够既认真钻研软件开发这门手艺，又真正理解和共情客户。不过，这样的人或许应该找专业人士看看，自己是不是有点人格分裂。
究竟什么才重要？
我确实相信，与用户交谈、理解他们的真实体验、对他们抱有同理心、解决客户的问题，并让所有利益相关方达成共识，对软件项目能否成功至关重要。
我也相信，写出优秀的代码是一门手艺，需要技巧、耐心、对细节的关注、经验和智慧。即使在未来，这些能力依然重要。
为什么不能两者兼得？
只要条件允许，我们就应该同时追求二者：既要深入理解自己正在构建的系统，也要真正理解我们为什么要构建它。
高声宣称“写代码很容易”，或者走向另一个极端，坚称“代码是一门艺术，是无法被自动化的人类创造性表达”，都只是在逃避现实。
这只是一种自我安慰。靠自我安慰无法解决问题，我们真正需要的是在这场变化中找到自己的位置，并继续向前。
这并不意味着所有人都要立即追赶大语言模型的热潮，也不意味着每个程序员都要成为一支 AI Agent 大军的管理者。同样，我们也不必认定“AI 生成的代码都是偷来的低质垃圾，必须拼命抵制，反正泡沫迟早会破灭”。
但我们必须承认，整个行业正经历一场地壳运动般的巨变。我们需要找到适应它的方法，也需要弄清楚哪些东西可能发生改变，哪些东西始终不会改变。
什么不会改变？
软件将变得越来越复杂。软件永远需要维护：软件腐化是生活中无法回避的事实，熵增也是如此。无论结果是好是坏，技术——包括硬件和软件——都会继续向前发展。抽象层堆成的高塔，或者说摩天大楼，只会越建越高。
用户永远想要更多，同时又只愿意花更少的钱。他们仍然不知道该如何表达自己的需求和愿望。更糟糕的是，他们自己往往也不知道究竟想要什么。客户，也就是真正为软件付钱的人，与实际使用软件的用户之间，依然会存在脱节；企业自身的需求与客户需求之间，也会继续存在张力。
另外，兜售“蛇油”的骗子永远不会绝迹。时髦技术来来去去——我还在等着新一轮 VR 复兴呢！
什么会改变？
从一开始，程序员就在不断颠覆自己的行业。如今已经没人再用穿孔卡片了，需要使用汇编语言或 COBOL 编程的人也寥寥无几。在 Rust、Go、Python 和 JavaScript 盛行的时代，那些用几十年时间与 C 或 C++ 内存错误搏斗、身上留下累累伤痕的经历，已经变得毫无价值。
我的年纪已经大到足以体会 Valgrind 的可贵，也还记得 PHP 4 时代的 mysql_real_escape_string()。这些东西，我这辈子大概再也用不上了。而那段历史其实并没有过去多久！
我入行稍晚，刚好错过了 dBase、Clipper、HyperCard 和 Access 盛行的年代。不过现在，偶尔仍能在商店或咖啡馆里看到这些老技术继续运行：一台落满灰尘的中塔式电脑机箱，原本是米白色，如今已经泛成黄褐色，却还在愉快地运行着某套定制的商业系统。
我们怎样才能过得更好？
接受变化必然会发生。面对新事物，既要保持好奇，也要保持批判性。
要明白，这其中存在大量炒作，并努力分清哪些只是空话，哪些东西确实有效，以及究竟能发挥多大作用。还要意识到，衡量技术进步的标准一直在变化。不妨退后一步，回顾过去一年甚至五年，看看技术、经济和社会究竟以多快的速度发生了改变。
你的角色和职责一定会随之变化。你需要愿意投入时间和精力，主动了解与你的专业相邻的领域和岗位。
如果你是一名资深开发者，不要只靠继续钻研技术来寻找安全感。可以去了解用户体验、客户访谈，以及所在行业中企业的商业战略。这会帮助你更全面地理解，一款软件从构想到最终交到用户手中，背后究竟需要完成多少工作，无论你以后是否需要亲自参与这些环节。
如果你刚刚入行，或者目前还是初级开发者，就应该进一步理解软件究竟是如何运行的。即使你写的是 JavaScript，理解指针、递归和内存层次结构也会有所帮助；即使你只是在开发 WordPress 插件，理解网络协议和 HTTP 的工作原理也同样有用。哪怕眼下用不上，也可以做一做 LeetCode，学习算法和数据结构。不要害怕追问“为什么”，也不要害怕继续追问“具体是怎样实现的”。
下面这些书籍和资源或许能给你带来一些启发：《计算机程序的构造和解释》、《程序员面试金典》、《人月神话》、《逆向工作法》、《团队拓扑》、《7 Powers》、《新机器的灵魂》、《Obviously Awesome》、《设计心理学》、《点石成金：访客至上的网页设计秘笈》、《持续发现习惯》以及《The Mom Test》。
最后再说一件事：无论你是谁，都不要把自己的理解力、判断力、同理心和品位外包给 AI。不要放弃自己应负的责任，也不要沦为 AI 的人肉代理。
争议与回响
这篇文章发布后，很快在 Hacker News 评论区引发激烈争论。支持者和反对者分成两派，帖子也被一路顶上热榜第一。到了 X 上，共鸣的声音则明显更多。
机器人开发者 Davide Faconti 写道：
终于有人把这句话说出来了。我觉得，那些声称“代码从来都不是难点”的人简直失去了理智，要么就是故意说这种话来激怒所有程序员。
推荐系统与搜索领域的创始机器学习工程师 Vicki Boykis 也表示：
谢谢你写出这篇文章。成为一名优秀的程序员，确实还需要具备许多代码之外的能力，但即使只是把代码写好，也从来都不容易。
数字营销从业者 Martin Baar 则用数学作类比：
写代码之所以难，就像数学之所以难一样。你可能理解所有数学概念，却依然解不好方程；你也可能掌握了设计一款优秀应用所需的全部知识，真正动手写代码时却仍然一塌糊涂。
不过，也有人赞成“写代码很容易”。
一位做过多年前端开发的 Hacker News 用户表示，过去 90% 的工作都谈不上代码有多难，大多数时候只是把网络功能连接到已有的 UI 元素上。真正令他感兴趣的是编写 GPU 着色器和优化可视化性能。
如今他转向 GPU 和内核编程，AI 在这些复杂任务上也开始超过他。但他认为，了解论文中的前沿算法、判断内存带宽瓶颈等专业知识，依然决定着人能否有效驾驭 AI。
评论区里最精彩的一条回复，来自拥有近 40 年编程经验的 Hacker News 用户 michaelrpeskin。他认为，LLM 出现后，编程或许真的不再是最难的部分。
他举了一个亲身经历的例子。自己维护着一套 25 年前编写的金融系统核心算法，每晚负责处理机构间数十亿美元的资金流转。代码从 FORTRAN 77 转成 C 语言，只有十来屏，却充斥着 goto、复杂分支和二十多个并行数组，运行极快，人却几乎无法读懂。
这套系统要解决的实际问题，用三句话就能概括，但由于上下文管理极其复杂，真正写出来非常困难。因此，客户宁愿长期支付授权费，也不愿自行开发。可到了今天，他认为 LLM 或许已经能够从头写出同样的系统。
在 michaelrpeskin 看来，过去编码的一大难点，来自两种理念之间的矛盾：一方面，开发者希望提前进行全面设计，为未来可能出现的需求做好准备；另一方面，又不能过度设计，更不该编写“以后可能用得上”的代码。
敏捷开发和 YAGNI 原则（不要提前实现尚未明确需要的功能）由此流行起来，把复杂项目拆解成一个个用户故事。在这种框架下，编码看起来简单了许多，开发者只需按照当前的用户故事实现功能。但新的问题随之出现：当需求继续变化，开发者又不得不回过头去重构昨天那个用户故事遗留下来的代码。
“我认为，这正是现在大家哀叹不已的原因：优秀的工程师不再被需要了。
现在，我可以直接让 LLM 编写代码。随着需求越来越复杂，它也会很乐意地不断重构代码，并替我管理上下文。因此，我们无须再担心代码是否‘整洁’，也无须再纠结所谓的‘代码质量’。只要 LLM 写出的代码符合规范，我们就满意了。
我觉得，编程真正的‘难点’一直在于管理上下文，而我们需要管理的上下文本身也在不断变化。擅长管理上下文的人，会擅长使用 LLM 编程；不擅长管理上下文的人，依然不会。”
然而，放权给 AI 已成大势所趋？
michaelrpeskin 的争议点是人类程序员是否擅长上下文管理，但实际上 Claude Code 已经又向前走了一步：就连 Agent 执行哪些命令可以放行、哪些命令需要阻止，也开始交由模型判断。
Anthropic 宣布，从 8 月 14 日起，Auto Mode 将成为 Claude Code 面向 Pro、Max 和 Team 用户的默认权限模式。Enterprise 用户、API 及云平台目前仍需手动开启，预计未来一个月内逐步扩大默认范围。
Anthropic 研究数据显示，Claude Code 用户目前会批准 97% 的权限请求。在另一项覆盖 1000 多名测试者的实验中，测试者只能识别出 13.6% 的危险命令，Auto Mode 却能识别出 89%。随着权限提示不断增加，测试者的判断能力还会快速下降：连续处理 50 次请求后，他们只能发现其中 5% 的危险命令。
Anthropic 认为，减少权限提示反而能让开发者更审慎地对待真正需要人工介入的操作。Auto Mode 下，一旦分类器判定某条命令危险，系统会直接阻止执行，Claude 可转而寻求更安全的替代方案，或回到用户处请求明确授权。若某项操作连续被阻止三次，或单次会话内累计被阻止二十次，系统会自动退出 Auto Mode，恢复手动审批。
Auto Mode 成为默认模式，标志着 Coding Agent 使用方式的转变。当 Agent 连续工作数小时，开发者已不可能守在屏幕前逐一批准每条命令。过去，Agent 负责生成代码，开发者负责逐行检查和批准；如今，连“哪些操作值得开发者关注”也开始由另一个模型筛选。
这让“写代码到底难不难”的争论又推进了一步。过去，人们至少还相信，AI 可以负责执行，人类负责监督和把关；Auto Mode 却说明，随着 Agent 执行的任务越来越长，就连监督也不可能覆盖每一个步骤。人类不会彻底退出开发流程，但介入的位置正在不断后移：逐渐从编写代码、检查代码和批准操作，转向定义目标、划定边界、处理异常并承担最终责任。
说“写代码很容易”，是对数百万开发者日复一日打磨手艺的轻慢；但把头埋进沙子里，假装一切如常，同样无济于事。真正的尊严，不在于捍卫某个固定岗位，而在于承认变化已然发生，然后主动去重新定义：在 AI 写代码的世界里，程序员还能创造什么不可替代的价值？
写代码或许真的变容易了，但写出对的代码，从来都不容易。
参考链接：
https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers
