我手里有一个用来处理 Agent 会话记录的命令行工具，平时用来检索历史记录、导出内容，并在每天傍晚自动整理出一份工作日志。
这个工具是我大约一年前用 Python 写的。这一年里，我一直在持续迭代它：陆续支持了更多的 Agent 和各种 Harness 的调用规范，随它们的接口变动调整适配层，补齐各种自己需要的小功能，该做的局部性能优化也顺手做掉了。用 tokei 统计一下，仅核心的 Python 代码就有 180 多个文件、4.5 万多行。除了底层一直基于 Python 技术栈之外，它有完整的自动化测试，在日常工作流里跑得很顺手。
切出那个重写分支的时候，纯粹是一次出于好奇的技术实验。
我想看看在自己完全不懂 Rust 的情况下，如果只把这一套迭代了一年、有 4.5 万行核心逻辑的 Python 代码和全套测试用例扔给 Agent，它究竟能把这套工具迁移成什么样。
我对 Rust 的了解，仅限于听过所有权、生命周期这些概念，既写不出几行像样的代码，更谈不上对它的项目架构有什么指导能力。动手之前，我只是在 Python 版本上跑了一组基准测试，把现有的吞吐耗时、内存占用和输出结果记下来，作为对照基线。
几个小时后，Agent 在那个实验分支上交了卷。
cargo test 跑通了移植过来的全部测试用例。基准测试跑下来，依靠编译型语言底层的天然优势，指标几乎是一边倒的碾压：命令启动耗时从 140 多毫秒直接压到了 5 毫秒，常驻内存从接近 40MB 骤降到 3.5MB，会话列表和导出耗时普遍缩短了数倍甚至十几倍。从功能上看，它百分之百复刻了原有逻辑，并且交出了一份无可挑剔的成绩单。
但我盯着终端里的这些数字，心里却有种说不出的别扭。
点开那堆 .rs 源码，满屏的模式匹配、泛型约束和生命周期标注，我几乎一行都审不动。我甚至没去细看代码的内部组织。按我以前做了十几年软件工程的习惯，把一段自己完全看不懂、在架构上毫无把控的代码合进主干，叫作严重的失职。
但它偏偏能跑，行为毫无偏差。
这种别扭在最近的开发者圈子里越来越普遍。如果连代码我都看不懂了，甚至连架构都不是我设计的，未来该怎么维护？机器生成的这些黑盒，真的能算可靠的软件吗？
其实在更大的开源世界里，这种冲突早已经公开上演过。
之前像 Bun 这样体量巨大、真正跑在生产环境里的核心项目，被尝试或引入 Rust 重写时，曾引发过极大的社区风暴。相比之下，我的命令行工具只是个个人项目，两者在规模和线上风险上根本不可同日而语。但耐人寻味的是当时围绕重写爆发的舆论走向。
讨论很快就溢出了纯粹的技术可行性，演变成了不同语言阵营之间的风格对抗、针对 AI 介入的强烈反弹，甚至夹杂着相当激进的人身攻击。
当时我只是一个隔岸观火的看客，觉得那些争吵多少有些情绪过载。直到面对这个被 Agent 完整重写出的 Rust 分支，我才切身体会到那种情绪背后的神经反射：
那不仅仅是对某种具体语言的偏执，而是所有在传统软件工程范式里浸润多年的程序员，面对自己笃信的手艺在短时间内被全盘颠覆时，本能爆发出的防卫机制。
写了十年以上代码的人，最先感到不适的，往往是失去了对语法的肉身控制。
过去我们花了很多年推敲代码的“品味”：给变量起精准的名字，把重复代码抽成公共函数，严格按照职责拆分模块。这些规矩有非常现实的物理基础：代码过去是人写、人读、人维护的。如果在两个地方写了相同的逻辑，后续改动时人肉很容易漏改，进而引发线上事故。可读性、去重和优雅的抽象，本质上是人类工程师为了对抗自身有限的脑力和记忆力，发明的防错脚手架。
但当代码的维护者变成机器时，这套脚手架的权重就彻底变了。
对模型来说，逻辑重复两次还是重复二十次，不过是上下文里多读几行 Token 的事。只要有测试套件兜底，它在修改时同步所有重复逻辑的成功率，远高于疲倦的人脑。以“让人类肉眼看着舒服”为前提建立的代码审美，在新环境里必须重新估价。
这门手艺并不是第一次经历这种重估。
在 18、19 世纪，如果一个人想要一份自己的肖像，需要请顶级画师耗费几个月时间。画师最值钱的看家本领，是用细腻的笔触把人物面孔描摹得毫发毕现，“画得像”是当时手艺人最高的技术壁垒。摄影术刚出现时，很多画师感到愤怒和不屑，波德莱尔公开痛斥摄影是没有想象力的机械复制，根本不配称为艺术。直到 1900 年柯达推出 1 美元的布朗尼相机，普通人按一下快门就能得到一张清晰的照片。
“画得像”这门手艺在市场上迅速贬值。
但画师并没有因此失业。失去对手工写实的垄断后，画家们被逼着放弃了与镜头的对抗，转而去探索构图、色彩和主观感受。印象派、立体主义、抽象派的大爆发，恰恰集中出现在摄影普及后的那几十年里。
手写代码在今天面临的处境，和当年的“画得像”很接近。它曾经是程序员最重要的护城河，但现在，机器把它变成了一件便宜而迅速的机械产物。
比手艺贬值更深一层的焦虑，是饭碗问题：如果连我不会的语言机器都能直接写出来，以后还要这么多人做软件干什么？
这种恐慌在每一轮技术迭代中都会反复上演。
1970 年代，自动柜员机（ATM）在美国的大型银行逐步铺开。当时的舆论普遍认为，银行柜员这个岗位很快就会彻底消失。推论听起来无懈可击：既然机器随时随地都能存取现金，银行为什么还要雇人坐在柜台后面？
但后来的真实数据给出了完全相反的答案。
经济学家 James Bessen 查阅过当年的历史档案：1985 年，全美约有 6 万台 ATM，柜员有 48.5 万人；到了 2002 年，ATM 增加到 35.2 万台，柜员人数不但没有萎缩，反而增加到了 52.7 万人。
核心原因在于单店成本降下来了。原本开一家网点需要 21 名柜员，有了 ATM 后只要 13 人就能运转。成本大幅降低，促使银行在城市各个街区疯狂增设分支网点。网点总数激增，对人力的总需求不降反升。柜员的工作内容也顺势转变了：机械的点钞交给机器，柜员转去处理更复杂的消费贷款、信用卡和理财咨询。
19 世纪的英国经济学家杰文斯在煤炭上也见过类似的事：当蒸汽机烧煤的效率大幅提高时，英国消耗的煤炭总量并没有减少，反而成倍扩张。一样东西变便宜了，人们会找到更多使用它的地方。
软件世界正在发生同样的事。
每个团队的待办列表底部，都压着一批“值得做但不划算”的需求：给内部后台加细致的操作审计，把臃肿的 Web 视图重写成流畅的原生桌面端，为几个特定用户写一套专属的自动化脚本。这些需求一直排不上期，纯粹是因为工程师的工时太贵了。算完投入产出比后，大家只能选择让系统粗糙地跑着。
当编写代码的边际成本降到几毛钱甚至几分钱时，被压制的需求会迅速涌现。
一个小团队同时维护几个平台的原生客户端，或者为几十个人的小群体做一个专用工具，这些以前算不过账的事情，现在全都可以做。软件的供给不仅不会收缩，反而会迎来一轮剧烈的爆发。写代码的人不必亲手敲每一行代码，但要决定做什么、做到什么程度、怎么证明它做对了。
在这之后，还有一种顾虑更加沉重：我完全看不懂的代码，里面藏着隐蔽的死锁或者漏洞怎么办？放任 Agent 执行命令，删了生产环境数据怎么办？
这些风险是真实的，但面对潜在破坏力的态度，决定了技术的走向。
1945 年 10 月，奥本海默在白宫见杜鲁门，说自己觉得双手沾满了鲜血。杜鲁门事后极为反感，直言不想再在办公室见到这个人。
原子弹确实造成了巨大的灾难。但如果人类因为核裂变具有毁灭性就彻底将核物理封存，后面的世界将是完全不同的模样。在随后的八十年里，核武器再没有在战争中使用过。同一套物理学原理带来了全球数以百计的核电站，为医学界提供了治疗肿瘤的同位素工具，还让旅行者 1 号和 2 号依靠核动力电池在星际空间航行了近半个世纪，至今依然在向地球传回深空的数据。
如果当初因为预见到最极端的结果就停止前行，人类放弃的将是清洁能源和探索深空的全部可能。
面对 Agent 写的代码，正确的态度也是一样的。它确实会产生幻觉，也确实会误删文件或写出有漏洞的代码。解决这些问题的手段不是因噎废食，而是用工程边界去约束它：把运行环境放进沙箱，默认只给只读权限，危险操作必须强制人工确认，每次变更都要过完整的回归测试。
这些划定边界、构建防护网的工作，原本就是工程师最擅长的事。
回顾每一次重大工具的出现，几乎没人能准确预判未来的走向。ATM 刚出现时的失业预言落空了，奥本海默对战后世界的悲观预期也落空了。
在看不清的时候，悲观和乐观所承担的代价并不对称。
如果你选择悲观，抱着对手艺的执念拒绝使用这些工具，一旦技术范式完成重塑，你失去的是在整个转变期积累工程体感的宝贵几年。如果你选择乐观，尽早用它去交付软件，就算后来发现黑盒代码带来了问题，你也是最早知道边界在哪、最早掌握怎么用工程手段修复它的人。
做完那个 Rust 工具的实验后，我给自己的工作流定了一条明确的界限：只要测试覆盖足够完整，基准性能明确跑赢，系统权限被限制在沙箱里，那么就算我完全看不懂源码里的 Rust 语法细节，我也能坦然地把它部署到机器上跑。
不再亲手写代码以后，程序员的工作不再是伺候语法，而是决定该做什么，并用严谨的工程手段证明它做对了。