OpenAI Codex 技术负责人 Michael Bolin 的职业轨迹，贯穿了过去十多年软件工程基础设施的关键演进。从 Google Calendar 到 Facebook 的 Buck 构建系统、再到虚拟文件系统 Eden，以及如今的 OpenAI Codex，他的每一次转身都带着一个鲜明特征：对现状不满，然后动手重写工具。

在最近一期 The Developing Dev 播客中，Bolin 与主持人 Ryan 展开了一场横跨 20 年工程实践的对话。他回顾了自己从“写 JavaScript 的工程师”到主导开发工具体系的转变，也坦诚讲述了其中的判断失误、能力边界与成长代价。更重要的是，他试图回答一个当下所有工程师都在面对的问题：在 AI 正在重塑开发方式的时代，哪些能力依然值得坚持，哪些又必须被重新理解。

在他看来，真正拉开差距的，从来不是写代码的速度，而是你选择解决什么问题，以及你如何定义“更好的系统”。

一、从工程师到工具创造者：被问题驱动的成长

Bolin 的职业生涯起步于谷歌。当时吸引他的，是谷歌对 Web 的前瞻性理解和对工程质量的追求。他参与了 Google Calendar 项目，做的是面向消费级市场的产品。但他很快发现，在谷歌，产品和基础设施两条业务线之间存在地位差异——搜索和底层基础设施才是公司的核心，而 Calendar 这样的产品更多是“服务支持型”角色。

四年后他选择离开。原因很直接：他发现自己总在那些对自己重要、但对公司未必重要的项目上倾注精力。他喜欢做 Calendar，后来转去做 Google Tasks，用户量小了两个量级，但他依然充满热情。他还为 Closure 工具套件写了本书，投入巨大。但从职业发展的角度看，这确实不是最明智的选择。

“我明明也在处理高质量的工程问题，但获得认可的怎么永远是别人？”他意识到，选择比努力更重要。

离开谷歌后，Bolin 加入 Facebook，当时公司正在全力做手机。他和 HTC 合作，对 Android 进行定制化改造。他接手的 Android 代码库来自外包商，构建系统粗糙、迭代痛苦。他决定自己动手，利用黑客松搞了一套新的构建系统，最终命名为 Buck。

有趣的是，当时几乎所有人都告诉他这是个糟糕的主意。只有一位同事支持他。他做的策略是：不正面冲突，不试图“接管一切”，先做出一个明显更好的版本。性能提升一倍后，大家的态度自然转变了。

Buck 成功的关键，在于他坐下来把谷歌那套工具的实现逻辑从头到尾梳理了一遍，发现它在增量构建场景下性能极差——只要有改动，就从头全部重新构建。他往更底层拆解，引入缓存机制，让没有变化的步骤不需要重复执行。同时把“新增模块”这件事变得极其简单，大家更愿意拆分模块，构建效率进一步提升。

二、选对问题：重构 IDE 和虚拟文件系统

做完 Buck 之后，Bolin 短暂去做了一段时间 iOS Messenger 开发。他不喜欢 iOS，也不适应 Xcode。更重要的是，Facebook 的应用规模始终是最大的，把所有功能塞进一个 App 里统一发布，这让他们总是比其他公司更早撞上移动开发工具的规模瓶颈。

Xcode 无法支撑这样的规模。他们和 Apple 沟通，得到的回应是“那你们的项目就不该这么大”。在这种情况下，自研工具变得有必要。Bolin 的直觉是：IDE 本质上在和编译器、语言服务打交道，完全可以在这之上做一层更好用的“外壳”。

当时公司里已经有另一套 Web IDE，基于一个被放弃的 Google 开源项目，用的是 GWT（Google Web Toolkit）。而 Facebook 已经是 react 的发源地。Bolin 觉得路线选错了，又做了一件和 Buck 类似的事——自己起一个新项目，先聚焦 iOS 场景。最终公司选择了他这条路线，后来变成 Nucleide。

回顾这段经历，Bolin 总结了两个关键：一是技术路线本身要成立，桌面应用在当时比 Web IDE 更实际；二是历史信用——Buck 做成了，大家愿意再赌一次。

晋升到 E8 后，他面临新的挑战。他想解决 Web 加载速度的问题，但这个方向需要数据分析、跨团队沟通和协调，不是他的强项。他尝试编译 V8 引擎、优化 JS 生成机制，最后全都没有结果。

“不同的人适合不同类型的问题。我更擅长从零开始、需要编写大量代码的项目。”这次失败让他明白，要坦然接受自己的局限性。

后来他加入虚拟文件系统项目。Facebook 采用单体仓库模式，所有代码集中在一个仓库里，但多数人实际只用到其中的子集。他们的核心思路是：克隆仓库、切换提交版本时，系统不再需要把所有文件都写入磁盘。通过消除传统文件系统中的默认操作，避免文件数量随仓库规模指数级增长。

Bolin 负责的是预判工具链中那些经常需要读取全部文件的工具，比如 grep。他开发了名为 miles 的文件系统，通过 cron 作业对主分支下的新提交进行索引，仅索引文件名而非内容，实现了快速模糊匹配。在处理超过百万文件的查询时，响应时间只有 10 到 20 毫秒。这套系统后来运行在全球至少 30 台服务器上。

三、AI 正在重塑开发方式：Codex 带来的真实变化

2023 年底，Bolin 面试 OpenAI。当时他在 Meta 负责基于大模型的开发者工具项目，但收到最多的反馈是“为什么不选择用 GPT-4”。他本身不是做模型研究的，更想做的是把这些能力做成产品、做成体验。他觉得，要做这件事，就应该去最好的模型所在的地方。

加入 OpenAI 后，他参与了 Codex 项目的启动。2025 年 4 月 Codex CLI 发布，开源后很快获得一两万颗星。但团队意识到，本地编程智能体虽然更符合当时用户的使用习惯，但长远来看，智能体的未来在云端——比如每当有新的 GitHub issue 进来，就自动触发 agent 去处理，这些任务不可能都跑在笔记本上。

8 月成为一个转折点。GPT-5 问世，他们发布了全新终端界面和 VS Code 扩展，进入疯狂迭代阶段。Codex 的使用量快速增长，如今周活用户已突破百万。

Bolin 自己的 AI 工作流也发生了很大变化。他现在本地会开四五个 Codex 仓库的副本，配合 Codex App 做多任务处理，同时推进多个任务，效率提升明显。他估计，现在模型生成的代码占比已经达到 80% 到 90%。

那剩下的 10% 到 20% 是什么？一类是偏底层的工作，比如 Codex 的 harness 层，用 Rust 写，涉及操作系统层面的细节。另一类是沙箱机制，保障安全性和完整性，确保模型不会突破预设边界。这类工作他更倾向于手动编写，因为必须确保万无一失。

在代码审查方面，Bolin 认同一种方式：让 agent 先做多轮自我审查，直到它自己足够有信心，再交给人来看。最终合入之前，人工审查不会省。但现在大家也开始用 AI 写 PR 总结，这让整个团队的描述质量提升了不少，大大加快了审查流程。

关于开源，Bolin 的理由很简单：这是一个会在本地运行且权限很高的工具，开源让用户可以查看代码、理解其行为，这在 AI 编程领域尤其关键。同时也能获得大量贡献和 bug 报告。

四、当 AI 已经能写 80% 代码，工程师的核心能力是什么

Bolin 建议工程师主动往底层走，去理解系统更底层是怎么工作的。他在做虚拟文件系统项目时，因为不懂 C，专门买了一本操作系统的书从头读到尾。他认为很多人可以在软件工程里走很远，但并不真正理解计算机是怎么工作的——这本身解放了生产力，但也会带来局限。如果你能主动往底层走，很多问题其实可以被重新理解甚至“拆掉”。

他还推荐做 CTF（capture the flag）这类安全竞赛。CTF 像一种“终端里的密室逃脱”，有不同形式的题目，涉及逆向分析、漏洞利用、二进制分析等，会强迫你去接触不同层面的知识，而且比单纯看书更容易坚持下去。

对于 AI 工具快速发展的环境，Bolin 认为应该主动去“往下走”，穿透抽象层，理解系统更底层是怎么工作的，这件事仍然至关重要。因为 agent 的回答质量，最终还是取决于你问的问题质量。如果你问的问题不对，就拿不到一个好的工程解法。

关于扩大影响力，Bolin 总结了三步计划：

1. 搞清楚自己真正喜欢做什么

2. 搞清楚雇主真正看重什么、什么对它来说最有价值

3. 找到这两者的交集，把精力集中在这个交集上

如果这个交集不存在，那就需要换一个环境。

回顾整个职业生涯，Bolin 给年轻自己的建议是：更早敞开心扉学习更多事物，对自己更狠一点。刚入门时，我们会对第一门编程语言抱有偏爱，总想证明它是最好的，但这会成为陷阱。他在 JavaScript 上钻研太深，如果能对其他项目类型保持更多好奇心和灵活性，结果会更好。

写在最后

Michael Bolin 的职业生涯给出了一个清晰的信号：在 AI 能写 80% 代码的时代，工程师的价值不在于写代码的速度，而在于选择解决什么问题，以及如何定义“更好的系统”。

AI 工具正在快速进化，但提出正确问题的能力、穿透抽象层理解底层的能力、以及把想法快速落地成原型的执行力，依然是无法被替代的。

来源：https://www.infoq.cn/article/EOnOWk4bXQ4qUT4u82Bq