Sashank Gondala 在 X 上发文：「构建 AI 原生工程组织」 / X

上周，Will Larson（@Lethain）询问领导者如何评估工程经理的 AI 技能。我回复了一份供思考的问题清单，收获了很多书签。Last week Will Larson (@Lethain) asked how leaders are evaluating engineering managers for AI skills. My reply, a list of questions to think about, got a lot of bookmarks.

更广泛地说，我一直在思考如何打造一家原生 AI 的工程组织。分享一些过去九个月在 FurtherAI 构建产品过程中积累的经验。More broadly, I've been thinking about how to build an AI-native engineering org for a while. Sharing some lessons from the last nine months of building at FurtherAI.

第 1 部分：我们交付产品的方式发生了哪些变化Part 1: What changed in how we ship

我们每位工程师交付多少内容How much we ship per engineer

自1月以来，每位工程师每天合并的代码变更数量增长了约5倍，而我们的回滚率始终低于0.5%。Since January, the number of code changes each engineer merges a day has grown about 5x, while our revert rate has stayed under half a percent.

但仅仅给工程师提供编程智能体，并不足以实现我们的目标。But giving engineers coding agents didn't get us there on its own.

每当我们加快一个环节的速度，工作就会堆积到下一个环节。Every time we sped up one step, work piled up at the next.

于是，我们开始一步一步地梳理软件交付的整个流程，并找出可以优化的环节。So we started going through the entire process of shipping software, one step at a time, and figuring out what we could optimize.

重建发货流程Rebuilding the shipping process

• 代码（3月）——智能体编写代码，工程师负责引导。我们没有准确的数据说明这一趋势从何时开始，因为早期这些工具只是偶尔会在某次代码变更中留下痕迹。但可以肯定地说，如今这一比例已接近 100%。
  Code (March) – Agents write the code and engineers steer them. We don’t have a clean number for where this started, as early on the tools only left a mark on a change once in a while. But it’s safe to say it’s now almost 100%.
• 测试（4 月）——智能体在编写代码的同时编写测试。现在 91% 的变更都包含测试，高于之前的 15%。
  Tests (April) – Agents write tests alongside code. 91% of changes now include tests, up from 15%.
• 审查（5月）——在人类审查之前，AI 审查的变更比例从 60% 升至 99%。人工审查者可以专注于需要判断力的部分。
  Review (May) – AI reviews 99% of changes before a person does, up from 60%. Human reviewers can focus on the parts that need judgment.
• CI（六月）——我们将测试并行化，并且只运行受变更影响的测试。CI 现在在同样的 17 分钟内运行的测试数量是原来的 20 倍。
  CI (June) – We parallelized tests and run only those affected by a change. CI now runs 20× the tests in the same 17 minutes.
• 缺陷报告（7 月）——我们开始使用 ClaudeTag（@claudeai）自动处理缺陷受理流程。任何人都可以在 Slack 中报告缺陷，ClaudeTag 会识别重复报告、创建工单，并分配给合适的人员。目前，60% 的缺陷工单由它创建。
  Bug reports (July) – We've started using ClaudeTag (@claudeai) to automate our bug intake process. Anyone can report a bug in Slack, and ClaudeTag figures out duplicates, files a ticket, and assigns it to the right person. It now files 60% of bug tickets.
• 规则（8月）——当 bug 或审查评论暴露出一条只有工程师才知道的规则时，我们就把它变成一个小型 Python 检查，在每次提交和每个 PR 上运行；检查失败时会使构建失败，并打印出修复方法。这样，我们就把隐性知识转化成了规则。智能体遇到这些检查后，会修复自己的代码并继续推进。我们的规则从零增加到了 21 条。这是如今低风险变更可以无需人工介入就合并的重要原因之一。
  Rules (August) – When a bug or a review comment exposed a rule only engineers knew, we turned it into a small Python check that runs on every commit and every PR, fails the build and prints the fix. This way, we convert tribal knowledge into rules. Agents hit these checks, fix their own code and move on. We went from zero to 21 rules. They're a big part of why low-risk changes can now merge without a person.
• 合并（8 月）——通过测试、自动化检查和 AI 审查的低风险更改会自动合并。如今，我们多达三分之一的更改无需人工参与即可合并。
  Merging (August) – Low-risk changes that pass tests, automated checks, and AI review merge on their own. Up to a third of our changes now merge without a person involved.
• 代码频道（9月）——任何人都可以开设 Slack 频道，向智能体描述一项变更，然后让它创建 PR。我们目前还没有准确的数据来衡量这一点，但这种方式非常有利于协作：多人可以在同一个频道中与同一个智能体协作，在过程中补充上下文并引导它。我们也大量使用 Devin（@cognition）的云端会话来进行团队协作。
  Code channels (September) – Anyone can open a Slack channel, describe a change to an agent, and have it open a PR. We don't have a clean number for this yet, but it's been great for collaboration: several people can work with the same agent in one channel, adding context and steering it as it goes. We also heavily use Devin's (@cognition) cloud sessions to collaborate as a team.

我们还使用内部的 Poirot 和 Sherlock 智能体来调查并解决生产环境和预发布环境中的问题。它们拥有所需的全部工具和上下文，可以访问日志、指标、追踪数据以及只读数据库。We also use our in-house Poirot and Sherlock agents to investigate and resolve issues across production and staging. They have all the tools and context they need across logs, metrics, trace and read-only database access

最精彩的时刻之一，就是多个智能体协同工作的时候。Claude Tag 对请求进行分流，Devin 负责执行任务，Poirot 则调取所需的内部数据。看着它们彼此交流、传递信息，真的很有趣。Some of the best moments are when agents work together. Claude Tag triages a request, Devin does the work, and Poirot pulls the internal data it needs. It's fun to watch them talk to each other and pass information along.

一个有意思的连带效应是，非工程师也开始提交代码了。自 8 月以来，我们的设计师已经合并了约 50 项更改，其中包括构建我们设计系统的那些更改。负责部署和面向客户的岗位人员也可以直接在 Slack 上自行调整 UI。One interesting side effect is that non-engineers have started shipping code too. Our designer has merged about 50 changes since August, including the ones that built our design system. People in deployment and customer-facing roles can also make UI tweaks themselves right from slack

它给我们带来的代价What it cost us

这一切都不是没有代价的。整个夏天，我们的大部分工程投入都花在了测试和工具开发上，每位工程师每月面向客户的改动数量保持在 17 到 30 项之间。None of this was free. Through the summer, much of our engineering effort went into tests and tooling, and customer-facing changes per engineer stayed between 17 and 30 a month.

9 月，这一数字跃升至 45。10 月预计将达到 48。In September, that jumped to 45. October is on pace for 48.

第二部分：团队正在发生哪些变化Part 2: What's changing in the team

随着工程进度加快，我们开始注意到另一个问题。As engineering got faster, we started noticing a different problem.

新的瓶颈The new bottleneck

我们编写代码的速度大幅提升了，但决定要构建什么的速度却远远没有那么快。We got much faster at writing code, but not nearly as fast at deciding what to build.

下面是一个简化示例。Here's a simplified example.

假设一项功能过去需要十天：三天规划、六天开发、一天审核。Say a feature used to take ten days: three to plan, six to build, and one to review.

如果智能体让构建速度提升 3.5 倍，但规划和评审耗时不变，那么整个功能的交付速度只提升 1.75 倍。If agents make building 3.5× faster, but planning and review stay the same, the overall feature only gets 1.75× faster.

规划和审核现在占用了 70% 的时间，高于之前的 40%。Planning and review now account for 70% of the time, up from 40%.

传统上，许多这类决策都由工程经理、产品经理和设计师层层传递。随着工程师的效率越来越高，这种方式会变得越来越难以为继。Traditionally, a lot of these decisions flow through engineering managers, PMs, and designers. That becomes increasingly difficult as engineers get faster.

如何组织团队，才能让工程师大幅提升开发速度，同时避免决策和评审环节形成瓶颈？How do you organize a team where engineers can build much faster, without creating bottlenecks around decisions and reviews?

我们的选择是让工程师承担更多责任。与其增加更多管理层级，我们更希望工程师自己负责更多规划、执行和评审工作。Our bet is to push more ownership to engineers. Rather than adding more layers of management, we want engineers to handle more of the planning, execution, and review themselves.

这改变了我们对工程师和管理者的期待。That changes what we expect from engineers and managers.

这对工程师意味着什么What it means for engineers

我开始从一个人能够端到端负责多大范围的问题，来思考工程师的资历。大致来说：I'm starting to think of engineering seniority in terms of how much of a problem someone can own end to end. Roughly:

• 初级工程师——借助智能体进行构建，并能判断它何时出错。
  Junior engineer – Builds with an agent and can tell when it's wrong.
• 高级工程师——规划并审查自己的工作。
  Senior engineer – Plans and reviews their own work.
• Staff 工程师——面对模糊的问题，权衡取舍，并对衡量成效的指标负责。
  Staff engineer – Takes a vague problem, makes the tradeoffs, and owns the number that says whether it worked.

这也意味着工程师需要更加贴近客户。It also means engineers need to be closer to customers.

我们正在赋能工程师，让他们能够端到端地承担更多流程：从理解客户问题，到交付解决方案，再到验证成效，并负责处理生产环境中的回归问题。We're empowering engineers to own more of the process end-end, from understanding the customer problem to shipping a solution to verifying success and owning regressions in production.

这对管理者意味着什么What it means for managers

这也改变了我们对工程经理的期待。This also changes what we expect from engineering managers.

1. 投入到工作中。1. Be in the work.

管理者需要了解正在构建什么、为什么要构建，以及这是否是合适的解决方案。Managers need to understand what's being built, why, and whether it's the right solution.

我希望管理人员能像最终用户一样在预发布环境中试用功能，而不只是检查代码是否经过审查。实际使用产品时，你会发现另一类问题。I want managers trying features on staging as an end user would, not just checking that the code was reviewed. You catch a different class of problems when you actually use the product.

但目标并不只是增加审查量。一如既往，目标是培养能够自行做出正确决策的工程师，让管理者只在需要他们判断的事项上介入。But the goal isn't just to review more. As always, it's to develop engineers who can make the right decisions themselves, so managers only step in on the ones that need their judgment.

2. 提升产品敏锐度。2. Be more product-savvy.

编写代码的成本降低后，决定要构建什么就变得重要得多。When writing code becomes cheaper, deciding what to build matters a lot more.

我希望工程经理能够理解客户、对产品有自己的见解，并且乐于做出产品决策，而不只是技术决策。I want engineering managers who understand customers, have strong product opinions, and are comfortable making product decisions, not just technical ones.

他们还应帮助工程师培养这种判断力。我们不应该事事都需要产品经理或设计师来做决定，即使是很小的产品决策也不例外。They should also help engineers develop that judgment. We shouldn't need a PM or designer to make every small product decision.

这让我们处于什么境地Where this leaves us

今年大部分时间，我们都在摸索如何提升工程师的效率。现在，我们正在探索如何让整个组织都以同样的速度运转。We spent most of this year figuring out how to make engineers faster. Now we're trying to figure out how to make the entire organization move at that speed.

我怀疑，这会比自动化代码、测试和评审更难。I suspect this will be a harder problem than automating code, tests, and reviews.

我们仍处于早期阶段，还有很多问题尚未解决。但这是我参与过的最有趣的工程挑战之一。We're still early, and there's a lot we haven't figured out. But it's one of the most interesting engineering challenges I've worked on.

我很好奇其他团队的情况。随着工程师们开始更快地交付，最先出问题的是什么？I'm curious what other teams are seeing. What broke first as your engineers started shipping faster?

我们正在 @furtheraicom 招聘工程经理/总监，共同应对下一波挑战。如果你对此感兴趣，欢迎联系我们！We're hiring Engineering Manager / Director at @furtheraicom to solve the next wave of challenges. If this sounds interesting, reach out!