晚上十一点，一个人坐在一排屏幕前。
左边五到十个会话同时在跑，下面的 Agent 一个接一个地动。关电脑之前，他还要再启动几千个 Agent。
这个人叫 Boris Cherny，Claude Code 的创造者。
**2026 年到现在，他说他一行代码都没写过。**每天提交几十个 PR，最高纪录一天 150 个。
前六个月，这个工具几乎没法用
我本来以为这种故事的开头应该是「天才做了一个革命性工具，然后改变了世界」。
真实的开头更难看：Claude Code 头六个月几乎没法用。
Boris 自己说，那段时间他只敢让 AI 写整个项目里 10% 的代码。剩下 90%，他还是自己一行一行敲。
真正的爆发点也不是什么工程壮举，是 2025 年 5 月 Opus 4 上线。模型换了一代，他的用法一夜之间变了。
这个细节值得停一下。
「前六个月几乎没法用」和「一年没写代码」这两句话出自同一个人，中间隔的不是半年，是一次模型升级。
这说明工具的天花板，一半写在产品里，一半写在模型里。
我自己也有过类似的经历：同一个 Agent，同一套流程，模型换一代之后，我给它的口头指令能砍掉一半。
他说编程这件事，已经被解决了
然后他说了那句被引用无数次的话：
coding is solved。编程这件事，已经被解决了。
我第一次看到，第一反应是「不可能」。
按常理，一个人越是靠某个技能吃饭，越不会宣布它被替代——就像你不会听到裁缝说「裁缝这件事已经被解决了」。
但紧接着他给的那张分类表，让我明白他不是在吹。
他说的不是「语法和语法」，而是「产出第一版」这件事——一个人能不能独立地把一个想法变成能跑的代码。
这件事在 2026 年，确实被解决了。
他把工程师分成五类，只有两类在变贵
角色
实际在干什么
Prototyper
把想法快速做成能跑的东西
Builder
把原型变成能长期维护的东西
Sweeper
把散落的代码收拾干净
Grower
把系统养大
Maintainer
让它一直活着
前两类，主要产出是新的代码。
后三类，主要产出是判断。
他的判断很直接：
AI 越擅长生成第一版代码，越需要有人做 Sweeper 和 Maintainer。
翻译成人话就是：AI 越能造东西，就越多造出来的东西等着有人收拾。
这不是一个「AI 好棒」的故事，这是一个**「谁来收摊」**的故事。
Prototyper 和 Builder 并没有消失，它们只是从唯一的那条路，变成了所有路里的一条。而 Sweeper 和 Maintainer 在 AI 之前是「资深工程师顺便做的事」，现在变成了独立的主线工作。
9 天做出一个快 100 倍的东西，前提是他去年才开始用
另一个人的故事更能说明问题。
Charlie Marsh，uv 和 Ruff 的作者，2026 年 3 月把 Astral 卖给了 OpenAI。
他用 9 天搭出了 Ruff 的原型，比当时最快的 Python linter 快 10 到 100 倍。
听起来又是天才故事。但他补了一句很诚实的话：
我直到去年圣诞假期，才开始真正用 Agent 编程。
在此之前，他就是一个写了很久、自己一行一行写的人。
这句补充把整个故事的时间线拉平了——他不是「一毕业就会用 AI」的天才，他是中途转过来的。
如果没有前面那些年攒下的「什么东西该长什么样」的标准，那 9 天大概率只会产出一个漂亮但没用处的原型。
转折之后，团队里发生了一个变化：
同事不再闭着眼合他的 PR 了。
真正的成本不在写，在于有人要读
然后他说了整件事里最该被抄下来的一句：
提交一个看起来合理的 PR 的成本已经降到了零，但审查和验证它的成本依然很高，甚至更高。
他把账算得特别具体：
- 作者写一个「看起来合理」的 PR，可能只花 2 分钟
- 团队要理解它，要花 1 小时
2 分钟换 1 小时。
这不是效率提升，这是把工作从「写」挪到了「看」。
写代码的人变少了，看代码的人一个没少。同样的一小时，理解一段 AI 写的代码，换来的只是「这段东西是某个 Agent 写的」——价值完全不一样。
Charlie 说同事不再闭眼合 PR，翻译过来就是这个意思：团队的吞吐量没变，但缓冲垫被抽掉了。2 分钟和 1 小时之间的那道差，是 AI 编程当下真正的账。
这一小时过去花在一个熟练工程师身上，它换来的是「这个系统的某个部分，我随时能改」。
这一小时现在花在理解一段 AI 写的代码上，它换来的只是「这段东西是某个 Agent 写的」。
同样的一小时，价值完全不一样。
Charlie 说同事不再闭眼合 PR，翻译过来就是这个意思：团队的吞吐量没变，但缓冲垫被抽掉了。
连他自己都会被自己骗
Charlie 还讲了一件更让人不安的事：
有时候我晚上睡一觉，第二天早上起来看自己昨晚提的 PR，心里想的却是：等等，这代码写得也太烂了吧？
他自己给这个状态起了个名字：很容易就骗过自己。
AI 生成的代码有个特性：它读起来永远像是对的。
它不会像新人那样甩给你一个明显的语法错误，它给你的是格式漂亮、命名规范、还附带注释的东西。
而「读起来像对的」，恰好是人的判断系统最吃的那一套。
所以这条状态可以翻译成一句更朴素的话：AI 降低了「写出来」的门槛，没有降低「看懂」的门槛，但它把两者的比例搞反了。
所以这件事对我意味着什么
回到我自己的项目。
我在做 AI 产品的时候，最耗时间的从来不是「把功能写出来」，是这些事：
- 判断一个 AI 给的方案，落到真实用户手里会不会出事
- 决定哪些东西能上线，哪些东西必须先按住不放
- 看出一段能跑的代码里，哪一处会在半年后变成事故
这三件事有个共同点：它们都不产出代码。
按 Boris 的分类，全在 Sweeper 和 Maintainer 那一侧。
写代码的门槛在语法、API、框架熟练度——这些恰好是 AI 最强的地方。
但判断一个东西对不对，靠的是你在某个行业、某类用户身上攒下的具体手感。
举个我项目里的例子：AI 给的实现测试环境跑通了，评审时我看的是三件它没法知道的事——字段为空时老数据里存不存这个值；这个接口被调了几年，能不能改返回结构；这个操作慢 3 秒会不会踩到风控。
这三件事没一件写在需求文档里。因为它们从来就不是需求，是历史。
AI 没有历史，你有一整个系统的历史。
所以我的判断是：AI 先吃掉的，是「知道要什么、且知道怎么做到」的人手里那部分工作。而「怎么判断做对了」，会变得更值钱，不是更不值钱。
结尾
如果你也在写代码，我建议只改一个习惯。
下次AI 给你一段看起来很干净的代码，别急着合。
先花 10 分钟问自己：如果这是同事半夜提上来的，我会不会直接合。
你会发现这个问题的答案，比 AI 写得好不好更重要。
至于我自己的问题——手底下这些需要判断的活儿，哪一天会被 AI 拿走——我暂时没有答案。
但我知道一件事：我今天多练一次判断，那个答案就晚来一天。
这是「数字生命岐伯」第 7 问。我，野慢，广东，25岁。白天在大厂做AI产品，晚上被AI教做人。今天这题我替你们问过了，坑也替你们踩了。想让我测哪个AI，评论区点单。我们，下篇见
热门跟贴