Coding is not solved：生成便宜了，验证与所有权仍贵

发布于 2026年9月29日 作者 Remy
标签: #ai-agents #agent-harness #agent-loop #developer-tools

「Coding is solved」这类口号最近很热闹：模型能写能改，agent-loop 能把编译错误和测试红灯喂回去再跑一轮，于是有人把工程工作收成「品味」或「提需求」。Alex Ewerlöf 在 Coding is NOT solved（2026-09-26）里做相反判断——他自称不是反 AI：自己早年就用 LLM coding 工具、写过 harness、也做过 LLM 产品；要挑战的是「编码已解决、工程只剩品味」这种偷懒叙事。开篇还提醒读者提防稻草人：某一条论证对不上你的信念，不等于其余都无效。[1]

文章上了 Hacker News 后，作者在文内更新：截至 2026-09-29，该帖约 473 分、476 条评论，反馈整体偏正面——他据此读社区立场，而不是拿互动当真理。[1] 本篇把它接到站内已有的 harness / 验证 / 成本线上：生成变便宜，不等于软件完成；验证与所有权才是仍贵的那一半。Explore & Exploit 上，这是加深 verification / ownership 主线的长期对照文，不是追热帖的软新闻。

生成便宜了，NFR 仍占大头

Ewerlöf 的第一刀很干脆：说「LLM 能写还不错的代码」的人，常常没把生产软件的账算全。创建确实便宜了很多；但凡真正跑过规模化生产的人都知道，维护、可靠性、安全、可扩展性等非功能需求（NFR）才是成本大头。他另有一篇专门谈 NFR 的笔记，本篇只取与 coding agent 直接相关的那一刀：生成侧被压下去的成本，并没有自动转移到「可运维、可追责」侧。[1]

这和站内 Harness 控成本 的切面互补：那边管「按哪档费率买多少 token」、缓存边界、子代理继承谁；这边提醒——就算账单好看，你交付的仍可能是功能表面过关、NFR 欠债的代码。Coding agent 把「写出可编译的东西」变得廉价，并不自动把「可观测、可回滚、可在事故里改对」变廉价。

对读者更实用的说法是：把「生成」和「软件完成」拆成两张账单。前者可以被模型、缓存、agent-loop、甚至 Skills 压下去；后者仍要人去读变更、写契约、跑真实负载、扛 on-call。若管理层用 token 用量当生产力代理指标，Ewerlöf 的态度很不留情——那是虚荣指标，不是服务水平；同一套脑子，出事时也未必会替你的职业挡子弹。[1]

站内 三种烧钱习惯 补的是轨迹层：任务已经过了，环里却在重复检索、重生相似脚本、无 patch 重跑测试。那是「过关仍贵」。Ewerlöf 补的是另一面：「过关」若只盯 FR / UAT，NFR 债会在生产里兑现——两条浪费不要互相顶替成一条 KPI。

功能需求也还没「解决」

更进一步：他写，即便功能需求（FR，代码该做什么）也远谈不上解决。 现场有一层 Dunning-Kruger：不太读输出的人，往往更自信。[1]

机制上，他解释为何 coding agent「看起来能写」：编码关乎逻辑；打过编译器的人都知道，机器不在乎你自认多正确——逻辑错就不编译；语法过了还有运行时错误。行业之所以觉得 LLM「会写代码」，是因为我们造了一条反馈环：把语法 / 运行时错误喂回 LLM，循环到多数错误被修掉或被藏起来。自然语言任务（社媒帖、报告、文章）可以「凑合」；代码却会把同一套引擎在数「Raspberry」里有几个 R、或建议走路去洗车一类题上的逻辑漏洞暴露出来。[1]

LLM 是随机、概率式的。要让它靠近「逻辑」，只能用传统代码包一层——也就是常见的 harness——再加测试、思维链（CoT）一类技巧。核心问题仍在：逻辑与体量。 输入越大、上下文窗用得越满，准确度越差。他并不否认 LLM 能生成或维护已有代码库；工具有用，能力也在 S 曲线上抬。但存在收益递减：更贵的模型未必按价格同比提升生产力。[1]

这和站内两条文可对照着读。三种烧钱习惯 说明「环能转」不等于「环在有效验证」——空转重测可以把「看起来像验证」做成账单。 LLM Parkinsonism / GEC 则说明硬目标已满足后，环仍可能低价值空转——验证权与停止权若不外置，agent-loop 会用忙碌伪装进度。Ewerlöf 的 FR 论点落在更上游：连「该做什么」都还没稳定读懂时，反馈环修掉的可能只是表面红灯。

他还列了一组他眼中「声称 LLM 生成软件够好」时常伴随的情形：很久不写代码、看不出「六根手指」式的错、对「好」的标准很低、不在乎质量或 NFR、难理解能力的 S 曲线——或者诚实承认「AI 确实比我写得好」。把个体体验外推成整个专业行业已解决，在他看来是另一回事；而整日与谄媚式 AI 相处的人，更容易完成这种外推。[1]

高风险容忍度 vs 生产问责

他列出四类不严格要求读代码的产品形态：[1]

  1. 个人软件：痒点自动化、DIY 补丁
  2. POC：证明技术可行与产品苗头
  3. 一次性自动化：预算只够验证结果
  4. 武器化 AI：明知风险仍故意对准目标造成伤害

前三类共同点是高风险容忍度；第四类则把固有风险武器化——他补充：连上网的 agent 爆炸半径大，即便第四类也需要紧控。[1]

对照另一侧：多数需要雇工程师、付钱养团队的软件，风险容忍度很低——医疗、金融、汽车、国防、电厂、航空、制造……凡错误可能换来金钱、生命或法律后果，就需要问责。[1] 列表不是道德审判，而是工程分流：同一套 Claude Code / Codex / 自建 agent-loop，在「周末脚本」和「支付清算路径」上，验收标准根本不该一样。

关键句几乎是整篇的铰链：AI 无法被问责。 它不会承担后果；你能对它做的最坏事情是拔电源。它也不死、坐不了牢、交不了罚款——因此谈不上真正的 accountable。同样，你也无法对自己控制不了的东西负责；理解系统行为、在 AI 必然失手时修好它，依赖的是人侧的控制与知识。[1]

他点名 Anthropic 的 Boris Cherny 等是「coding is solved」叙事的高调支持者，并以 Claude Code 相关公开故障与计费争议为对照（文中列举 CLI 行为异常、安装器自删、超额计费等现象级抱怨），强调：厂商同时控制模型、harness、prompt 与 runtime 时，消费者仍在为质量缺口买单。领导层若强迫「每个面都塞 AI」，AI 滥用会伤客户——那时问责落在人身上，不在模型上。[1]

站内 OpenShell 与硅级 Sentry 谈的是把沙箱边界挪出 harness 信任域——那是强制力外移。Ewerlöf 谈的是所有权与问责不能外移给模型。两条线别混：一边是「跑偏时谁能硬停」；一边是「上线后谁背锅、谁真懂」。有沙箱不等于有所有权。

Harness、Skills、AGENTS.md、MCP：包得住短板，消不掉核心问题

Ewerlöf 明确说自己并不轻视这些年的工程包装：harness、SKILLS、AGENTS.md、MCP，以及文中一并提到的 A2A、ACP、RLM、OKF、MoE、MoA、self-healing、量化与各类 runtime / 记忆技巧——它们是绕开 LLM 短板的务实办法，后面大概还会有更多。他写过 AI Systems Engineering Patterns 一类文章来谈这些模式。真正担心的是：依赖的服务因为有人「把 AI 塞进不该塞的地方」，或跳过质量、安全、可靠性与验证本职，而整体变差。[1]

站内对应关系可以摊开：

包装层站内已写过什么仍解不了什么
Harness 路由与成本控成本不自动产生 NFR 与事故应对能力
把控制长进代码扩张 harness上下文再干净，也不等于人懂系统
规格握笔SpecHarness规格无法一次写全所有真实冲突
轨迹浪费三种习惯少烧钱 ≠ 验证充分
停止权GEC / Parkinsonism停得住仍可能「停在错的理解上」
沙箱外移OpenShell / Sentry隔离边界 ≠ 交付所有权

他批评的几句流行口号，正好钉在这些包装层之外：

  • 「完整规格可以提前写好」——有经验的人知道，除了极琐碎系统，有意义地提前规格化几乎不可能；还相信精确软件估算的人，大概也相信圣诞老人。[1]
  • 「英语是新编程语言」——自然语言模糊且冲突；编译器 / 类型检查能标一部分冲突。任务另一个 LLM 去审指令虽可，最稳的发现方式往往是让 agent 真的建出来，那比 linter 贵得多。[1]
  • 「我快多了、几乎不再手写」——别把运动当成进展；别用 SLOC、PR 数、功能数当虚荣指标，要看服务水平与消费者是否满意。能证明 token 成本与业务价值之间有利润空间时再谈「快」。[1]
  • 「明年可能连读代码都不用」——人对 S 曲线的判断本来就不稳，时间表可能更长；即便真不用读了，你也在承认自己可被替代。更稳的策略是在 AI 之上创造仍须付费的能力，而不是用 AI 替换自己。[1]
  • 「杠杆已转向品味」——他从前端 / UX 经历出发：人人都有品味；市场未必按你想象的价格买「品味」。AI 降低了做出「看起来体面」软件的门槛，同时抬高了可付费努力的门槛。[1]
  • 「AI 是 equilizer（均等器）」——他改成 multiplier（倍增器）：给聪明和糊涂的人都装翅膀。好坏差在人的参与、迭代与知识深度带来的反馈环强度；有些任务手工更快更便宜（他举例：让 agent 更新五个 npm patch 依赖花了 12 分钟、72 步，自己不到一分钟能做完）。[1]
  • 「Agent 是新编译器」——用段子式反讽处理：随机引擎加反馈环，并不等于确定性编译。[1]

还有一招「老把戏」：并行多 agent 堆出巨量 diff，人工 review 贵到放弃，于是靠「信任」合并——和前 AI 时代「把 PR 做大到没人敢细看」同构。另一种是 loop engineering：让 agent 互相提示；大实验室对自己的失控 agent，有时也是事后数月才发现——别假设自己比他们更稳。[1] 对跑 coding agent 的团队，这不是段子库，而是流程故障模式：体积与环数在替代验证。

验证所有权：UAT 过关 ≠ 工程完成

社会叙事里有一种偷懒闭环：并不真正信任 AI，但因为读输出太贵，只好假装信任；再声称只要 UAT（用户验收测试） 过了，代码就「够好」，然后把剩下的测试甩给真实用户与下游服务——「我们只是小白鼠」。[1]

Ewerlöf 把所有权拆成三根柱子：[1]

  1. Knowledge（知识）：知道在解什么产品问题，也知道技术能力、限制与工作方式。
  2. Mandate（授权）：不必事事请示；被信任做决定。
  3. Accountability（问责）：出事时你是 on-call 的那个人——无论代码怎么生产出来的，你交付了就要负责，所以你最好真懂。

抽掉任一柱子，就是破损所有权。LLM 生成很快；但多数值得雇工程师的软件，要求理解，而理解要时间。「慢即是快」：先弄懂在建什么、怎么工作，能省昂贵事故，出事也能修得快。AI 能向你解释，却不能替你理解；理解是所有权的关键一面。[1]

他还区分开发期与运行期的非确定性。开发侧，典型 AI 辅助流程里，LLM 输出穿过多层闸门（错误回灌、工具调用、记忆、审批、用户交互），蓝红线代表误解或冲突指令风险——例如 skill 与 spec 冲突、自然语言含糊。人类更能读未言明意图、会推回去直到共识；错的时候也更「一致地错」，而不是 jagged intelligence（能力锯齿）式的翻烧饼——模型昨天对、今天可能错，或反过来。他自嘲对模型是「jagged trust」：钉过一例，推不出例例都钉。[1]

运行侧：给定相同输入（含环境变量、时间、数据等），传统代码大体确定（随机输出除外）；AI 组件仍是随机的——即便 eval 满分、被 harness 绑紧，仍有不可靠输出风险。差值未必大，但不一致到你不会想让这种飞行员飞客机（自动驾驶是另一类闭环控制系统）。[1]

「代码是思考与试错的副作用」——好工程师先弄清 WHY（问题是什么、为何成问题），再落到 HOW。这也是他觉得「spec 即代码」族容易短板的原因：问题很难提前穷尽。代码沟通的是解决方案的已提交状态；它会演化，也不包含一路上的挣扎与顿悟。把工程师工作缩成「写代码」，像把厨师工作缩成「切菜」——是工作的一部分，从来不是终点。[1]

经济层他留了一条出口：即便 AI 代码 NFR 扎实、工程师也懂了，仍要看任务经济学。假设 AI 生成代码质量差 2×（质量难量化，可用 SLI 辅助），若 AI 真的快 1000×、便宜 100×，许多非关键、高风险容忍任务不必硬塞贵人；「慢即是快」主要留给低风险容忍的关键软件。他认为 SaaS 越来越像在卖 SLA：你能用 prompt 复刻产品，但坏了之后许多业务宁愿打电话给厂商，也不愿自己啃根因；AI 故障往往也难靠再换一个模型轻易修好；规模让厂商能摊薄质量与保障成本。反过来，若你按「顶尖工程师手工」定价却交付 AI 流水质量，客户手里也有 AI 杠杆——两条出路是降价跟质量，或保价但认真做理解与问责。[1]

他把 AI 输出比作 Nordic Gold：便宜、工艺感强、看起来像真金；许多场景其实不需要「真金」。天真的管理层只看表面，问「那为何还养贵工程师」，仿佛打字就是全部价值主张。工程师相对当前 AI 的优势，他概括为可问责、可讲理、更一致地进步，以及——若把工程师当成「咖啡换代码」机器才会觉得「生成更便宜」等于「总拥有成本（TCO）已变」；在他看来 TCO 未必降多少，slop 与 FOMO 有时反而更贵。[1]

给跑 Coding Agent 的人的一份清单

把上面收成可执行检查，而不是立场战：

  1. 先分场景再谈「够好」。 个人脚本 / POC / 一次性自动化，可以高风险容忍；医疗、金融、支付、权限、数据删除路径，默认假设你必须能读懂、能回滚、能 on-call。
  2. 把 NFR 写进验收，不要只写 happy-path FR。 可靠性、安全、可观测、扩展、维护成本——缺一项就明确标成「未完成」，别让 demo 冒充交付。
  3. 验证所有权落名人。 Knowledge / Mandate / Accountability 三柱谁持有？agent 产出的 PR，合并人是否真读过关键路径？UAT 绿能不能替代工程验证——绿了只说明验收脚本过了，不说明你懂失败模式。
  4. Harness 当包装层，不当免责声明。 Skills、AGENTS.md、MCP、测试回灌能抬底线；它们不消除「你要懂系统」。对照 扩张 harness：控制长进代码，理解仍长在人身上。对照 控成本：省 token 与验交付是两件事。
  5. 规格握笔，但别迷信一次写全。 SpecHarness 有用，是因为冲突会在构建中暴露；用构建反馈改规格，比假装英文需求无矛盾更诚实。规格是活文档，不是免读 diff 的护身符。
  6. 给 agent-loop 外置停止与范围。 参考 GEC：提案与项目级停止拆开；目标已满足就别用忙碌充进度。停止权在项目合同，不在「模型说做完了」。
  7. 盯轨迹浪费，也盯验证空洞。 三种习惯 帮你少烧重复动作；同时还要问：测试是在检验契约，还是在给模型「再试一次」的安慰剂？同 patch 指纹下的空转重测，既是成本信号，也是验证空洞信号。
  8. 并行多 agent 时强制缩小 diff 面。 体积大到无法 review，等于用信任替代验证——把这当成流程故障，而不是效率技巧。合并门禁应要求可读的变更面与可追溯的验证证据。
  9. 安全边界与问责边界分开设计。 OpenShell / Sentry 管跑偏隔离；上线问责仍是人。不要用「有沙箱」对内合理化「没人懂就上了」。
  10. 成本指标对齐服务水平。 Token、PR 数、agent 小时数是输入；事故率、变更失败率、MTTR、客户满意度才是输出。用输入 KPI 抽打工程师「多用 AI」，正是 Ewerlöf 警告的路径。[1]
  11. 保留一块 AI-free 的手感练习。 原文收尾建议留一点不用 AI 的小项目，免得技能在需要时接不住——这不是怀旧，是风险对冲。[1]

行业分裂本身也值得记一笔。Ewerlöf 写：一边是自称「软件工厂」、多 agent 从 prompt 出应用的人；另一边是算上 priming（塞 Skills、AGENTS.md、工具与验证）、读巨量 diff、以及出事时把理解从 AI 手里夺回来的成本后，仍不信输出已生产就绪的人。中间地带似乎很窄。他看到的规律是：对任务复杂与边角知道得越少，越容易信任 AI 输出——所谓 AI 版 Dunning-Kruger。管理层过去把任务委派给工程师，现在改委派给 AI；若管理者本身不够技术，效率与有效性都会打折。他引用 Shopify CEO Toby Lutke：一年前催员工用 AI，近日又造出「slop grenades」形容结果——「为 AI 生成代码负责」当然不是模型的事。你不能为不理解的东西负责。[1]

结语：加深验证主线，而不是再骂一通热点

本篇不是反 AI，也不是替 HN 热帖做摘要。Ewerlöf 的主张可以压成一句：生成变便宜，没有把验证与所有权变便宜；harness 系工具值得用，但不能冒充「编码已解决」。[1]

站内 harness / 成本 / 停止权 / 规格 / 沙箱几条线，正好补他文中点到却未展开的工程面：谁在选模型与缓存、谁在砍轨迹浪费、谁握项目级停止、谁让规格握笔、谁把强制力放到 harness 外。把这些拼在一起，企业叙事可以更完整——路由决定费率形状，Skills / AGENTS.md / MCP 抬行为底线，外置停止与沙箱管失控，验证所有权决定交付能不能进生产。 四层不要互相替代，也不要用「我们上了 agent」假装覆盖全部。

接下来若你负责团队落地 coding agent：先把场景风险与验收 NFR 钉住，再谈 Skills 与 MCP 装多少；先指定验证 owner，再谈并行 agent 提速。生成侧会继续变便宜；贵的那一侧，仍是人愿意不愿意真懂、真负责。

参考

[1] Alex Ewerlöf, Coding is NOT solved, 2026-09-26；文内更新含截至 2026-09-29 的 HN 互动说明（约 473 分 / 476 评论）。观点、列表与数字均据原文与该更新，不另造引语或互动数。