Theo：AI 编程时代，维护开发环境成了重要工作

最近我一直在和旧金山圈子之外的工程师讨论 AI 编程，以及工程师的工作意味着什么。我认为这份工作发生了深刻变化。我的比喻是：我们是园丁，负责维护一个让有用代码生长的环境。

我喜欢工程，是因为我们能找到不同部件，把它们组装成有意义的东西。软件有许多层次的积木，从芯片、汇编到编程语言、软件包和模块。我曾担心使用 AI 会夺走这种动手探索的乐趣。

经历这段转变后，我发现新的构建方式和问题让我更加享受。我也知道自己很幸运：软件开发并不是我身份或收入的全部，因此变化对我来说没有那么可怕。

我在 2017 年到 2021 年间为 Twitch 工作。加入视频点播团队后经历了一段困难时期，经理鼓励我尝试 React 和 TypeScript。React Hooks 与我的函数式编程经验相契合，我随后加入了 Twitch 网页产品的重建工作。

那是我第一次觉得自己足够了解一个系统，能够预测改动的影响。在 Twitch，产品团队负责某个用户界面的全部工作，例如聊天、审核工具或创作者仪表盘。

独立的平台团队则为这些产品提供支持。浏览器客户端团队维护共享网页仓库，GraphQL 边缘层连接客户端和服务，其他团队负责数据库和视频基础设施。每个产品团队都自行搭建全部基础设施并不现实。

尽管我属于产品团队，我还是花了很多时间与浏览器客户端团队合作。早期，我根据误导性的文档和示例提交过一个不佳的改动。一位同事问我为什么这样写，然后修正了文档和令人困惑的代码。

这让我看到，不佳的 pull request 可能暴露了需要消除的根本原因。如果误导性示例还在，下一个人很可能犯同样的错误。我也曾在规模较小的内部安全工具仓库中试验想法，再把有效的做法推荐给 Twitch 主站。

我喜欢构建用户实际使用的产品，也喜欢能够改善产品的平台工作。两者的关系是双向的：产品为平台提供反馈，好的平台则帮助产品成长。

代码质量部分是沟通和组织问题。理想情况下，环境应当帮助不同水平的工程师提交不会损害代码库质量的改动。我说的是这种反馈关系，而不只是增加管理或衡量测试覆盖率。

离开 Twitch 创办 Ping 后，我从有许多专业团队的公司变成一个人工作。我的第一反应是重建那些团队维护过的复杂系统，结果同时承担了好几个人的工作，于是必须寻找更简单的方式。

T3 Stack 源于这种需求：我希望获得平台带来的信心，又不承担同样的维护负担。我组合了 Next.js、TypeScript、Prisma 和 tRPC 等现有工具，用共享类型连接前端和后端。我并没有发明这些工具。

构建 Ping、经营公司和频道时，我能用于编程的时间有限。我估计大约一半改动是改进平台，而不是直接改变产品。这些用户看不到的改动让另一半工作更容易交付。

我学会了在两者之间切换：当一个功能比预想中更难实现时，先改进平台，再回来做产品。在 Twitch，跨越产品与平台的界限也让我解决了一些因误以为另一个团队不会同意而陷入僵局的问题。

有一次，我的团队认为 GraphQL 团队不会接受用简单的 JSON 表示仪表盘布局，因此提出了复杂方案。我向平台负责人描述问题，没有暗示解决办法；他独立提出了 JSON 方案。一场对话消除了大量摩擦，而此前讨论花的时间比构建仪表盘还多。

我最后一次大型手写改造是把 T3 Chat 从自建同步引擎迁移到 Convex。我曾对 Convex 持怀疑态度，后来认为它是更成熟的后端、数据库和同步平台。当时智能体还无法替我完成这次迁移。

改动涉及超过 2.5 万行代码，花了约一个月。用户主要会注意到设备之间的同步更可靠。作为大客户，我们遇到了一些特殊问题，Convex 很快处理了它们；但迁移的更大原因是团队。

旧的数据库同步代码只有我一个人理解，因此我经常阻塞同事。迁移到 Convex 后，即使我因手部手术数月无法编程，团队也能继续交付。平台改进让产品工作更容易。

我以前写的代码本身也给团队带来了低质量代码和摩擦。不论摩擦来自人还是智能体，它都可能阻碍下一个在系统中工作的人。

在 Twitch，TypeScript 检查曾耗时 15 到 20 分钟，启动开发服务器需要三到五分钟。我联系了 TypeScript 团队的一位成员，并促成他与 Twitch 浏览器客户端团队交流。这让我看到，身边的工具都是人创造的，也可以改变。

我把这类工作称为园艺：建立一个引导代码朝正确方向发展、提供支持并尽早发现问题的环境。改进 TypeScript 检查也是为了让大家更有信心地检查和修改代码。

最近，即使 TypeScript 已有 Go 重写版，T3 Code 的类型检查仍会占用大量 CPU。过去，即使有数百名 Twitch 工程师受益，重写工具也很难证明划算。现在我正在用 Rust 重写 TypeScript，帮助三人团队更快工作。

在 Twitch，一次 Apollo GraphQL 客户端升级导致数千个文件出错。我们把文件列在共享表格中，分配给志愿者，再逐个手动修复和测试。约八个人加上协助者花了一个多月。我认为智能体现在能以低得多的成本完成这类迁移。

缓慢的开发服务器、检查和发布流程也会阻塞智能体。五分钟的启动时间会延迟反馈，还可能浪费缓存的上下文；慢检查占用资源，限制能够并行执行的任务数量。智能体反复遇到这些摩擦时，平台维护变得更加重要。

糟糕的代码和不必要的测试可能迅速积累，因此需要有人清理它们并处理原因。在 T3 Code，我删除了约一半单元测试：约 1.1 万个测试、25 万行代码。我认为我们没有遇到被删除测试本可捕获的回退，并恢复了其中四个测试。

仅删除还不够。我们调整了给智能体的指导，并留意不良测试是否再次出现。一旦出现，我们会请贡献者查看智能体的对话记录，问它为什么添加测试，再利用解释寻找根本原因。

我还不断看到会话同步协议传输数据量的性能回退。我制作了一个自动 pull request 检查，使用真实事件数据和模拟的端到端流程，报告传输量，并向审查者和智能体标记明显回退。

这项检查告诉智能体，我们关心并希望优化传输量。我估计它运行时间不到 45 秒。我把它看作一根引导植物方向的支架，而不是让质量完全依靠运气。

我在 T3 Chat 的很多工作是通过改进平台来解除团队成员的阻塞。现在我也为智能体做同样的事：观察它们在哪里遇阻，改善周围的代码库和检查。对我而言，这仍然是工程，也是我喜欢做的工作。

我展示了 T3 Code 每天合并 pull request 数量的图表。我说项目从每天约 2 到 20 个，发展到不忙的日子约 60 个、活跃的日子超过 400 个；我将其归因于工作环境的改善。其他人也用园丁比喻观察变更、清除反复出现的问题。

我们还需要继续了解哪些维护方法有效。变化的速度可能令人担忧，但我希望大家也能在使用这些新工具构建产品时找到乐趣。