How building software is changing at AnthropicAnthropic 的软件构建方式正在发生怎样的变化
A deepdive on what’s changed in how the leading AI lab makes software. Ever more code review and testing is done by AI, two-pizza teams very much alive, and more. Details from inside of Anthropic深入剖析这家领先的 AI 实验室在软件开发方式上的变革。AI 正在承担越来越多的代码审查与测试工作，“两个披萨团队”原则依然稳固，等等。来自 Anthropic 内部的详细内幕。
Much-improved AI tooling is changing how we build software, and I want to take a peek into how the future of software engineering may unfold under its influence. What better place for that than with tech’s most “AI-pilled” teams: the AI labs themselves.日益完善的 AI 工具正在改变我们构建软件的方式。我想借此机会一窥 AI 影响下软件工程的未来走向。还有什么地方比科技界最“沉迷 AI”的团队——即 AI 实验室本身——更适合进行这项探索呢？
So, I visited the two leading AI labs to see how teams and engineers do things day to day. In this article and in an upcoming follow-up, I’ll share what I learned about how AI is reshaping software engineering principles many of us are accustomed to – and what’s stayed mostly the same despite the AI wave.因此，我走访了两家领先的 AI 实验室，观察团队和工程师们的日常工作方式。在本文及后续文章中，我将分享我所了解到的 AI 如何重塑我们习以为常的软件工程原则，以及在 AI 浪潮下依然保持不变的内容。
In a later article, we’ll compare findings from Anthropic and OpenAI to see what their ways of working might mean for the overall direction of software engineering.在后续文章中，我们将对比 Anthropic 和 OpenAI 的研究发现，看看他们的工作方式对软件工程的整体方向意味着什么。
Thanks to Anthropic for showing me inside their lab in San Francisco. I talked with four people:感谢 Anthropic 让我参观了他们位于旧金山的实验室。我与四位成员进行了交流：
Katelyn Lesse, Head of Engineering for Claude Platform, whose organization owns the infrastructure that Claude runs onKatelyn Lesse，Claude 平台工程负责人，其团队负责 Claude 运行所需的基础设施
Jarred Sumner, creator of Bun, now at Anthropic on Bun and Claude CodeJarred Sumner，Bun 的创始人，目前在 Anthropic 负责 Bun 和 Claude Code
Thariq Shihipar, who works across Claude Code engineering and educationThariq Shihipar，负责 Claude Code 的工程与教育工作
David Hershey, at Anthropic’s Applied AI organization in a role resembling a sales engineer, working with customers like Cursor, Cognition, and PerplexityDavid Hershey，就职于 Anthropic 应用 AI 部门，担任类似于销售工程师的角色，与 Cursor、Cognition 和 Perplexity 等客户合作
Thanks to them, I got a sense of where things are headed at the leading AI lab – and possibly for the wider industry.多亏了他们，我得以了解这家领先 AI 实验室的发展方向，以及整个行业可能的发展趋势。
Before we continue, The Pragmatic Engineer will be on summer break for the next week and a half. This means no Thursday article this week, and no articles next week. I appreciate your understanding and support!在继续之前，先告知大家：《The Pragmatic Engineer》将在未来一周半进行暑假休刊。这意味着本周四没有文章，下周也不会更新。感谢您的理解与支持！
Back to today’s deepdive, we cover:回到今天的深度报道，我们将涵盖以下内容：
Complex & long: Claude Managed Agents. One of the most complicated projects took the Claude Platform team six months to ship, and created a new primitive to use at the agent infra level. Infra projects still need re-architecting mid-way through and take time to get right.复杂且漫长的项目：Claude Managed Agents。Claude 平台团队最复杂的项目之一耗时六个月才发布，并为代理基础设施层面创建了一个新的原语。基础设施项目在进行到一半时仍需重构，且需要时间来打磨。
Twelve-month project done in 11 days: Bun rewrite to Rust. Migrating a 500K+ line project to another language used to take a small team a year, making it impractical. With Fable and $165K of tokens, it recently took the creator of the project less than two weeks.十二个月的项目在 11 天内完成：Bun 重写为 Rust。将一个 50 万行以上的项目迁移到另一种语言，过去通常需要一个小团队耗时一年，这在实践中几乎不可能。借助 Fable 和 165,000 美元的 Token，该项目的创始人最近仅用了不到两周就完成了。
Changing engineering practices. Inside the AI lab with more than 3,500 employees, prototyping is more fluid, verification is more time-consuming than implementation, code review and testing are increasingly done by AI.工程实践的变革。在拥有超过 3500 名员工的 AI 实验室里，原型设计更加灵活，验证比实现更耗时，代码审查和测试正日益由 AI 完成。
Team-level changes. Design is more ongoing and less upfront, teams work on more projects, a maximum of two engineers per project, and more.团队层面的变化。设计工作更加持续化，而非前期集中式；团队负责的项目更多；每个项目最多配备两名工程师，等等。
Still the same: two-pizza teams, planning is important, PRDs are relevant in complex projects, context switching is a challenge, the ratio of time spent on coding vs testing not changing that much.依然不变的：两个披萨团队原则、规划的重要性、复杂项目中的 PRD（产品需求文档）、上下文切换的挑战，以及编码与测试时间的比例并未发生太大变化。
Changing the “standout” software engineer archetype? Deep understanding, including of a layer below what you work on, is valuable, along with the ability to coordinate work.“杰出”软件工程师的原型是否在改变？深度理解能力（包括对自己所处层级之下的理解）以及协调工作的能力依然极具价值。
Will AI replace software engineering? The more hands-on software engineers get with AI at the lab, the less they fear their jobs are going away.AI 会取代软件工程师吗？实验室的软件工程师在 AI 实践中投入得越多，他们就越不担心自己的工作会消失。
1. Complex & long: Claude Managed Agents1. 复杂且漫长的项目：Claude Managed Agents
The Claude Platform team’s most complex project in the past year was building Claude Managed Agents, a pre-built harness for production agents that runs in the cloud on infrastructure managed by Anthropic, or on your team’s own infrastructure, with any sandbox you choose. The project took around six months from idea until launch in April. Katelyn Lesse, head of engineering for Claude Platform, shared the story.Claude 平台团队过去一年中最复杂的项目是构建 Claude Managed Agents。这是一个用于生产环境代理的预构建框架，运行在 Anthropic 管理的云基础设施上，或者运行在用户团队自己的基础设施上，并支持任何你选择的沙箱。该项目从构思到 4 月份发布大约耗时六个月。Claude 平台工程负责人 Katelyn Lesse 分享了其中的故事。
Claude PlatformClaude 平台
This team sits between the model/accelerator layer (Claude models operate on GPUs) and the product/application layer (with products like Claude Code and Claude Cowork):该团队位于模型/加速器层（Claude 模型在 GPU 上运行）与产品/应用层（如 Claude Code 和 Claude Cowork 等产品）之间：
Katelyn on what the Platform team does:Katelyn 谈及平台团队的工作：
“We’re on the ‘token hot path.’ The prompt comes in, then we tokenize it. Then, things like safeguards and billing all happen within our layer.”“我们处于‘Token 热路径’上。提示词进入后，我们对其进行 Token 化处理。随后，安全防护和计费等环节都在我们的层级内完成。”
What the Claude team calls “Platform,” I think more of as “API.” Claude Platform operates the API, and owns responsibilities an API would have. Of course, the team does more than that, and Claude Managed Agents is one case we cover here.Claude 团队所说的“平台”，我认为更接近“API”。Claude 平台运营 API，并承担 API 应有的职责。当然，团队所做的不止于此，Claude Managed Agents 就是我们在此讨论的一个案例。
The platform layer is being migrated from Python to Rust. Originally, this layer was written for Python for the “usual” reasons at AI companies: it’s a convenient language and AI researchers use Python already, which enables quick iteration. But Python is single-threaded, and at scale, when the API is under high load, it’s not as performant as Rust.平台层正从 Python 迁移到 Rust。最初，该层使用 Python 是因为 AI 公司常见的理由：它是一种便捷的语言，且 AI 研究人员已经在使用 Python，这有助于快速迭代。但 Python 是单线程的，当 API 在大规模高负载下运行时，其性能不如 Rust。
Harness infrastructure demand框架基础设施需求
The project came together due to customers wanting their own “harness infrastructure”, says Katelyn:Katelyn 表示，该项目的产生源于客户需要自己的“框架基础设施”：
“We started with a model where you get an API to define an agent, then you get an API to start a session with an agent. The reality of what the world wants and needs right now is people running their own infrastructure. So, we started to build a self-hosted sandbox.“我们最初的模型是：你获得一个 API 来定义代理，然后获得一个 API 来开启与代理的会话。但现实是，人们现在需要运行自己的基础设施。因此，我们开始构建自托管沙箱。
But then, what we started to hear from lots of customers is that they’re trying to hack harnesses together, running their own “harness infrastructure,” and this gave us the idea for Claude Managed Agents.”但随后我们从许多客户那里听到，他们正在拼凑各种框架，运行自己的‘框架基础设施’，这给了我们构建 Claude Managed Agents 的灵感。”
The largest part: planning最重要的一环：规划
In this project, Katelyn said the single biggest matter was planning:Katelyn 说，在这个项目中，最重要的事情就是规划：
“There are products you can jump straight to prototyping, but then there are ones where you need to start by architecting it properly. For example, if we build a TypeScript CLI – which is pretty trivial for what needs to be built – we could go straight to prototyping. But with Claude Managed Agents, we needed to first figure out what we are doing.“有些产品你可以直接进入原型设计阶段，但有些则需要从架构设计开始。例如，如果我们构建一个 TypeScript CLI——对于所需构建的内容来说相当简单——我们可以直接开始原型设计。但对于 Claude Managed Agents，我们需要先弄清楚自己在做什么。
Of course, we did some upfront prototyping for Managed Agents: hacking and spiking things. But prototyping itself was more about understanding the requirements.当然，我们确实为 Managed Agents 做了一些前期原型设计：进行黑客式开发和探究。但原型设计本身更多是为了理解需求。
Our planning process looked more like a typical pre-AI planning process. You know how every team has the project, where everyone comes up with some version of the same idea and people keep floating and circling it around until you finally do it? Managed Agents was this for our team. When we started the project, we had documents dating back up to two years about ideas and suggestions.我们的规划过程看起来更像 AI 出现之前的典型流程。你知道每个团队都有那种项目吗？大家提出了同一个想法的各种版本，人们不断地讨论、兜圈子，直到最终付诸实践。Managed Agents 对我们团队来说就是这样。当我们启动项目时，我们已经拥有了长达两年的关于想法和建议的文档。
Post-planning, when the project officially kicked off, a PRD (product requirements document) was created:规划完成后，项目正式启动，并创建了 PRD（产品需求文档）：
“In the end, it was the Product Manager and the Tech Lead on our API Agents team who decided to pull the trigger and kick off this project. We’d get in a room, go through it, and get aligned. But it wasn’t just us: we’d have to align with teams around the business, other cloud providers, and other engineering teams. For example, we have a sandboxing team inside of the Platform org: and so this team was consulted on the design of Managed Agents, given this product would spawn a lot of sandboxes.“最终，是我们 API 代理团队的产品经理和技术主管决定扣动扳机，启动这个项目。我们聚在一起，梳理流程并达成共识。但这不仅仅是我们：我们必须与公司内部的其他团队、其他云服务商以及其他工程团队保持一致。例如，我们在平台组织内部有一个沙箱团队：鉴于该产品会生成大量沙箱，我们咨询了该团队关于 Managed Agents 的设计。
Just like before, we had a PRD, it was a Google Doc. We used a Google Doc because we needed to coordinate all interested people. This has not gone away.就像以前一样，我们有 PRD，它是一个 Google Doc。我们使用 Google Doc 是因为我们需要协调所有相关人员。这一点并没有改变。
Similarly, my product counterpart and I run product reviews.”同样，我和我的产品负责人会定期进行产品评审。”
Some processes from before AI, like the PRD, are still useful in complex projects today, for getting large groups of people on the same page.一些 AI 出现之前的流程（如 PRD）在今天的复杂项目中依然有用，有助于让大型团队达成共识。
Build for an internal customer first首先为内部客户构建
With planning complete, the team decided to do a “spike” and stress-test the idea and architecture, by building the backend of Claude Code on the web. Remote execution of code with an agent harness was a similarly shaped problem to the one they wanted to solve for customers. The thinking was to start by solving it for the Claude Code team before tackling it in a more generic way for customers.规划完成后，团队决定进行一次“探究（spike）”，通过在 Web 上构建 Claude Code 的后端来压力测试这一想法和架构。使用代理框架进行远程代码执行，与他们想要为客户解决的问题本质相似。他们的想法是先为 Claude Code 团队解决这个问题，然后再以更通用的方式为客户解决。
Internal teams are more fluid than before AI. Katelyn:内部团队比 AI 出现前更加灵活。Katelyn 说道：
“Pre-AI, we might have hit the Claude Code team up with a bunch of big requirements documents, and they would have then hit us back with another set of documents. Now it was much easier: someone on our team built a few components, took it over to the Claude Code team, and they started to hack around it. We could figure out how this component plugs into this part of their product, and the other way around. It was just a faster and easier process, getting this first internal version of the product up and running.“在 AI 之前，我们可能会向 Claude Code 团队发送一堆厚重的需求文档，而他们会回以另一套文档。现在容易多了：我们团队有人构建了几个组件，带给 Claude Code 团队，他们就开始围绕这些组件进行开发。我们可以弄清楚这个组件如何接入他们产品的特定部分，反之亦然。这是一个更快、更简单的过程，让我们得以快速建立起产品的第一个内部版本。
Aligning with other teams on interfaces remains important, and it’s easier. Back in the day, you’d have to come with a fully spec’d interface to use. Now, we could do it a lot more fluidly: we could stand up a stub service that shadowed traffic to start with, and iron out the interfaces with the Claude Code team as we went. They did some hacking on it and gave feedback, we made changes while building out the service under the interface, then went back to make it work.”与其他团队在接口上保持一致仍然很重要，而且现在更容易了。过去，你必须提供一个完全规范的接口。现在，我们可以更灵活地进行：我们可以先建立一个存根服务来模拟流量，并在开发过程中与 Claude Code 团队不断完善接口。他们进行了一些尝试并给出了反馈，我们在接口下方构建服务的同时进行修改，然后再回头进行适配。”
They launched a service for Claude Code’s mobile app to spin up a sandbox, boot up Claude Code and run it. The service went to production and the Claude Platform team took the learnings.他们为 Claude Code 的移动端应用发布了一个服务，用于启动沙箱、引导并运行 Claude Code。该服务已投入生产，Claude 平台团队从中汲取了经验。
Re-architecting midway through中途重构
It’s likely a familiar scenario many engineers can relate to, that after planning a project and getting underway, you see that you’re going to need to change the architecture. It happened on this project, too.许多工程师可能都有过这种经历：在规划项目并开始实施后，发现需要更改架构。这个项目也不例外。
The platform team ended up re-architecting Managed Agents based on learnings from the Claude Code “spike.” Re-architecting meant decoupling the “brain” of Claude and its harness from the “hands” (sandboxes & tools that perform actions) and the “session” (the log of events). Each became an interface that made few assumptions about each other.平台团队最终根据 Claude Code “探究”中的经验对 Managed Agents 进行了重构。重构意味着将 Claude 的“大脑”及其框架与“手”（执行动作的沙箱和工具）以及“会话”（事件日志）解耦。每一部分都成为了一个接口，且彼此之间几乎没有预设依赖。
The team also built an abstraction around vaults and credentials. Credentials can safely be stored inside a vault. All calls using credentials are made via a proxy which has a session token. It is the proxy that fetches the right credentials from the vault: the credentials are never seen by the agent, sandbox, or session. Credentials are only injected at the egress boundary when the service is invoked:团队还围绕保险库和凭据构建了一个抽象层。凭据可以安全地存储在保险库中。所有使用凭据的调用都通过具有会话令牌的代理进行。是代理从保险库中获取正确的凭据：代理、沙箱或会话永远不会看到这些凭据。凭据仅在服务被调用时的出口边界处注入：
Internal “dogfooding” helped surface hard problems to solve. A few examples:内部的“狗粮”测试（dogfooding）有助于发现需要解决的棘手问题。几个例子：
Reliability and scalability: these are really hard to do well for agents because if connection to the sandbox is lost, the whole agent dies and you lose state可靠性和可扩展性：这对代理来说非常难做好，因为如果与沙箱的连接断开，整个代理就会死亡，状态也会丢失。
Credentials and access control: also hard and problematic, especially when first building the service凭据和访问控制：在最初构建服务时，这也是一个棘手且充满问题的地方。
The Managed Agents team shared more about this re-architecting project.Managed Agents 团队分享了更多关于这个重构项目的信息。
The project took about six months, by no means a rapid process. Katelyn emphasized that pre-AI, a project like this would have probably been in the realm of two years. Managed Agents is one of the biggest projects the Claude Platform team has built, and more complex than it looks: for example, adding support for running agents on AWS, GCP and Azure.该项目耗时约六个月，绝非快速过程。Katelyn 强调，在 AI 之前，这样的项目可能需要两年时间。Managed Agents 是 Claude 平台团队构建的最大项目之一，其复杂程度远超表面：例如，增加了在 AWS、GCP 和 Azure 上运行代理的支持。
2. Twelve-month project done in 11 days: Bun rewrite to Rust2. 十二个月的项目在 11 天内完成：Bun 重写为 Rust
As covered before, Jarred Sumner is the creator of Bun, a popular JavaScript runtime with 22 million monthly downloads currently and Claude Code as a dependency.如前所述，Jarred Sumner 是 Bun 的创建者，这是一个流行的 JavaScript 运行时，目前每月下载量达 2200 万次，并将 Claude Code 作为其依赖项。
Bun is written in Zig, a performant, productive language. However, it’s not memory safe and memory issues kept coming up. Jarred thought that rewriting the project to an also-performant, memory-safe language like Rust could be an option – except that rewrites like this turned out as follies in the past. Jarred (emphasis mine:)Bun 是用 Zig 编写的，这是一种高性能、高生产力的语言。然而，它不具备内存安全性，内存问题层出不穷。Jarred 认为将该项目重写为一种同样高性能且具备内存安全的语言（如 Rust）是一个选择——但这种重写在过去往往被证明是愚蠢的。Jarred（重点由我标注）：
“Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig. A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time. The least risky approach to getting something shippable would be a mechanical port from Zig to Rust, with the minimal number of behavioral changes, using the exact same test suite we already use for testing Bun.“从历史上看，重写是个糟糕的主意。除去注释，Bun 有 535,496 行 Zig 代码。用另一种语言重写需要一个小团队耗时整整一年。这意味着在那段时间里，必须冻结错误修复、安全补丁或功能开发。实现可交付成果风险最小的方法是进行从 Zig 到 Rust 的机械移植，尽可能少地改变行为，并使用我们现有的同一套测试套件来测试 Bun。
Fortunately, Bun’s own test suite is written in TypeScript which means it doesn’t depend on the runtime’s programming language.幸运的是，Bun 自己的测试套件是用 TypeScript 编写的，这意味着它不依赖于运行时的编程语言。
A year of zero user-facing impact was not an option we could consider. So, enforcement through code style to fix stability issues was our best bet, and was our plan when we added Rust-inspired smart pointers to Bun’s codebase.一年内对用户零影响是不可能的。因此，通过代码风格强制执行来修复稳定性问题是我们最好的选择，这也是我们向 Bun 代码库添加 Rust 风格智能指针时的计划。
But honestly, I didn’t want to do it. Homegrown smart pointers offer worse ergonomics than Rust, with none of the guarantees.”但老实说，我不想这样做。自制的智能指针在人体工程学上比 Rust 差，而且没有任何保证。”
But then, Jarred asked if AI could do the heavy lifting and wondered how much the migration could be sped up. In the end, he completed the rewrite from start to merge in 11 days, using 64 parallel agents and $165,000 in tokens at API price. Here’s Jarred on how his AI-heavy rewrite compared:但随后，Jarred 询问 AI 是否可以承担繁重的工作，并思考迁移速度能提高多少。最终，他仅用了 11 天就完成了从开始到合并的重写工作，使用了 64 个并行代理，并花费了 165,000 美元的 API Token。以下是 Jarred 对他这次 AI 密集型重写的评价：
“By hand, I think this would’ve taken three engineers with full context on the codebase about a year, during which time we wouldn’t be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would’ve done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.”“如果是手工完成，我认为这需要三名对代码库有充分了解的工程师耗时一年，在此期间我们无法提升 Node.js 兼容性、修复错误、修复安全问题或实现新功能。我们绝不会那样做。现实的选择是无所作为，并继续修复本文开头提到的那些错误。”
There was a lot more to the project than typing out the “...make zero mistakes” prompt:这个项目不仅仅是输入“……做到零错误”的提示词那么简单：
Jarred made a detailed plan and style guide on how to migrateJarred 制定了详细的计划和迁移风格指南
He set up the project so agents would not use Git worktrees which he found slow, but worked on different files in the same codebase他设置了项目，使代理不会使用他认为速度较慢的 Git 工作树，而是在同一个代码库的不同文件上工作
He created an orchestration system where each AI agent came up with suggestions of what to change, but did not make a change to the file to avoid conflicts; an orchestrator AI agent created the commits他创建了一个编排系统，其中每个 AI 代理都会提出修改建议，但不直接修改文件以避免冲突；由一个编排 AI 代理负责创建提交
The most time and tokens went on fixing the compile bugs, tests, and verifying that things worked最耗时和最耗费 Token 的部分是修复编译错误、测试以及验证功能是否正常
Bun itself has a very robust test harness: when all tests pass, it’s a high-confidence signal that the rewrite worksBun 本身拥有非常强大的测试框架：当所有测试通过时，这是一个重写成功的强有力信号
Crucially, Jarred is the ultimate domain expert in Bun: he created the project and knows the codebase better than anyone至关重要的是，Jarred 是 Bun 的终极领域专家：他创建了这个项目，比任何人都更了解代码库
The rewrite has been shipped to production and powers Claude Code today.该重写版本已投入生产，目前为 Claude Code 提供支持。
We cover a lot more on this in What can we learn from Bun’s rapid Rust rewrite with AI?我们在《从 Bun 的快速 Rust 重写中我们可以学到什么？》一文中对此有更深入的探讨。
3. Changing engineering practices3. 工程实践的变革
So, what has changed in how teams build software at Anthropic, compared to the pre-AI days? That’s the question of this article, and it seems that many things are different. Let’s go through it:那么，与 AI 出现之前相比，Anthropic 团队构建软件的方式发生了什么变化？这是本文的核心问题，看起来确实有很多不同之处。让我们逐一审视：
AI lab-specific practicesAI 实验室特有的实践
Some things as normal as breathing at AI labs like Anthropic stand out as different with an outside perspective:在 Anthropic 这样的 AI 实验室里，一些习以为常的事情从外部视角来看显得非常不同：
Everyone runs multiple AI agents all the time. Running 3-10 parallel agents is a given. Folks I talked with had their agents running in the background or cloud.每个人都在不停地运行多个 AI 代理。运行 3-10 个并行代理是常态。我交谈过的人都在后台或云端运行着他们的代理。
No token budget, usage not tracked. One major difference between AI labs and everyone else is that there really is no token limit or token leaderboards that promote tokenmaxxing; people already use agents all the time.没有 Token 预算，不追踪使用量。AI 实验室与其他机构的一个主要区别是，这里确实没有 Token 限制，也没有鼓励“Token 最大化”的排行榜；人们已经习惯了随时使用代理。
Very high autonomy. Work is becoming more structured inside AI labs, but there’s still massive autonomy compared to Big Tech and most startups. When everyone has unlimited tokens, it’s pretty easy to prototype any idea.极高的自主性。AI 实验室内部的工作正变得越来越有条理，但与大型科技公司和大多数初创公司相比，这里仍然拥有巨大的自主权。当每个人都有无限的 Token 时，原型化任何想法都非常容易。
Prototyping and “spiking” is far more fluid原型设计和“探究”更加灵活
It was several times faster to prototype early approaches for Claude Managed Agents. Similarly, “spiking” the Claude Code mobile backend implementation was much faster than pre-AI, Katelyn told me.Katelyn 告诉我，为 Claude Managed Agents 设计早期方案的速度快了好几倍。同样，Claude Code 移动端后端的实现探究也比 AI 出现前快得多。
Verification takes longer than implementation验证比实现更耗时
Jarred made a point about the split between implementation and validation in his 11-day rewrite to Rust. Roughly, it was:Jarred 在他为期 11 天的 Rust 重写中提到了实现与验证之间的分工。大致情况是：
The “implementation” part of rewriting the code from Zig to Rust took about 15% of the time, while 85% went on fixing things up: getting it to compile, fixing tests, verifying that it worked.从 Zig 到 Rust 的代码重写“实现”部分大约占用了 15% 的时间，而 85% 的时间花在了修复问题上：使其通过编译、修复测试、验证功能。
Most tokens no longer spent on implementation大部分 Token 不再用于实现
Thariq:Thariq 说：
“We see that few tokens are spent on actual implementation. Most are spent on discovery of unknowns, prototyping, mocking, and then in verification and testing.”“我们发现很少有 Token 花在实际实现上。大部分都花在未知领域的探索、原型设计、模拟，以及验证和测试上。”
Jarred’s Bun rewrite echoes this: he spent more tokens on fixing up the implementation and verifying that it worked than on the implementation itself!Jarred 的 Bun 重写印证了这一点：他在修复实现和验证其有效性上花费的 Token 比在实现本身上花费的还要多！
Code review and more testing by AI代码审查和更多由 AI 完成的测试
Jarred:Jarred 说：
“Critiquing the code and testing it with agents is a new approach we do a lot more of. I think a lot about trust when you merge a lot of code. How do you merge 100+ PRs a day, and make sure the code works? At this pace, you need to trust the code without the ability to read it all yourself. And I think it’s a few things:“使用代理来批评代码并进行测试是我们做得更多的一种新方法。当合并大量代码时，我非常关注信任问题。你如何每天合并 100 多个 PR，并确保代码正常工作？在这种节奏下，你需要信任代码，而无需自己阅读所有内容。我认为这涉及几点：
Code review: it needs to be really good and automated. I’m clearly tooting our own horn here, but I find Claude’s code review to be really good. Claude’s code review catches bugs that would take me an hour of closely reading the code to figure out. The caveat is that it’s expensive!代码审查：它需要非常出色且自动化。我显然是在自夸，但我发现 Claude 的代码审查非常棒。它能捕捉到我需要花一小时仔细阅读才能发现的错误。缺点是它很昂贵！
Security scanning: for this Rust rewrite we did 11 runs of the Claude Security Scanner.安全扫描：对于这次 Rust 重写，我们进行了 11 次 Claude 安全扫描。
Fuzz testing: we’ve also been doing different types of fuzzing (fuzz testing), where we had Claude write a fuzzer for things like parser fuzzing.模糊测试：我们还一直在进行不同类型的模糊测试（fuzzing），我们让 Claude 为解析器模糊测试等任务编写模糊测试器。
Running out-of-process testing, where it happens in a different process/session from coding, is one way to build trust in the code. I expect more of this.”运行进程外测试（即在与编码不同的进程/会话中进行测试）是建立代码信任的一种方式。我期待看到更多这样的实践。”
New pattern: fanning out work to AI新模式：将工作分发给 AI
Jarred described a new way he works:Jarred 描述了他的一种新工作方式：
“A new approach I’m using is fanning out a lot of the work to many Claudes at the same time. I did this with the Bun rewrite, but I use it for other work. This approach works very well for me, and I feel it’s pretty underused.”“我正在使用一种新方法，即同时将大量工作分发给多个 Claude。我在 Bun 重写中使用了这种方法，我也将其用于其他工作。这种方法对我非常有效，我觉得它目前还未得到充分利用。”
Time-saving automations powered by agents more widespread由代理驱动的时间节省型自动化更加普遍
Jarred listed several time-saving automations set up by the Bun team to run an active open-source project with a small team, while the team works on Claude Code:Jarred 列举了 Bun 团队设置的几项自动化措施，以便在团队致力于 Claude Code 的同时，用一个小团队运营一个活跃的开源项目：
Every time someone files an issue, Claude runs to try and reproduce the issue. If it succeeds, it starts another container, which then tries to fix the issue and submit a PR.每当有人提交问题时，Claude 就会运行以尝试复现该问题。如果成功，它会启动另一个容器，尝试修复问题并提交 PR。
The agent tasked with submitting a PR has to write a test that fails in the system version (the one without the patch) of Bun, and passes in the debug build with the patch, before it is allowed to submit a PR负责提交 PR 的代理必须编写一个测试，该测试在系统版本（未修复版本）的 Bun 中失败，而在带有补丁的调试构建中通过，然后才能提交 PR。
There are other automations, like if there is no test, the PR is auto-rejected; all linters are run: Claude Code review is run, CodeRabbit’s code review is run, and the agents go back and forth on the GitHub pull request还有其他自动化措施，例如如果没有测试，PR 会被自动拒绝；所有 Lint 工具都会运行；Claude 代码审查会运行；CodeRabbit 的代码审查也会运行，代理会在 GitHub 的 Pull Request 上来回交互。
Auto-merge of pull requests: coming soon?Pull Request 自动合并：即将到来？
Pull requests are merged manually when all quality gates pass, but this could become automatic at some point. Once all the above checks pass, all (AI) code review comments are addressed, tests are added to new code, etc. As an interesting aside, a lot of GitHub activity is Claude talking to Claude!Pull Request 在所有质量门禁通过后由人工合并，但这在未来可能实现自动化。一旦上述所有检查通过，所有（AI）代码审查意见得到处理，新代码添加了测试等，即可自动完成。顺便提一下，GitHub 上有很多活动其实是 Claude 在与 Claude 对话！
But manual merging may vanish in low-risk cases, at least for the Bun project. Jarred told me:但在低风险情况下，人工合并可能会消失，至少对于 Bun 项目而言是这样。Jarred 告诉我：
“Today, a person presses ‘merge’ but within a few months, I expect:“今天，还是由人点击‘合并’，但几个月内，我预计：
Automated reviewer LGTMs自动化审查员给出 LGTM（看起来不错）
→ another Claude with a fresh context window judges if it’s simple and low blast-radius→ 另一个拥有全新上下文窗口的 Claude 判断它是否简单且影响范围小
→ if it is: auto-merge!”→ 如果是，自动合并！”
Test assumptions with each model generation在每一代模型中测试假设
Inside Anthropic, the team keeps testing their priors. Thariq gave an interesting example:在 Anthropic 内部，团队不断测试他们的先验假设。Thariq 给出了一个有趣的例子：
“The thing with agents is that you have to revisit any assumptions you have made because it can change with a new model generation. For that reason, we deleted 80% of the Claude Code system prompt recently because the model has gotten smarter.“关于代理，你需要重新审视你所做的任何假设，因为它们会随着新一代模型的出现而改变。因此，我们最近删除了 80% 的 Claude Code 系统提示词，因为模型变得更聪明了。
Using HTML is another assumption we needed to re-examine. HTML is one of those things which Claude is a lot smarter at than many of us expected. I’ve started preferring HTML as an output format over Markdown, and see this being used by others on the Claude Code team.使用 HTML 是我们需要重新审视的另一个假设。Claude 在处理 HTML 方面比我们预期的要聪明得多。我已经开始偏好 HTML 作为输出格式，而不是 Markdown，我也看到 Claude Code 团队的其他成员也在使用它。
HTML can convey much richer information compared to markdown, HTML documents are easier to read and share.”与 Markdown 相比，HTML 可以传达更丰富的信息，且 HTML 文档更易于阅读和共享。”
4. Team-level changes4. 团队层面的变化
At Anthropic, there are also changes in how engineering teams operate, compared to pre-AI.在 Anthropic，与 AI 出现之前相比，工程团队的运作方式也发生了变化。