造出 Claude Code 的人说：我一年没写一行代码，每天提交 150 个

晚上十一点，一个人坐在一排屏幕前。

左边五到十个会话同时在跑，下面的 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，评论区点单。我们，下篇见