上周，Will Larson（@Lethain）问大家，管理者如何评估工程经理的 AI 技能。我的回复列出了一些值得思考的问题，被不少人收藏。
其实，关于如何打造 AI 原生工程团队，我已经思考了一段时间。这里分享一下过去九个月在 FurtherAI 的一些实践心得。
第一部分：我们的软件交付方式发生了什么变化
每位工程师的交付量
从一月到现在，每位工程师每天合并的代码变更数增长到了原来的约 5 倍，而回退率一直保持在 0.5% 以下。
但光是给工程师配上编程智能体，并不足以取得这样的结果。
每当我们加快一个环节，工作就会在下一个环节堆积起来。
于是，我们开始逐一梳理软件交付的整个流程，寻找可以优化的地方。
重建交付流程
- 编码（三月）：智能体写代码，工程师把握方向。我们没有准确的起始数据，因为早期工具只是偶尔在变更中留下使用痕迹。但可以肯定的是，现在由智能体编写代码的变更占比已接近 100%。
- 测试（四月）：智能体在写代码的同时编写测试。如今，包含测试的变更占比从 15% 提升到了 91%。
- 评审（五月）：99% 的变更会在人工评审前先经过 AI 评审，之前这一比例是 60%。人工评审者可以专注于需要判断力的部分。
- CI（六月）：我们让测试并行执行，并且只运行受当前变更影响的测试。如今，同样是 17 分钟，CI 能运行的测试数量达到了原来的 20 倍。
- 缺陷报告（七月）：我们开始用 ClaudeTag（@claudeai）自动处理缺陷受理流程。任何人都可以在 Slack 中报告缺陷，ClaudeTag 会识别重复报告、创建工单，并分配给合适的人。现在，60% 的缺陷工单由它创建。
- 规则（八月）：当某个缺陷或评审意见暴露出一条只有工程师才知道的规则时，我们就把它写成一个小型 Python 检查程序，在每次提交和每个 PR 上运行；不符合规则就让构建失败，并输出修复方法。这样，我们就把团队口耳相传的经验变成了明确的规则。智能体遇到这些检查后，会自行修复代码，再继续工作。这样的规则从零增加到了 21 条。如今，低风险变更可以不经人工介入就合并，这些规则功不可没。
- 合并（八月）：通过测试、自动化检查和 AI 评审的低风险变更会自动合并。现在，我们多达三分之一的变更无需人工参与就能完成合并。
- 编程频道（九月）：任何人都可以创建一个 Slack 频道，向智能体描述需要的变更，让它发起 PR。我们还没有这方面的准确数据，但它对协作很有帮助：几个人可以在同一个频道里与同一个智能体合作，随时补充上下文、调整方向。我们也大量使用 Devin（@cognition）的云端会话开展团队协作。
我们还会使用内部开发的 Poirot 和 Sherlock 智能体，调查和解决生产环境与预发布环境中的问题。它们拥有所需的工具和上下文，能够查看日志、指标、追踪数据，并以只读方式访问数据库。
最精彩的一些时刻，是智能体彼此协作的时候：Claude Tag 对请求进行分流，Devin 负责执行，Poirot 则提取所需的内部数据。看着它们互相交流、传递信息，很有意思。
一个有趣的附带变化是，非工程师也开始交付代码了。自八月以来，我们的设计师已经合并了大约 50 项变更，其中包括搭建设计系统的变更。负责部署和直接对接客户的同事，也能直接在 Slack 中自行调整 UI。
我们付出的代价
这些成果并不是白来的。整个夏天，我们的大量工程精力都投入了测试和工具建设，每位工程师每月交付的面向客户的变更数一直在 17 到 30 项之间。
到了九月，这个数字跃升到了 45。按目前的进度，十月预计能达到 48。
第二部分：团队正在发生什么变化
随着工程交付提速，我们开始注意到另一个问题。
新的瓶颈
我们写代码的速度快了很多，但决定要做什么的速度并没有相应提高。
举个简化的例子。
假设过去开发一项功能需要十天：三天规划、六天实现、一天评审。
如果智能体让实现速度提升到原来的 3.5 倍，但规划和评审耗时不变，那么整个功能的交付速度只会提升到原来的 1.75 倍。
规划和评审在总耗时中的占比，就从 40% 上升到了 70%。
传统上，很多此类决策都需要经过工程经理、产品经理和设计师。随着工程师的交付速度越来越快，这种方式会越来越难以维持。
当工程师能够更快地实现功能时，该如何组织团队，才能不让决策和评审成为瓶颈？
我们的选择是让工程师承担更多主导责任。我们不想增加管理层级，而是希望工程师自己负责更多的规划、执行和评审工作。
这也改变了我们对工程师和经理的期待。
这对工程师意味着什么
我开始用一个人能够端到端负责多大范围的问题，来衡量工程师的资深程度。大致来说：
- 初级工程师：能借助智能体完成开发，并能识别它何时出错。
- 高级工程师：能自行规划和评审自己的工作。
- Staff 工程师：能接手一个模糊的问题，作出权衡，并对衡量成效的指标负责。
这也意味着，工程师需要更贴近客户。
我们正在赋予工程师更多权责，让他们负责更多端到端流程：从理解客户问题，到交付解决方案，再到验证成效，并对生产环境中的回归问题负责。
这对经理意味着什么
我们对工程经理的期待也随之改变。
- 深入具体工作。
经理需要理解团队正在做什么、为什么做，以及所选方案是否正确。
我希望经理像最终用户一样，在预发布环境中亲自试用功能，而不只是确认代码已经通过评审。真正使用产品时，你会发现另一类问题。
但目标并不只是增加评审。和以往一样，目标是培养能够独立作出正确决策的工程师，让经理只在确实需要自己判断的事情上介入。
- 更懂产品。
当写代码的成本降低，决定要做什么就重要得多。
我希望工程经理理解客户，有鲜明的产品观点，并且能自如地作出产品决策，而不只是技术决策。
他们也应该帮助工程师培养这种判断力。我们不应该每作出一个小的产品决策，都要找产品经理或设计师。
我们接下来要面对什么
今年的大部分时间，我们都在研究怎样让工程师更快。现在，我们正在研究怎样让整个组织跟上这个速度。
我怀疑，这会比自动化编码、测试和评审更难。
我们仍处于早期阶段，还有很多事情没有想清楚。但这是我参与过的最有意思的工程挑战之一。
我很好奇其他团队看到了什么。当你们的工程师开始更快地交付时，最先出问题的是哪个环节？
我们正在为 @furtheraicom 招聘工程经理／工程总监，共同解决下一阶段的挑战。如果你对此感兴趣，欢迎联系！