Agent 时代，类型系统是最硬的反馈

Ron Minsky 在 Bug Bash 2026 的演讲，题目是“Now more than ever: building reliable software in the age of agents”。光看题目，像是那种“我都说了多少遍了，现在你们该信了吧”的发言。但内容很实在。

他是 Jane Street 的人。Jane Street 是一家全球交易公司，约 3500 人，其中约 2000 人日常写代码。他们的系统承担着美国股票市场约 10% 的交易量。这家公司有个出名的怪癖：主力语言是 OCaml，还嫌不够，往里面加了自己的扩展。交易公司的软件必须可靠——系统直接连着钱包。Ron 提到，他们几年前就开始搞 AI 助手工具，但长期是净生产力消耗，直到去年 11 月模型越过某个阈值，“像是造好了帆船，风突然来了。”

演讲的核心观点：Agent 依赖反馈生存。类型系统是其中最硬的一种反馈。类型系统在代码运行前就拦截错误，不需要测试环境，不需要人介入。对 Agent 来说，一个类型错误就是一个即时、免费、无法争论的评审。有网友在推文评论区总结得比标题还精炼：“类型是唯一一个 Agent 没法甜言蜜语忽悠过去的评审。一个类型错误，它绕不过去；一个 flaky test，它可以。”——时好时坏的测试，Agent 总能找到借口重跑一次。

YouTube 原视频

Ron 讲了几件具体的事。

让非法状态不可表示

make illegal states unrepresentable，OCaml 圈子流传多年的老话。与其在文档里写“这个字段在 refunded 状态下不能改”，不如把状态空间压缩到合法范围内，让编译器强制执行全局规则。Agent 不需要理解业务约束，类型系统从编译层面就把路堵死了。这对 Agent 尤其重要：它少了很多需要猜测的东西。

Expect tests

把程序输出直接打印出来，固化成测试。编译器领域的 fixture tests 一直都是这么干的。Lauren（@poteto）在推文里举了一个例子：React Compiler 的测试 就用了整套这样的 fixture。好处是行为可读，评审时看输出是否合理就行，不用逐行追实现逻辑。

属性测试、模糊测试、确定性仿真

这些方法本身不新。但 Agent 会生成大量代码，而且可能以你没想到的方式破坏系统。属性测试和模糊测试能自动找出边界问题。全系统确定性仿真则把整个系统放进可控环境里跑。靠人盯着 Agent 写的代码，盯不过来，需要机器来盯机器。

形式化验证的性价比变了

seL4 是经典例子：8700 行 C 代码，25 人年，每行 C 配了 23 行证明。过去这笔账怎么算都不划算。Agent 改变了成本结构。形式化验证过去贵在人力，而 Agent 有可能承担其中大量机械性的证明工作。这东西可能从学术奢侈品变成工程选项。

Ron 还提了一个容易被忽略的点：代码评审在 Agent 时代没有消失，反而更关键。评审的重心也在变。除了代码本身对不对，还要看它有没有延续系统的设计意图。

有条推文回复说得更狠：repos are prompts now。代码库就是 Agent 的提示词。代码库的质量，决定了 Agent 输出的质量。

整场演讲最反常识的地方在这里：AI 时代，旧方法的价值反而被放大了。类型系统、测试、评审，这些几十年前就存在的东西，成了更重要的基础设施。