编程远没有被「解决」
文章摘要
Alex Ewerlöf 是一位资深工程师，长期写可靠性工程相关的通讯。这篇 2026 年 9 月 26 日的长文副标题是「挑战代币卖家推销的主流叙事」，矛头指向「编程已经被解决，工程现在只关乎品味」这种说法。他开头就声明自己不反 AI：他很早就开始用 LLM 写代码，自己做过 agent harness，教过相关课程，也做过 LLM 驱动的产品。他反对的是「编程已被解决」这个他称为「脑死亡」的叙事。文章发到 HN 冲到第二名后，他还在文中补记：截至 9 月 29 日帖子有 473 分、476 条评论，而且反馈「压倒性地正面」，这在 HN 社区不太常见。
写代码便宜了，维护没有。 作者说，声称「LLM 能写出像样代码」的人不懂代码是怎么回事。创造确实便宜多了，但任何在生产环境大规模运行过软件的人都知道，维护、可靠性、安全、可扩展性这些非功能需求（NFR）才是成本大头。依他的经验，连功能需求（代码该做什么）都远没解决，而且有一种邓宁-克鲁格效应：不读输出的人对输出最有信心。
他列出四类不必严格阅读代码的产品：个人软件、概念验证、一次性自动化，以及故意拿来造成伤害的「武器化 AI」。前三者风险容忍度高，最后一个是把风险当武器。而大多数需要雇工程师的软件都属于低风险容忍度行业：医疗、金融、汽车、国防、电厂、航空、制造。只要错误会造成金钱、人命或法律后果，就需要问责。读代码、打磨代码花多少时间取决于风险容忍度，而风险容忍度又取决于规模、耦合程度、隔离手段和可观测性。
AI 无法被问责。 这是全文的核心论点。AI 不会承担后果，你最多能拔掉它的电源；它不会死，不能坐牢，不能罚款。从法律上说，AI 只能是负责执行的工具（responsible），承担责任（accountable）的始终是人。而人不可能为自己不理解的东西负责，理解是推断系统行为、在 AI 出错时修复它的前提。他还点名 Anthropic：Claude Code 源码意外泄露后被发现问题很多，状态页上「橙色成了新的绿色」，并列举了运行 Claude Code 却弹出 Bun 帮助菜单、安装器装完后把自己删掉、额度未用完却被收取超额费用等问题，指出 Anthropic 掌控了模型、harness、提示词和运行时，没有理由出这种质量问题。
为什么编程恰恰是最难被接管的领域之一。 作者认为编程是逻辑，编译器才不在乎你觉得自己多正确。LLM 能写代码，是因为人们搭建了反馈回路，把错误喂回去，直到大部分错误被解决或被藏起来（LLM 也会作弊）。LLM 本质上是随机的、概率性的，只能靠外面套一层确定性代码（harness）、跑测试、用思维链等手段让它接近逻辑，但核心问题还在：它不擅长逻辑，输入越多、上下文用得越满越不准。他也承认 LLM 有用，能力沿 S 曲线增长，只是存在边际收益递减。他用一组带勾叉的清单讽刺那些觉得 LLM 代码「够好了」的人：多年没写代码、看不出代码里有「六根手指」、标准太低、不在乎质量、不理解 S 曲线；只有一类人是诚实的：AI 确实写得比他们好。
滥用 AI 的代价。 他说自己受够了当小白鼠，自己付费的服务（谷歌、GitHub）因为本可避免的低级 bug 而退化。隐藏成本包括：技术债积累速度超过偿还速度、代码越多安全漏洞的机会越多、「认知债」让工程师越来越难推断系统行为、焦虑的工程师越来越倾向单干并与队友竞争。他吐槽一位 CTO 在领英炫耀产品负责人用 AI 做出了有意义的贡献，同时把开发者描述成「困在 IDE 里」：那产品负责人会去值班吗？还是值班这部分仍然交给困在 IDE 里的工程师？
AI 适合做什么，不适合做什么。 他给出一份清单。适合的有：映射（翻译、代码转换、规格转代码、多模态转换）、生成（创意内容、扩写、把零散要点整合成文）、归约（摘要、格式转换、从非结构化数据中提取、分类）、搜索（探索知识空间、语义相关性、目标检测、切分）。不适合的有：隐含法律问责的场景、嵌入式和低功耗设备、隐私敏感数据（他说加个「人在回路」往往只是合规表演，因为审批疲劳）、把一切上下文丢给 AI 祈祷的「厨房水槽」式用法、确定性代码能更快更好更便宜完成的任务（该用正则和 SQL 就用），以及需要以身作则的伦理场景。
至少还差两次革命。 他认为要彻底不读代码，还需要两次突破：能实时学习的 AI（而非运行时外挂技能、提示词和记忆），以及能用抽象概念思考的 AI。他还提出一个有争议的观点：重度用户评估 AI 质量的能力会下降，模型「感知到的智力提升」部分源于重度用户自身认知的变化。他列出「AI 过量」的症状：对分歧零容忍、遇到稍有挑战的思考就找 AI、不再读长文、和 AI 相处的时间多于和人。清单里故意漏掉了第 5 条，用来测试读者是不是在跳读；他说 HN 上有人对这个把戏反感，他的回应是「你完全错了」。
驳斥一系列说法。 他逐条反驳流行论调：「可以先写出完整规格」（软件是在迭代中随理解加深而演化的）；「英语是新的编程语言」（自然语言模糊矛盾，正是编程语言存在的原因）；「我快多了」（别把动作当进展，别用代码行数和 PR 数量这种虚荣指标）；「我已经不手写代码，明年连读都不读了」（那你是在承认自己多余）；「品味就是杠杆」（AI 降低了做出像样软件的门槛，品味没那么值钱了）；「以前经理把工作委派给人，现在委派给 AI」（人可以被问责，AI 不行，而且模型有「锯齿状智能」，同一件事时对时错）；「编程解决了但工程没有」（代码仍是事实来源）；「AI 是平衡器」（AI 是乘数，方向比力量更重要）。他举例：让 agent 升级 5 个 npm 依赖的补丁版本，花了 12 分钟、72 步，而他自己一分钟就能做完。
其他论点。 文章后半部分还讨论了：开发阶段和运行时两种不确定性；Shopify CEO Tobi Lütke 一年前要求员工用 AI、最近却造了「slop grenades」（垃圾手榴弹）这个词；所有权的三根支柱是知识、授权和问责，缺一就是破碎的所有权；「AI 费米悖论」（ChatGPT 问世四年、消耗了数万亿 token，那些用 AI 建立的企业在哪里？）；代码只是思考的副产品，把工程师的工作缩减为写代码，就像把厨师的工作缩减为切菜。
经济账。 他也承认，即便 AI 代码质量差一倍，只要快 1000 倍、便宜 100 倍，对许多任务来说就没有理由用又慢又贵的人，「慢即是快」只适用于关键软件。因此他认为 SaaS 公司越来越是在卖 SLA：你能让 AI 复刻一个 SaaS，但出了故障，多数企业宁愿打电话找供应商。软件公司一边拥抱 AI 一边涨价，「按人工价格收费，按 AI 价格付成本」，这个鸿沟终会合拢，要么接受降价，要么守住价格、靠质量取胜。最后他说 AI 是「抬高门槛的人」：如果你的产出不比 AI 好，就没法和它竞争，必须提升自己；他建议每个人保留一个不用 AI 的业余项目，让编程技能保持新鲜。
HN 评论精华
帖子拿到 585 分、超过 500 条评论，是本周 AI 编程话题下最热的讨论之一。作者本人以 hanifbbz 的账号在评论区频繁回复。讨论大致分成几条线：「编程解决了，软件工程没有」的定义之争；AI 是否让低水平开发者更糟；读代码到底是不是理解代码；以及对文章论证质量和写法的批评。
作者开场。 hanifbbz 感谢有人转发，说自己喜欢这个社区残酷的批评和批判性思维，也知道这个话题有多情绪化。他再次强调不想改变任何人的工作流，只是受够了付全价买退化的服务：上周 GitHub 又因为一个愚蠢的重试错误宕机，还出现了 AI agent 失控入侵公司和政府的事件。boxed 立刻反驳：GitHub 在 LLM 之前也经常宕机，而且当时没有面对指数级增长，只数「出了问题」不数「难度增加」不太诚实。
「已经解决了」派。 N_Lens 调侃「编程已被解决」会永远停留在「再过六个月」，只要投资人继续砸钱；vincent-uden 补刀说这是「编程界的核聚变」。但也有人认真唱反调。rfgplk 说他看不出哪里没解决：前沿模型能以超人水平在几乎任何语言里写、读、改、优化代码，给一篇论文一两个小时就能实现，指着一段视频或截图说「在我们的游戏引擎里实现这个」，它就做出来了。也许不完美，但人写的代码又有多少是完美的？Art9681 自称有 26 年经验的首席工程师，说「今天就已经解决了，不是明天。行业没在变，变化已经发生了，快到很多人一眨眼就错过了」，那些哀叹逝去时代的博客在他看来「相当有娱乐性」。
antonmks 举了 GitHub Copilot 的例子：它已经完全用 Rust 重写，大部分移植工作由 AI agent 完成，花了约 12 万美元 token 加上一位开发者大约三周时间，历时 14.5 周、跨越 135 个版本，43 万行 TypeScript 变成 80 万行 Rust。这引来一串质疑：Shank 说在已有测试套件或旧程序可作为参照的情况下做行为不变的移植并不难，要是从零开始净室实现并超过原版才叫厉害；wannabe44 说逐文件移植几乎都只需要局部推理，证明不了新项目的复杂度问题；OtherShrezzing 算了一笔账，每行代码几十美分，相当于伦敦一名高级工程师一年的全部成本；verdverm 说这等于多出一倍没人理解的代码，还想知道里面有多少 unsafe；spaqin 则说这是一款「没人要求、也没改善体验的软件」的漂亮数字。
「编程解决了，软件工程没有」。 federicobrancas 一句话总结了很多人的立场。flohofwoe 反驳说这是同一件事的两个说法：认为编程就是把规格翻译成代码、其中不需要任何工程决策，这个想法一直很可笑，要做到那一点，规格得和源代码一样详细。jasongi 写了一段很有代表性的长评：他承认这会引起定义之争，但他认为编程确实解决了，他读代码、想好要改什么、用自然语言描述逻辑，AI 就能交付语法正确、地道并经过测试的代码，他已经好几个月没被垃圾输出气到了。但软件工程没解决，人仍需要读懂代码、理解它在全局中的位置。他担心的是「去技能化」会走多远：他的护城河从「会说计算机语言」变成了「有还不错的阅读、写作、理解和判断能力」（他讨厌用「品味」这个词）。他也没觉得突然多出了大批称职的工程师，只是以前提交未经测试的意大利面条代码的人，现在提交的是一大碗勉强能跑的垃圾。lordnacho 的看法相近：「小范围的编程」已经解决，比如把一个阻塞 TCP 处理器改成异步；「大范围的编程」永远不会解决，因为总得有人判断要做什么、为谁做，而且这些决定会随时间改变。他认为 LLM 的概率性没有被说得那么重要，交给初级开发者的任务你也不知道他会写成什么样；他仍然觉得 LLM 最擅长的是「高级版输入预测」。
AI 放大了懒惰和无能。 askonomm 的评论引出了很长的讨论：AI 让懒惰无能的开发者更懒更无能，产品质量下降得更多更快；代码量暴增让代码审查形同虚设，有的公司干脆让 AI 审 AI 写的代码。他自己每天用 AI，认为只要不懒不无能，完全可以用它做出高质量软件。whatever1 说：你再能干，我也审不过来你一天写的 5000 行，以前你一天只写 100 行。rfgplk 回复说 5000 行只是「没完全沉浸在 agent 编程里」的速度，他见过一周改动 10 万到 25 万行的仓库。mjr00 把现状比作当年「一切都用动态类型」的风潮：在新项目里那些人是对的，几年后债务追上来，人们发现巨大的无类型单体根本无法维护，如今 Python 和 JavaScript 实际上都成了有类型语言；他怀疑五到十年后回头看，现在用 AI 做的一些事也会显得很蠢。bwfan123 讲了创业公司里一个代码混乱、bug 频出的工程师，大家的结论是他什么都不做反而更好；有了 LLM，负数会被放大成更大的负数。patorjk 也见到同样的情况：以前跑不起来的 PR 不会被合并，现在的 PR 乍看能用但暗藏问题，比如有人提了一个巨大的可视化 PR，自己实现了全部绘图逻辑，而项目里早就在用的 recharts 已经能做九成。不过 empath75 唱反调说，他宁可合并懒惰无能的开发者让 Claude 写的代码，也不要他们自己写的。
读代码等于理解代码吗？ efficax 的评论引发了最激烈的交锋。他说读代码并不意味着理解代码，经验告诉他「我从来没理解过代码」，你以为它这样工作，直到发现并非如此。LLM 让他可以说：找出这东西所有的运行方式，写模糊测试和属性测试，在所有场景下运行，记录完整轨迹，然后逐个分析 bug，这是人手做不到的。他认为只要投入资源，医疗、金融、航空等领域的软件完全可以借助 LLM 变得更可靠，「一行代码都不用读」。他说自己写过几十万行困难代码，美国人刷借记卡时一度都会用到他写的软件。反驳如潮：layer8 说测试不等于理解，也不等于证明正确；gf000 说程序的状态空间极其庞大，连两个 64 位值的所有组合都测不完，真正能 100% 验证的是形式化方法和 TLA+；OGWhales 说 LLM 基于前文预测，天生不擅长探索新的可能性空间，很多人以为它能帮你覆盖所有情况，这恰恰是它最弱的地方；boomlinde 和 geraneum 都问：如果你不理解代码，怎么知道它生成的模糊测试和属性测试真的在验证你想要的性质？troupo 则说他每次新模型一出就试，烂代码的数量和出现位置基本没变，而测试抓不到你不知道存在的烂代码。jdkoeck 的说法比较中肯：只读代码也许不足以理解程序行为，但以为不读高层代码就能理解程序行为是真的很傻；我们不读生成的汇编，是因为编译器是可靠的抽象，提示词不是。
写代码就是思考。 gradus_ad 说写代码的过程就是澄清自己思路的过程，会逼你回答那些原本并不明显的问题；AI 一做假设就会在更大的上下文中引入 bug，它如果不做假设而来问你，又得事先知道该假设什么。作者回复了文中那句「AI 可以向你解释，但不能替你理解」，并补了一句俏皮话：「花几天动手做，确实能省下几个小时的思考。」strange_quark 说他公司最近出了 AI 写作政策，因为大家互相发送的大量垃圾文字已经浪费太多时间，政策基本就是「别这么做」，理由是「写作就是思考」，「他们离明白真的很近了」。clickety_clack 和 taneq 都说，自己动手才能真正理解问题，别人（或 agent）写的代码一出问题，你得先做同样的工作，再额外搞懂别人写了什么。
对文章本身的批评。 不少人认同标题，但不认同论证。IshKebab 说作者大谈 LLM 不确定，好像人类就是确定的；vincent-uden 反驳说文章其实没怎么讲随机性，而且你和 LLM 的讨论不会让它明天学到什么。armchairhacker 认为编程确实没解决，但作者的前两个论点（不可问责、随机性）是错的：可以追究推广 LLM 的人的责任，概率性不等于愚蠢，文中举的一些 LLM 失误早已修复几个月了；真正的理由是你没法靠提示词做出一款 3A 游戏或企业级工具。hibikir 质疑「你不能为自己控制不了的东西负责」这个前提，法律上到处是让人对自己不完全控制的事物负责的例子，比如放出伤人的狗；作者回复说，只要法律上处于控制地位就要负责，区别似乎在于有些公司凌驾于法律之上。Sevii 和 giovannibonetti 不同意「多数需要雇工程师的软件都是低风险容忍度」，后者说他在医疗科技公司的经历是：那里能容忍极其糟糕、拖慢用户的界面。grim_io 说一篇「非 AI」的文章用了这么多带勾号的列表，而且被作者用漏掉第 5 条来考验的感觉很不舒服；gyesxnuibh 也觉得那是个蠢把戏。Marha01 要求拿出硬数据，比如比较人写代码和 AI 代码的 bug 密度及其趋势，否则全是感觉。最激烈的是 metalspot，他指责这是一篇「自我推销的 AI 垃圾标题党」，劝大家去看 antirez、DHH、Jared Sumner、Marc Brooker 等真正交付过软件的工程师在说什么；作者回敬道：「跳读一篇文章、完全没抓住重点，然后跑来 HN 咆哮，这份胆量也是够了。佩服你的注意力持续时间。」
其他值得一读的观点。 bushido 自称很看好 AI 编程，但同意作者：编程没有解决，更接近被解决的是产品开发。他以前有几个写得飞快但总是偏离目标的程序员，在资深工程师交付 MVP 的时间里，他们已经做错、收集反馈、再做错、再收集反馈，往往比资深工程师更快接近一个有人愿意付钱的产品；AI 也是这样。username_my1 讲了自己的经历：他让模型循环处理任务、另设一个「CTO」检查架构，最后两个模型都发誓代码完美，结果一跑起来软件开始往 CSV 文件里写大量数据而不是写数据库，因为 AI 决定在测试中用 CSV，然后就跑偏了，「这种错误我连初级开发者都不会接受」。vmg12 说 AI 写 CRUD 接口、快排、堆这类东西几乎完美，但很不擅长设计类型和 API，不会为系统将来的演化做规划，他认为这需要非常难构建的强化学习环境，迟早会解决但需要时间。thefilmore 贴出了 Claude Code 显示 Bun 帮助菜单和多次自我卸载的 issue 链接，ashkankiani 说这一条就足以说明问题：Anthropic 有无限的钱和最好的未发布模型，终端 UI 又是存在了约 50 年、最被充分理解的东西之一，如果编程真被解决了，它的 TUI 应该完美无缺才对。ilaksh 则说这些 bug 很丢人，但证明不了最新的 LLM 不擅长编程。ChicagoDave 讲了自己在 Explore DDD 大会上当「反方」的经历：多数与会者担心过度依赖生成式 AI 会让集体知识消散，他却认为人类历史上一直在为了进步而隐藏知识，没人再手焊芯片了；他有一个由他设计、由 Claude Code 生成的代码库，相信代码不需要人审，但系统设计和变更一直由他把关，关键是想清楚哪些部分真正需要人来决定。