AI 吃掉的是机械实现，留下来的却是更昂贵的东西：工程判断力、系统控制力，以及把 Agent 约束进现实世界的能力。

AI 会写代码之后，很多程序员最先失去的，不是工作，而是确定感。

过去那些靠熟练手工实现建立起来的优势，正在迅速被重估。补函数、改 bug、补测试、搭页面、读仓库、跑命令，很多以前默认必须由程序员亲手完成的工作，现在已经可以直接甩给 coding agent。

于是一个问题开始反复出现：

AI 都已经这么会写代码了，我们还要不要学那些”古法编程”？

我的判断是： 古法编程没有消失，但它的意义变了。

如果把编程理解成”亲手把代码敲出来”，那它确实正在被 AI 侵蚀。 但如果把编程理解成”把一个模糊的想法，稳定地变成一个可运行、可维护、可演进的软件系统”，那古法编程不仅没有消失，反而变得更重要了。

只是，它不再只是”人肉产出代码”的能力， 而越来越变成一种更高阶的能力： 定义问题、约束系统、判断结构、验证结果、控制演进。

换句话说，AI 不是在消灭编程。 它是在抬高编程。

01 AI 最先吃掉的，不是编程本身，而是机械实现

如果回头看过去一年 AI 编程工具的演进，你会发现一个很明显的趋势： 它们最先吃掉的，不是软件工程的核心，而是软件工程里最机械、最重复、最局部的那层劳动。

比如：

• 写一段样板代码
• 按已有模式补一个接口
• 给页面补交互
• 根据错误日志回溯代码路径
• 写一个基础测试
• 把一段局部重构做完

这些工作过去当然也需要能力，但它们有一个共同特点： 可以被明确描述，可以被局部验证，也可以被快速试错。

而这恰恰是当前 coding agent 最擅长的事情。

所以今天很多程序员真正感受到的冲击，并不是”AI 会不会彻底替代自己”，而是另一件更现实的事：

那些曾经足够值钱的手工实现能力，正在迅速失去稀缺性。

你会写 CRUD，别人也会写，Agent 也会写。 你能一晚上撸出一个后台页面，别人能，Agent 也能。 你熟悉某个框架的大量模板化写法，这当然还是能力，但已经不再像过去那样构成明显壁垒。

所以，焦虑不是幻觉。 只是很多人把它说成了”程序员要没了”，但更准确的说法应该是：

程序员的价值锚点，开始迁移了。

02 真正没被吃掉的，是工程判断力

AI 会写代码，不等于 AI 会做工程。

这中间差的，不只是正确率，也不只是 hallucination，而是更底层的东西：判断力。

比如：

• 这段代码虽然能跑，但它是不是把边界条件偷偷埋雷了？
• 这个需求应该抽象成公共能力，还是先局部实现更划算？
• 现在为了快引进这个依赖，三个月后会不会变成新的维护负担？
• 这个 patch 是真的修好了问题，还是只是把复杂度推迟爆炸？
• 这个模块表面上被 AI 重构得更”干净”了，但它是不是已经偏离了系统原有的演进方向？

这些问题，没有一个是”多写几行代码”就能自动解决的。

它们依赖的是长期的软件工程训练，依赖的是对系统结构、业务语义、历史包袱、团队协作、未来维护成本的综合判断。

这也是为什么，很多 AI 生成代码虽然能跑，但你总觉得”不太对”。

去年 InfoQ 援引过一个安全方向的报告，里面有一句话特别扎心： AI 生成代码往往功能上可用，但系统性缺少架构判断。

这几乎点穿了今天 AI 编程最大的边界。

AI 最容易补齐的是”把东西写出来”。 人最难被替代的，是判断”这样写到底对不对”。

所以古法编程真正留下来的，不是手写速度，而是结构判断。 不是你一小时能敲多少行，而是你能不能提前看见一段代码三个月后的代价。

03 古法编程的价值，正在从”生产代码”转向”约束代码”

如果说过去程序员最核心的动作是”写”， 那今天越来越重要的动作，其实是”约束”。

一个人和 AI 配合得好不好，往往已经不取决于他会不会写华丽 prompt， 而取决于他能不能把下面这些东西说清楚：

• 目标是什么
• 什么不能做
• 哪些边界不能碰
• 成功标准是什么
• 测试标准是什么
• 兼容性要求是什么
• 哪些历史行为必须保持

这件事听起来很新，但本质上非常古法。

因为老派工程师一直都知道，软件开发最难的从来不是把代码敲出来， 而是把问题定义对，把约束描述清楚，把质量边界守住。

Anthropic 在讨论 agent eval 的文章里提到一点，我觉得特别关键： 对于 coding agent，最自然、最有效的评估方式，依然是软件工程最传统的标准，代码能不能跑，测试能不能过。

这其实提醒了我们一件特别重要的事： AI 再聪明，最后还是得被拉回到工程世界的现实里。

不能只看它”像不像”，而要看它”行不行”。 不能只看它”生成了没有”，而要看它”验证了没有”。 不能只看它”回答得漂亮不漂亮”，而要看它”结果是不是可重复、可回归、可维护”。

这恰恰就是古法编程最核心的精神：

• 不迷信表达，要回到运行结果
• 不迷信生成速度，要回到测试验证
• 不迷信一时成功，要回到长期演进

所以今天真正厉害的程序员，越来越像在做一件事： 把 AI 约束进现实世界。

04 人不会退出 loop，只会退出更低层的 loop

Martin Fowler 最近有个说法，我觉得特别适合解释现在的软件开发变化。

他把整个软件开发过程分成 why loop 和 how loop。

why loop 关心的是： 我们为什么做这件事？我们到底想得到什么结果？

how loop 关心的是： 这个结果具体怎么被做出来？

在 AI 时代，一个非常清晰的趋势是： 人不会退出 loop，但会逐渐退出更低层、更细碎的 how loop。

那些逐行实现、逐块拼接、逐处修补的工作，会越来越多地被 agent 接管。 而人会更多留在更高层的位置，负责：

• 定义目标
• 拆分任务
• 设计流程
• 设定约束
• 设计测试与 eval
• 判断结果是否可信
• 控制整个系统的演进方向

这很像工业化之后很多行业发生过的变化。

以前工匠要亲手完成每一道工序， 后来机器替代了大量工序， 但更值钱的人，反而变成了那些会设计流程、定义标准、控制质量的人。

程序员今天其实也在经历类似变化。

未来一个优秀工程师，不一定是那个手写代码最多的人。 他更可能是那个最能拆需求、最会设边界、最懂怎么设计测试、最擅长判断 agent 有没有”看起来完成了，实际上已经做歪了”的人。

05 为什么不会写代码的人，依然很难真正驾驭 AI 编程

很多人现在特别爱讲一句话： AI coding 会让不会编程的人也能做软件。

这句话不能说错，但它只说对了一半。

AI 确实显著降低了软件生产的门槛。 但它降低的，主要是”开始做”的门槛，不是”持续做对”的门槛。

你让一个完全没有工程训练的人用 AI 搭个 demo，当然可能很快。 但当系统稍微复杂一点，问题马上就会浮出来：

• 他不知道哪里是关键路径
• 他不知道什么叫技术债
• 他不知道为什么测试必须前置
• 他不知道为什么这次 patch 修好了 A，却炸掉了 B
• 他不知道一个今天能跑的系统，为什么三个月后会完全失控

而这些，恰恰都是古法编程训练出来的东西。

你可以不再亲手写那么多代码， 但你必须知道什么叫好代码、坏代码、脆弱代码、可演进代码。 你必须知道一个系统为什么会慢慢烂掉。 你必须知道哪些地方可以放心自动化，哪些地方必须自己做最终判断。

所以未来真正稀缺的，不是”会不会写代码”，而是”有没有经过工程训练”。

AI 时代真正的分水岭，不是会不会用工具， 而是有没有经过足够扎实的软件工程训练。

06 AI 没有消灭古法编程，它只是把古法编程抬高了一层

如果非要用一句话概括我的判断，那就是：

AI 没有消灭编程，它消灭的是”把编程等同于手工敲代码”的狭义理解。

古法编程以前更像武功招式。 现在它更像内功。

你平时未必每一招都亲自打， 但你有没有这个底子，决定了你能不能看出问题，能不能驾驭工具，能不能在复杂系统里不翻车。

所以今天再看那些传统能力，比如：

• 抽象能力
• 结构化思维
• 调试能力
• 测试意识
• 架构判断
• 对复杂系统的敬畏
• 对边界、约束、质量的敏感

它们没有过时。 它们只是从”直接产出代码的能力”，变成了”组织 AI 产出代码的能力”。

这就是我理解的，AI 时代古法编程的新意义。

不是自己多写， 而是知道什么该写，为什么写，写成什么样，以及怎么证明它真的写对了。

结尾

所以，如果今天还有人问我： AI 都这么强了，还要不要学古法编程？

我的答案反而比以前更坚定： 要，而且更要学。

只是不要再把它学成一种纯手工劳动技能， 而要把它学成一种工程判断力，一种系统控制力，一种把 Agent 约束进现实世界的能力。

未来最强的程序员，未必是写代码最多的人， 而更可能是最能定义问题、组织 agent、约束质量、守住系统边界的人。

代码当然还会继续被写。 只是越来越多时候，写代码的未必是你亲手。

但对代码负责的人，依然是你。