现在我一天大概看十几二十个 PR。不是因为团队大，是因为大部分功能开发的流程已经变成了：一句话需求，生成开发规格，交给 agent 走完开发、测试、落地的全流程。
Harness 层足够成熟之后，agent 的执行力不是问题。问题反过来了：人变成了卡点。我的精力最多就只能做到这些，而 agent 那边还有余量。
人类程序员的职责，从来都不是为了写代码而写代码。在面对模糊性、各种限制和不断变化的需求时，把风险降下来，这才是核心。以前写代码的时候如此，现在不怎么写代码了，更是如此。
代码可以不被人读
Joseph Ruscio 最近提了一个概念叫 Write-Only Code：越来越多的生产代码，从写出来到上线，中间没有人类读过它。他的判断是，这不是纪律的缺失，是代码产出的规模已经超出了人类注意力的带宽。他用了一个服务器时代的类比：生产服务器从被精心命名和维护的"宠物"，变成了批量创建、用完即弃的"牲畜"，代码正在走同一条路。
Alex Klos 从另一个角度讲了类似的事：编译器抽象掉了机器，agent 正在抽象掉代码本身。代码不再是人直接操作的对象，意图才是。
我同意这两个观察。但在我自己的实践里，代码层面的风险 agent 基本能自己兜住。测试跑过、类型检查通过、构建没报错，这些 gate 对 agent 来说不难。偶尔有瑕疵，但不是系统性的问题。
真正让我紧张的是上面一层。
产品不能不被人想
正因为落地门槛低了，想法可以很快变成代码、变成功能、变成 PR。但"能做"和"该做"之间有一段距离，这段距离在产能充沛之后反而被拉大了。
做了一段时间之后我发现，有些功能是冗余的。逻辑设计上有可以共用的部分，实体的抽象可以归并，界面上好几个入口做的是差不多的事。一些想法在落地之前没有被充分想透，但因为实现成本太低，它们就直接进了产品。
这就是产能过剩的后果。生产端的效率远远高于消费端的吸收能力，产品很容易走向混沌。
代码可以不被人读，但产品不能不被人想。
这个时候最稀缺的能力不是继续做更多的功能，是收敛：把几个功能合并成一个，把已经落地但没人用的砍掉，把散落在各处的逻辑提炼出共性的抽象。
收敛难在一条线上：过度抽象和抽象不足之间。抽象过了，系统变得难以理解，改一个地方牵动一片；不足，每次新需求进来都在重复造轮子，系统越长越散。这条线画在哪，是人的判断，目前还交不出去。
程序员要做的事其实没变：用足够的逻辑思维，在限制和约束下把需求交付成功能，同时应对后续不断增加甚至互相矛盾的需求，保证新的进来不会把旧的弄坏。只是这件事的载体，从代码上移到了产品。
我的思考
第一，产能过剩之后，瓶颈从生产端转到了价值验证端。 东西造出来了，但能不能解决问题，这件事没有捷径，只能放到真实用户面前去验。agent 能帮你把想法快速变成产品，但"这个想法值不值得变成产品"，它回答不了。
第二，Skill 是人机协作的界面，不是 agent 的草稿本。 一份好的 skill 应该足够简单、描述性强，人能看懂、能审查。它不只是给 agent 的指令，更是人和 agent 对齐工作方式的协议。可读性就是可审查性，这一点在《Skill 的门槛不在写，在拆》里讲过，放到这个语境下同样成立。
第三，在充分的供给下找到对的那个，比从零开始做一个更难。 发散现在很便宜，agent 能快速生成大量方案和实现。但从一堆可能性里收敛到那个对的、可持续的，需要对问题的深层理解和对产品的整体判断。无人阅读的代码会越来越多，这大概不是问题。问题是在产能充沛之后，有没有人还在想，这些代码造出来的东西，到底解决了谁的问题。