9 月 10 号，dev.to 上 Sylwia Laskowska 那篇文章的标题把话说死了：AI 在编码方面已经超过大多数软件开发者。底下 188 条顶层评论，吵成一片。我把标题看了两遍，不是想挑刺，是这个句式我太熟了。它上一次以这个形状出现，主语还不是 AI。
1959 年，CODASYL 那拨人给 COBOL 定标准，推广口径里有一条几乎算是政治承诺：这种语言要让人读得懂，最好让写业务规则的人自己就能写。据当时的说法，它要消灭的正是那个把人的意图翻译成机器指令的中间层。这句话今天还在说，只是换了名字——换成了"让业务人员自己搭应用"，再换成"让产品经理用自然语言直接生成功能"。六十多年，每一代换一个技术名词，靶心一动不动。
中间层没被去掉。一次都没有。但每一次都削薄了一层，削下来那部分需求往下压，压成新的中间层。这是这条线上唯一稳定的规律。
1980 年代中后期到 90 年代初，CASE 工具那一拨。承诺非常具体：分析师在屏幕上画数据流图、画实体关系图，工具从图里生成代码骨架，激进一点的厂商干脆说能生成整个应用。那一拨展台上摆的东西，跟今天 agent 的 demo 在观感上是一个物种——输入是人的意图，输出是能跑的东西，中间那段自动化。结局呢？CASE 这个词今天没人提了。活下来的是图本身：ER 图、数据流图，以及后来接棒的 UML。它们留在白板上、留在设计评审里，但它们不再承诺"图画完，代码自己出来"。
1990 年代，4GL 那一拨。我前些时候挖过它一遍来龙去脉，比较有意思的地方是：它没有失败。它活得好好的，只是没人再叫它 4GL 了。你今天在 BI 工具里拖几个字段生成一张报表、在低代码平台上连几个表单出一套审批流——那都是 4GL 的直系后代。它的承诺兑现了大概一半：在"数据库查询加报表"这一个窄格里，它确实做到了"说清楚要什么，机器自己去取"。另一半没兑现：它出不了那一格。让它去写一个状态机、写一段并发控制、碰一下内存边界，它当场哑掉。
这一步是分水岭。4GL 的胜利和它的边界是同一样东西——它能覆盖的语义范围越窄，就越可靠、越好用；一旦越出这个范围，它就从工具退化成必须被绕开的障碍。抽象层每往上抬一级，覆盖面就窄一格。被挤出这一格的需求不会消失，它沉到下面，变成新的手写代码。Joel Spolsky 2002 年那篇讲 leaky abstractions 的文章说的是 API，我这儿说的是"谁负责写代码"，同一个结构。
2001 年，OMG 推出了 MDA，MOF、XMI 那一套。这个东西的情怀跟今天的 agent 像得让我回头看有点心疼——模型是唯一的真相来源，代码只是模型的一次投影，换个平台就换一次投影，业务逻辑本身不跟着平台变。方向对。
我承认我对 MDA 有偏爱，但偏爱改变不了它死掉的事实。它死在哪儿？它要求人先花比写代码更多的精力，把系统画成一个足够精确的模型，然后才给你生成。而这个"足够精确"恰恰是最贵的一段活——不是画图贵，是把人脑子里那些含含糊糊的东西逼成形式化模型贵。省下来的打字时间，填不回建模的时间。回头翻那一批项目的复盘，还有一层被反复提到：模型本身也在变，模型一改，生成的代码全得重来，而手写的那几个补丁不会跟着模型走，两边的裂缝越撕越大。
正确方向的东西，死在错误的时代和错误的实现方式上。这种死法在技术史上比"方向错了"常见得多，也更容易被后来的胜利者忘掉。
那篇文章真正的核心是那一句：AI 更擅长编码不会降低软件工程师的价值，而是让编码本身作为软件工程技能变得更不值钱。这句话我基本同意。但它被当成安慰剂喝下去，就有问题了。它藏着一个没说出口的推论——编码贬值了，工程师就升值了。历史上这个推论从来没成立过。
每一次"写代码变容易"发生，跟着来的都不是现有工程师身价上涨，是"谁有资格叫工程师"这条线被重新划一遍。六十年代"程序员"这个岗位描述的是什么人？把一个已经被人设计好的流程翻译成机器指令。技术史里对这批人的记述相当一致：里面很多是女性，工资低于设计者，做的被归为文书性的工作。等到编译器成熟、高级语言稳定，"把流程翻成指令"这件事被语言本身吃掉了，这个岗位名慢慢退场，"软件工程师"这个称谓浮上来。这不是同一批人换了个头衔。是门槛换了地方，一部分人被留在了旧门槛外面。
那篇文章里有个判断我觉得方向对但归因省事了：多数软件本来就不复杂、压力主要落在初级和中级开发者身上。压力大不是因为他们手上的活简单，是因为他们的活正好落在"能被抽象覆盖"的那一格上——按前面那条规律，这一格永远最先被吃掉。中级的处境其实比初级更别扭：初级还有个"我在学"的身份标签挂着，中级被期望既写代码又做判断，而 AI 正在把"写代码"这半边从他们的价值里抽走，剩下那半边他们往往还没长出来。她说的另一件事倒是跟这条规律咬得上：责任心强、懂产品、会决策但编码不是顶尖的人，空间会变大——门槛往"负责"那边挪，正好把这批人放进来，而把只会把任务转成代码的人挤出去。这是同一件事的两面。
但这次有个东西真的不一样。不说清楚，我上面整套"历史上演过"就变成了自己的天命所归式偷懒。前三次的工具都是确定性的：CASE 的代码生成器、4GL 的编译器、MDA 的模型转换器，同一份输入给同一份输出，读得懂、追得到、能进版本控制。LLM agent 不是。它每次给你的东西都不太一样，你也很难从输出倒推出它为什么这样输出。
后果落在验证成本上。评论区一位叫 Nazar Boyko 的讲得很实在：他已知解法时写代码只要几分钟到几小时，用 AI 省掉了那几分钟，但多出来"读它、修它、测它、检查它有没有把项目其它地方搞坏"这一整段，而且在大型生产代码库里 AI 最有用的时候是分析，还并不总对。他把"脱离 AI 之后还能不能维护"当成工作是否完成的标准之一，这个标准我觉得比任何基准分数都靠谱。
METR 那几份结果方向一致地不稳。2025 年初那份针对有经验开源开发者的研究，结论跟直觉是反的——经验丰富的人在熟悉的仓库里用 AI，反而更慢；后来的 uplift 更新又提示新工具可能带来提速，但幅度远不如原始编码基准上那么惊人；MIRRORCODE 的初步结果、NBER 那份工作论文 w35275，都落在这个区间里。这些材料各家口径有出入，我不判谁对谁错。当一项技术在基准上的成绩和在真实工作里的成绩差这么远，那个差值本身就是结论——差在验证、差在上下文、差在没人愿意替它把约束写清楚。
那篇文章里我最喜欢的，是她自己举的那个例子：某个改动，agent 大概五分钟就能实现；从讨论要改什么，到协调多个团队，到客户点头，实际花了四天，中间决策还反复变了几次。她用这个区分 coding 和 software engineering。例子选得好，但它的意义比她自己说的还大一点。
过去几十年"编码慢"这件事一直在替组织遮丑。讨论没对齐、需求反复、跨团队扯皮，这些成本一直都在，但它们有个方便的藏身处：这周在写代码。等到写代码这一格被压到五分钟，遮不住的东西就全暴露了。那个 5 分钟对 4 天的比例不是 AI 造出来的新现象，是它把一个一直存在的比例第一次照了出来。Brooks 在 1975 年就算过这件事，沟通路径是 n(n-1)/2，人一多，协调成本比人手增长快一个量级。七五年那个公式，今天还成立。
她那句"AI 让我变得更不懒"我信，减少写重复代码的时间是真实收益——但收益的落点不是速度，是注意力。把注意力从不值得的地方挪开，这件事的价值经常被算成提速，其实不是一回事。
所以回到今天。那篇文章的标题里，"编码"和"软件开发者"这两个词的定义一直在打架。它拿编码的尺子去量开发者，量出来当然是输。可这把尺子本身一直在往更不值钱的方向走，用它量赢的人，赢的是越来越轻的一把尺子上的刻度。
我自己的判断是：这一轮真正被重划的门槛，不在"会不会写"上——那条线已经很低，再往下划没有意义。它划在一个更硬的地方：能不能对一个自己没有从头写完、也没有完全看懂的系统负责。听着像老生常谈，做起来很难。你得读得懂不是你写的代码，得判断这个改动会不会把半年后某个地方掀翻，得在 agent 给你三份看起来都行的方案时选一份，并且愿意在出事的时候说这是我定的。前几轮抽象升级，人被要求"想清楚要什么"就够了；这一轮开始要求"对不是自己做的东西负责"。这两件事在能力上不是同一件事，中间隔着一段没人教过的路。
评论里有人提了个说法，把 developer、engineering、architecture 这些词里的 software 换成 system——软件以后主要由机器实现，人负责意图和控制。这不是修辞，它对应一个具体的变化：以前工程师的技能树从"读别人写的代码"开始长，以后可能从"读机器写的代码、并且能判断它哪里不对"开始长。那篇文章的作者提到她见过清理 vibe-coded 应用的招聘岗位，还开了个玩笑说 vibe-code 清理工程师可能是未来职业。这不是玩笑，这是验证成本已经涨到需要专门岗位来吸收的第一批信号。
反事实历史是廉价的。如果 MDA 晚生二十年，赶上今天这拨算力和模型，它会不会就是今天 agent 在做的事？也许。但这个问题问不出答案。能确定的是，它当年死掉不是方向错，是它要人先付的成本太高、拿回来的收益太晚。一项技术能不能活下来，不取决于它替掉了多少打字工作，取决于它省下来的时间够不够填回它新制造出来的成本。前三次填不回来。这次填不填得回来，就看验证成本那一栏——那一栏现在还在涨。