Anthropic 每日合并 3 万次代码变更的背后：软件工厂如何验证与问责

简要描述Brief Description

How Anthropic Merges 30，000 Code Changes a Day - Manish Kapur， Sonar & Addy Osmani， Anthropic

目录Table of Contents

• 快速问答与责任追究
  Lightning questions and accountability
• 软件工厂与验证
  Software factories and verification
• 分层检查、智能体控制与问责机制
  Layered checks, agent controls and accountability

软件工厂与验证Software factories and verification

我很高兴来到这里，和大家聊聊谁来验证软件工厂。在开始之前，能不能请大家快速举个手？如果你的编码代理在过去一周内创建过任何拉取请求，请举手。几乎所有人都举手了，谢谢。如果你合并过拉取请求，并且审查了所有已合并代码的每一行，请继续举着手。嗯，我看到有几位。太棒了。今天我要谈的是这两类人之间的差距：一类是不经人工审查就合并拉取请求，另一类则是在进行一些审查之后再合并。先自我介绍一下，我叫 Manish Kapoor，在 Sonar 负责产品与解决方案开发者关系团队。很高兴今天能和我的特邀嘉宾、来自 Anthropic 的 Addy Osmani 一起交流。I'm pretty excited to be here and talk about who verifies the software factory. before we get started, can you give me a quick show of hands? raise your hand if your coding agent has pulled opened any pull request in the last 1 week. Almost everyone, thanks. And keep your hands raised up if you have merged pull requests and reviewed every line of code that was merged. Oh, I do see a few people. That's excellent. So, what I'm going to talk about is the gap between the two camps, merging requests without reviewing manually, and you know, merging requests after doing some reviews. So, my name is Manish Kapoor, and I lead the product and solution developer relations team at Sonar, and I'm excited to be here with my guest speaker, Addy Osmani from Anthropic.

Addy在Google工作了大约14年。你们大多数人应该都认识他。他写了很多很多内容和文章。我从Addy身上学到了很多，所以今天能请他来到这里，站在我身边，与大家分享他的经验，我感到非常幸运。他最近加入了Anthropic。Addy，恭喜你加入Anthropic！你愿意跟团队介绍一下你在Anthropic负责什么，以及你正在做些什么吗？Addy has been had been at Google for about 14 years. Most of you probably know him. And he's written lots and lots of content and articles. I learn a lot from Addy, so I'm really fortunate to have him here, stand next to me, and share his wisdom with all of us here today. he recently joined Anthropic, and Addy, so congratulations on your role at Anthropic. Would you like to tell the team what you're working on at Anthropic, what your role is?

当然。我负责确保大家在使用 Cloud Code 进行开发时拥有非常棒的开发者体验。每当我们发现还能让体验更加顺畅的机会，都会马上将改进落实到产品中。我们每天都会发布几次更新，因此我们非常希望尽可能经常地为大家带来最佳体验。Yeah, sure. So, I'm responsible for making sure that you all have a really great developer experience building with Cloud Code, and anytime that we discover there are opportunities to make it even smoother, we bring that right back into the product. We ship a couple of times every single day, and so we're very interested in trying to make sure that you have the best possible experience as often as possible.

很好，谢谢。好吧，我们先从一张介绍问题和背景的幻灯片开始。这张幻灯片上有两个数字。CircleCI 今年分析了 2800 万个 CI 工作流，并发现吞吐量提升了约 59%。然而，尝试将代码合并到生产环境的操作中，仍有十分之三以失败告终。这是 CircleCI 发布的一项独立统计数据。我觉得，我每天接触的大多数客户身上也都呈现出同样的趋势。 这句话引自 Adi：“软件工厂正在大规模利用循环。”这句话让我很有共鸣。如果你还没读过那篇文章，可以去找来看看。文章很有启发性，探讨了软件工厂的未来形态。那么，Adi，你愿意进一步谈谈吗？你在写这篇关于软件循环以及如何大规模利用循环的文章时，心里是怎么想的？Cool. Thank you. All right. so, let's start with some problem and context setting slide. There are two numbers on the slide. CircleCI analyzed 28 million CI workflows this year. And they noticed that the throughput jumped by about 59%. But yet three in 10 attempts to merge that code into production are failing. And this is a stat from one independent stat from CircleCI. And I think I'm seeing the same trend from most of our customers that I speak to every day. this is a quote from Adi. A software factory is harnessing loops at scale. This resonated quite a bit for me. And if you have not read that article, you can look it up. It's pretty educational article and talking about future how the future will look like in terms of soft software factories. so, Adi, would you like to expand on what you were thinking when you wrote this article about soft loops and harnessing the loops at scale?

是的，当然。这里很多人可能都听说过“软件工厂”这个说法，至少有两种工厂值得记住。你知道，软件工厂就是大规模运用循环。所谓“亮灯工厂”，是指有智能体不断帮你规划、构建、检查并交付代码，而你作为人，仍然会在整个过程中运用自己的判断力和品味。另一种是“暗软件工厂”，它更接近那种由机器人运作的汽车工厂——工厂会持续不断地完成工作：界定范围、构建、检查；而你作为人，则进一步转而思考意图，只有遇到极其特殊的情况时，才会被拉进来。Yeah, absolutely. So, a lot of folks here probably heard this term software factories, and there's two types of factories that are at least worth keeping in mind. Well, you know, software factory is harnessing loops at scale. A lights-on factory is one where you have agents that are helping you with planning, building, checking, and shipping code again and again, but you as a person still apply your judgment and taste inside the picture. And then we have a dark software factory, which is a little bit closer to how, you know, a car factory with robotics might be working where it's constantly doing the work. So, it's scoping, building, checking, and you as the person move down further to thinking about intent, and you're pulled in when they're really the greatest of exceptions to the case.

不过，我想的差不多就是这样。我觉得很多团队都处在这个渐进过程中的某个阶段，也都在摸索如何在自己能够信任自动化的前提下，逐步扩大自动化的范围。But, that's sort of what I was thinking. I think a lot of teams are somewhere on this spectrum and are on this journey to figure out like how do I get further and further into automation in a way that I can trust it.

很好。所以，AI 编码基本上已经是一个解决了的问题。我们都知道智能体已经出现了。85% 的组织已经在使用编码智能体。这个比例将升至 95%，很快就会达到 100%。在那 76% 会生成 AI 代码的开发者中，有 75% 表示，代码的生成速度快到他们根本无法验证。因此，他们花在审查代码上的时间越来越多。那么，你认为工程领导者现在最迫切的问题是什么？Cool. So, AI coding is now basically a solved problem. We all know agents are there. 85% of the organizations are already using coding agents. It will go to 95% and very soon to 100%. 75% of the 76% of the developers that generate AI code, they are saying that it's being code is being produced at a speed that is impossible for them to verify it. So, they are spending more and more time reviewing the code. So, what do you think is the most pressing question that engineering leaders have right now?

所以，我认为过去一年里，团队在与智能体协作方面已经做得更好了，模型和运行框架也有了进步。我发现很多领导者都很关注一个问题：我们如何帮助你们更有信心地加快代码交付？其中，信心这一点非常重要。如今，智能体能够以比以往低得多的成本，生成各种方法来检查代码。想想看，哪些东西能让我们认定代码是好的、质量很高的？比如优质的测试、基准测试、规范，以及任何能增强我们信心的东西。如今，智能体能更轻松、更快速地帮我们生成这些内容。当然，我们还可以对它们进行完善，但我认为这些检查正是我们现在最值得投入时间去做的事情之一。So, I think that teams have gotten better working with agents over the last year. models, harnesses have also gotten better. And what I see a lot of leaders being interested in is how do we enable you to ship code faster with confidence. And that confidence piece is very important. Agents can now generate ways for you to check your code much more cheaply than ever before. And if you think about the things that enabled us to call good code, you know, high quality, those were things like good tests, benchmarks, specs, anything that gives us confidence. So, agents are able to help us generate that a little bit more easily these days, a little bit more quickly. We can of course refine those things, but I think that those checks are one of the most important things we should be spending our time on these days.

比如，如果你希望智能体产出最高质量的结果，就需要给它们提供一种验证工作是否正确的方法。如果你做好了这一点，就能确保代码既正确又完整，从而轻松将成果质量提升两到三倍。Like if you are hoping to get the best quality output from your agents, you need to give your agents a way to verify that the work is correct. If you've got that in place and it you can make sure that the code is both correct and complete, that can easily two to three by like the quality of your outcomes.

是的。是的。完全正确。说得太对了。我觉得在代码信心这方面，我们一直在宣传代码信心很稀缺这一点。既然编程问题已经解决了，你们现在真的需要把代码信心建立起来。其实，我昨天晚上——所以这个问题对你来说可能有点突然——昨天晚上我读了 Anthropic 的一篇帖子，我鼓励大家都去读一读。帖子谈到了 Anthropic 的运营规模：他们每天合并大约 30,000 次代码变更。就在几个月前，他们每天大概只处理 3,000 次左右，或者说 2,500 次左右的代码变更。他们已经从每天 2,500 次代码变更，增长到了 30,000 次。这简直令人难以置信。所以，我没……Anthropic 的 Claude Code 团队，以及你正在合作的 Claude Code 团队，他们的代码审查是什么样的？Yep. Yep. Absolutely right. Spot on. I think code confidence we have been running an ad code confidence is scarce. And you really need to build it up now that the coding problem is solved. So, I actually I yesterday night, so this might be a surprise question for you. yesterday night I read a post from Anthropic, and I encourage all of you to read it. It talks about the scale at which Anthropic is operating. they are merging about 30,000 code changes every single day. They used to do about 3,000 or so, 2,500 or so code changes just a few months back. They have scaled from 2,500 code changes to 3,000 30,000 code changes per day. That is mind-boggling. So, I didn't What does code review look like at Claude Code at Anthropic and with the Claude Code team that you're working with?

是的，这些问题都问得很好。早在五月，我们就合并了大约 2,500 项更改。最近更新 Claude.ai 时，我们还发布了一篇案例研究，称其性能提升了约三倍。这是在很短的时间内合并了大约 3,000 个拉取请求才实现的，参与其中的有工程师、产品设计师以及来自多个不同职能团队的成员。为了落实验证和代码审查，我们的工作流程是先让 Claude 进行第一轮审查。这里非常重要的一点是，要确保它能够像真实用户一样实际体验产品。这可能包括执行端到端任务，比如打开产品、在浏览器中检查、运行各种工具、执行 lint 检查，以及进行其他必要的检查，从而建立起足够的信心。Yeah, these are great questions. So, we were we were merging about 2,500 changes all the way back in May. and even for our recent refresh of Claude.ai, we put out a case study saying that we kind of three-by'd the performance of it. That was accomplished by merging about 3,000 pull requests in a very short space of time with engineers, product designers, a number of different functions contributing to it. So, our workflow for being able to get verification and code review in place is that we first of all have Claude do a first-pass review. What's very important in there is making sure that it has a way to actually try the experience out similar to a real user. So, that can mean end-to-end tasks, you know, opening up the experience, checking it in a browser, running any tools, doing any linting, doing any other checks that are necessary to build up that confidence.

人们通常会问：“好吧，如果你发现了一个 bug 或功能缺失，会怎么样？”我们有一些钩子，会在任何编辑发生后运行。它们会检查差异，让我们建立起这样一个循环，尽可能快地修正 PR。因此，我们让 Claude Code 来做审查。我们还有一款代码审查产品，也可以去看看，挺不错的。我们的想法是尽可能自动化代码审查。这也是我们自己在用的东西。如今越来越重要的是，你们的团队要思考如何削减……这些日子我们总是在谈品味和判断力，对吧？重要的是，你们要尝试把自己认定的最佳实践和品味整理成规范，写进团队共享的 Claude.md、agents.md 等文件里，让智能体在代码审查时能够查阅。people usually ask, "Is it okay, well, what happens if, you know, you discover a bug or a gap in functionality?" Well, we have hooks that will then go and run on any edits. They will study the diffs and allow us to get this loop in place where we're correcting the PR as quickly as possible. So, we have Claude Code doing the review. We have a code review product that you can also check out. It's pretty good. And the idea there is we're trying to automate code review as much as possible. This is something that we use ourselves. and increasingly what's important is for your teams to be thinking about how can you cut We talk about taste and judgment so much these days, right? It's important for you to be trying to codify what you consider best practice and taste in your team's shared like Claude.md, agents.md, anywhere where the agent can then consult during code review.

然后，人们要负责检查智能体提供的证据。那么，我们怎么知道呢？有些……如果我正在构建一段 UI，它将由用户在浏览器中使用，我就希望确保它在浏览器中经过测试；也许还能为我生成一段体验视频，展示它如何在页面上点击操作，让我更有信心。好吧，行，这样就能用了。如果我在意移动端或桌面端的体验，它也许会为我生成相应的截图或视频。总之，你希望智能体尽可能提供更多验证证据。And then people are responsible for checking on the agent's evidence. So, how do we know? Some If I'm building out a piece of UI that's going to be, you know, used by a user in the browser, I want to make sure that it's tested in the browser, maybe generated me a video of that experience where it's been clicking around and gives me confidence. Well, okay, well, this works. If I care about the mobile or desktop experience, maybe it generates me screenshots or videos of that. But basically, you want to get to a place where the agent's giving you as much verification evidence as possible.

不错。是的，验证至关重要。我认为，你需要验证软件工厂所产出的一切，这也是我们今天要讨论的内容。顺便说一下，这些数据来自 Sonar 即将发布的《代码现状调查报告》。我们调查了大约一千多名开发者，发现了一些有趣的数据，能让我们了解当今行业正在发生什么，以及未来的发展方向。84% 的受访者表示，AI 功能让新功能和修复更快投入生产。拉取请求也变得更大、更复杂。不过，只有 31% 的受访者表示，更多代码未经审查就进入了生产环境。这多少有点令人担忧，尤其是对于受监管行业中的生产应用和任务关键型应用而言。在这些场景下，你绝对需要确保代码经过验证，并对即将发布的代码有信心。Cool. Yeah, verification is key. I think you need to verify everything that the software factories will produce and that's what we are going to talk about today. so another these stats by the way are from the state of code survey report that will be coming out very soon from Sonar. we surveyed about a thousand more than a thousand developers and we found some interesting data which will give us insights as to what's happening in the industry today and where we are headed. So, 84% say AI features gets features and fixes put to production faster. The pull requests are getting larger and more complex. and you know, yet only 31% more code is reaching the production without review. So, that's a little little bit of a scary fact particularly for production applications in the regulated industries in the mission-critical applications where you absolutely make need to make sure that you know, you have to verify that code and you're confident in the code that is being shipped.

那么，下一波增长会来自哪里，Addy？So, what are the where are the next gains going to come from, Addy?

我认为，接下来的提升将来自我们把验证真正做好，对吧？同时也来自模型质量。不过，模型质量已经相当不错了，比如看看 Opus 55 就知道了。我想，我们能够分享验证这一步的最佳实践，会变得越来越重要，因为如果你告诉大家“对，检查一下成果就行”，你知道，他们接下来就会问：这到底是什么意思？I think the next gains are going to come from a combination of us really nailing verification, right? As well as model quality. But models are already like if you take a look at Opus 55, model quality has already gotten to a place where it's pretty good. and I would say that us being able to share best practices about that verification step is going to become increasingly more important because if you tell people, yeah, just like verify the work, you know, their next question is, what does that even mean?

是的。Yeah.

因此，我认为讨论需要进一步聚焦于哪些类型的测试有用。我们很依赖端到端测试、属性测试以及各种视觉验证测试——这些测试能让我们有信心自动合并这些变更。And so, I think that the conversation needs to evolve into specifically what kinds of tests are useful. We lean a lot on end-to-end tests, property tests, any visual verification tests, things that can help us just get that confidence to merge those changes in automatically.

很好。你提到了轻量级工厂。我们想沿着这个话题深入聊聊，这也是我们正在前进的方向。我们的调查结果显示，目前有 5% 的公司在使用软件工厂。这个比例将升至 34%，而在金融服务行业，竟然会达到 39%。你们当中有多少人现在正在使用软件工厂？我只是好奇。那有多少人计划在明年之前使用软件工厂？是啊，这是个好问题。你们如何定义软件工厂？你愿意回答这个问题吗？Cool. You mentioned light factories. Want to go down that and that's the way direction we are headed. our survey results show that, you know, today 5% of the companies are using software factories. It will get to 34% and surprisingly 39% in the financial services. How many of you are using software factories today? Just curious. A handful of you. And how many are planning to use software factories by next year? Yeah, that's a good question. How do you define a software factory? Would you like to take that question?

对，对，当然。刚才我们稍微聊了一下软件工厂的定义。软件工厂本质上就是大规模循环。我们思考这个问题时，关键在于：从流程中仍有多少人参与这一点来看，你处于这个光谱的哪一端。智能体越能生成验证结果、让你更有信心，你就越能达到那种可以放手不管的状态。我觉得，大多数人目前仍处于这个光谱的某个位置，还没有像这些数据所显示的那样，真正达到完全放手的阶段。Yeah, yeah, sure. So, we talked about definition of software factories just a little bit earlier. A software factory is basically loops at scale. And when we think about this, it's all about like what end of the spectrum are you at in terms of how much people are still involved in the process. The more that the agents are able to generate verification and give you confidence, the more that you can get to that place where you go dark. And I think that yeah, most people are still somewhere in that spectrum and are not quite as this data shows at that dark point just yet.

分层检查、智能体控制与问责制Layered checks, agent controls and accountability

是的。补充一下 Addy 刚才说的内容，我认为可以把软件工厂想象成一条生产线：从定义意图和规格开始，然后开始编写代码。这就像一条装配线，软件开发生命周期中的每个步骤都会在这里完成。大规模自动化这些步骤时，工厂基本上就会变成一座暗工厂——里面不会亮灯，它会自主运行，完全自主运行。亮灯工厂则是在每个步骤或大多数步骤中都有人参与的工厂；而暗工厂的目标是关掉灯，让工厂独立运行，全天候不停运转。好。你刚才谈到了验证，我来简单谈谈 Sonar 对验证的看法。如果你今天早些时候看了我们 CEO 的主题演讲，就会听到他提到验证应该是多层次的。Yep. Just to add to what Addy said, I think software factory, think of it like a production line where you start defining the intent and your specifications. Then you start writing the code. So, it's an assembly line where each of these software development life cycle steps happen. And automating them at scale where there's pretty much in a dark factory, there would be no lights on. It's autonomously working, fully autonomously working. A light factory has is where people are involved in the process at every step or most steps. whereas a dark factory, the goal would be to turn off the lights and let the factory run independently 24/7. all right. So, you talked about verification. I'll talk a little bit about what we think at Sonar about verification. If you saw our keynote earlier today from our CEO, he talked about verification should be multi-layered.

我们绝对百分之百相信，每家公司都应该采用零信任的多层验证方法。验证应该在每个循环中进行。无论你是在智能体循环中运行，还是在 CI 验证循环中工作，抑或是在进行代码维护，每一个循环中，验证工厂或智能体所生成的代码输出都至关重要。因此，我们从分层的角度来看待这件事，可以把它理解为：第一层是确定性层，用于捕获错误、安全问题，例如 SQL 注入、缓冲区溢出等；然后是第二层，在这一层进行智能体审查，正如 Adi 所说，会使用智能体来审查代码。we absolutely 100% believe that each company should adopt a zero trust multi-layered verification approach. And verification should be done in every loop. Whether you're operating inside the agentic loop or whether you're working inside the CI verification loop or whether you're doing code maintenance. In each and every loop, it is important to verify the output of the factories or the agents that code that the agents are producing. So, we look at it in terms of layers and think of it like, you know, the there's first layer which is a deterministic layer which catches bugs, security issues, things like SQL injection, buffer overflow bugs, and all of those are caught. And then there's a second layer where agentic review happens where agents are used to like Adi was talking about, agents review that code.

在这种智能体式审查中，他们能发现确定性层不太适合捕捉的逻辑和意图问题。因此，我们让每一层都专门针对特定类型的问题进行检测。第三层可以是软件供应链安全层，用来检查所有 CVE，并进行所有恶意软件检测和恶意软件包检测。这些工作都在第三层完成。这是一种分层方法，每一层都经过调整和优化，以检测某一特定类型的问题。因此，我们绝对建议采用多层验证。哎呀。这里还有另一项数据：你知道，28% 的公司已经批准使用智能体，并设有共享控制措施，但真正设有共享控制措施的公司却很少。还有 5% 的公司正在自主运营软件工厂。Adi，你怎么看？And in that agentic review, they catch logic and intent issues which the deterministic layer is not well suited to catch. So, we use each layer is targeted at catching a specific types of issues. And then the third layer could be a software supply chain security layer where you look at all the CVEs, all your malware detection happens, all your malicious package detection happens. All of that happens in the third layer. So, it's a layered approach where each layer is tuned and optimized to catch a certain type of issue. So, we absolutely recommend doing a multi-layered verification. Oops. So, there's another stat here. 28% you know, companies have approved agents and shared controls and very few shared controls. And 5% are operating software factories autonomously. What are your thoughts there, Adi?

就……而言in terms of

我和很多公司聊过，就在几个月前，他们最大的担忧之一是，任由工程团队自行探索和尝试智能体，结果有些公司拥有了数百甚至数千个智能体，却完全不知道这些智能体在做什么。比如，这些智能体到底在做什么？它们接触我们所有的系统，访问各种数据，甚至可能还会部署到生产环境。因此，很多企业都在考虑智能体身份、遥测，以及如何追踪实际发生的情况等问题。So, I've talked to so many companies where a couple of months ago one of their biggest worries was they were allowing their engineering teams to go off and play around with agents and they got to a place where there were hundreds, thousands of agents in some cases and they just didn't know what they were doing. Like, what are these agents actually doing? They're touching all of our systems, accessing all kinds of data, maybe they're deploying to production. And so, a lot of enterprises think about concerns like, you know, agent identity and telemetry and being able to track what's actually happening.

是的。Yeah.

我想说，对很多公司来说，最重要的三件事是：我们如何看待控制、如何看待权限，以及如何看待沙箱？也就是说，我们如何确保智能体不会跳出沙箱，去做不该做的事情？And I'd say that the three biggest things for a lot of companies are how do we think about control, how do we think about permissions, and how do we think about the sandbox? Like, how are we making sure that the agent isn't jumping out of the sandbox and doing things that it shouldn't be doing?

是的，是的，在 Sonar，我们称之为“引导轨道”。所以，我们想把它叫作“引导轨道”，而不是“防护栏”：我们引导智能体沿着正确的轨道前进，对吧？为它们设定一条明确的路径，防止它们越界，或者像 Addie 说的那样，跑出沙盒。因此，为智能体设置引导轨道，并对你所使用的智能体进行管理，非常非常重要。好了，我们现在差不多要结束了，计时器提醒我只剩几分钟了。接下来来一轮闪电问答。每个问题用一句话回答。你们已经在幻灯片上看到这些问题了，所以……Yeah. Yeah, we at sonar we call it guide rails. So, instead of guard rails, we're thinking of calling it as guide rails, where we guide the agents to follow the real tracks, right? A specific path to take and prevent them from going out of bounds or so to say going out of the sandbox like Addie was saying. So, it's very very important to have guide rails for the agent and govern the agents that you're working with. So, let's we're coming to a close now as my timer is telling me we just have a few minutes left. Let's go get into a lightning round. one sentence response for each of these questions. And you've seen the questions already on the slide, so

闪电提问与问责Lightning questions and accountability

这些可以是长句吗？Can these be long sentences?

它们可以在时间允许的情况下尽可能长。They can be as long as the time permits.

太好了。Perfect.

到2027年底，大多数团队会采用明灯工厂还是黑灯工厂？是还是不是？light or dark factory for most teams by end of 2027, yes or no?

我认为，我们将会看到一些只在局部采用暗工厂模式的轻工厂。我不认为在场的每个人都会完全采用暗工厂模式，但情况会很接近。I think we're going to see light factories with some dark corners. I don't think we're going to get to everybody in this room using dark factories entirely, but it's going to be something close to that.

我猜 Anthropic 会在今年或明年推出它。I would guess Anthropic would do it this year or next year.

好的。第二个问题：PR 中是否应该标明由代理编写的代码？All right. Second question. Should agent-written code be labeled in the PR?

我个人认为应该如此。过去，我们对自己的代码有很强的归属感，也会为此感到自豪：“嘿，这东西是我写的。我会在上面署上自己的名字。”而在 Anthropic，我们对此的看法有些不同。我们的理念已经发展到这样一种程度：如果 Claude 被标注为“嘿，这东西是我写的”，我们其实并不太介意，因为我们更关注结果，确保代码、功能，也就是我们交付给用户的东西是正确的。所以，我个人认为，如果代码被标注为由智能体编写，也完全没问题。这还能帮助我们思考一些问题，比如：“好吧，如果这是智能体写的，我们需要保留哪些限制和额外检查？”I personally think it should. Historically, we have felt a great deal of ownership around our code, pride around the fact that, "Hey, I wrote this thing. I'm putting my name on it." And at Anthropic, like we think about this a little bit differently. We've evolved to the point where we don't really mind so much if Claude is like labeled as, "Hey, I'm I'm the one that wrote this thing." because we're a little bit more focused on the outcomes and making sure that the code, the features, like what we're shipping to users is the right thing. And so, I personally think it's fine for the code to be written labeled as being coming from an agent. And that can also help us with things like figuring out, "Okay, well, if the agent wrote it, what are some of the constraints and extra checks that we need to keep in place?"

我和你观点一样，Addie。我认为短期内，至少在可预见的未来，也就是6到9个月内，我们应该给 PR 打上标签，直到我们对自己的工厂足够有信心。我们确实想了解并跟踪这一点；对于这里的金融客户来说，这在可审计性方面也很重要。如果你——如果你知道的话，给它打上标签，就能知道是谁写的代码，因为归根结底，我们仍然要对……负责I have the same point of view, Addie. I think in the short run, at least in the foreseeable you know, 6 to 9 months, we should label the PRs till we are confident enough in our factories. We do want to know and track it, and it's also important for the financial customers here in terms of auditability. If you if you know, if you label it, you know who's writing the code because we are at the end of the day still accountable for

是的，当然。问责是这里最重要的部分。比如，我们仍然会标明这项变更的负责人是谁。我可能启动了一个 Cloud Run 来完成一项工作，但我仍然要对此负责。要是出了问题，我就得去把它修好。Yeah, absolutely. Accountability is the most important part here. Like we still label like who is the owner for this change. I might have kicked off a cloud cloud run to complete a piece of work, but I'm I'm still on the hook. If something goes wrong, I have to go and fix it.

对，对。关键点。对。下一个问题，其实我就在这里即兴提问吧，因为这是一次领导力课程。今年，初级开发者或领导者应该培养哪一项技能？Yep, yep. Key point. Yep. the next question, actually I'll improvise it here because this is a leadership session. What one skill a junior developer or leader should build on this year?

我认为，如果你是领导者，就应该推动团队认真思考“验证”意味着什么。你们现在是如何处理测试之类的事情的？从目前的做法到让你们非常放心地让智能体自行确认代码质量达标、可以合并，中间还差些什么？所以，关键是弄清楚这一点。如果你是初级开发者，情况正好相反：要在不同类型的测试中积累更多经验，比如端到端测试、属性测试等等。I think that you should push your teams, if you're a leader, you should push your teams to really think hard about what verification means. how are you already approaching things like testing? What is the gap between that and you getting to a place where you're very comfortable with the agents being able to sign off on the code being good enough to merge on their own. And so figuring that out, if you're a junior, it's the other side of that. Like actually getting more experience in the different flavors of tests, whether it's like end-to-end tests, property tests, etc.

是的。而最后一点，你实际上没有遵守规则，写得超过了一句话，不过没关系。最后一个。Yep. And the last you actually not following the rules, you're going beyond one sentence, but that's cool. The last one

还剩30秒。我没事。30 seconds left. I'm fine.

我想我们多花一分钟也没关系。代理已经开了 PR。什么时候合并才安全？We can go a minute over, I'm sure. the agent opened the PR. It is safe to merge when?

你完全确信不会出什么差错，或者已经尽可能地降低了风险。You have full confidence nothing's going to go wrong or that you have mitigated that as much as possible.

太棒了。好，这是我的最后一张幻灯片，然后我们就结束。究竟是什么让团队既能快速交付，又不至于盲目交付？我觉得有三点关键经验想告诉大家。编写代码是最快的环节，这个问题已经解决了。对团队进行严格的审查和验证，才能帮助你们保持这样的速度。写得快不等于交付得快。你基本上必须统计有哪些内容被合并，审查被合并的内容，并确保它们在进入生产环境之前不会逃出沙箱，等等。验证一切。自主性是靠赢得的。很快——如果不是明年——我们就会进入软件工厂时代。你需要在工厂的每个循环中加入独立的自动化验证，确保你能信任工厂产出的结果。Love it. All right. here's my last slide and then we'll wrap it up. so what separates teams that are shipping fast but not shipping blind? I think that three key takeaways for you. writing code is the fastest part and that is solved. Strong review and verification for our teams is what will help you maintain that speed. Fast to write is not fast to ship. you have to basically count what is getting merged, looked at what is getting merged, and make sure it doesn't escape the sandbox and the things like that before it gets into the production. Verify everything. And autonomy is earned. you We will get to software factories very soon if not next year. you need to put in independent automated verification inside each loop of your factory. Make sure that you can trust the output that the factory is producing.

那么，我就到此结束。感谢大家今天参加我们的演讲，聆听与 Adi 的对话。再次感谢 Adi 抽出时间来到这里与我们交流。如果大家还有其他问题，或者想继续聊聊，欢迎到展览厅里那个大红色的 Sonar 展位来找我们。再次感谢大家。with that, I'll wrap it up. Thanks for attending our talk today, a conversation with Adi. again, Adi, I appreciate you taking the time and joining us here in this conversation. visit us at the big red booth, the sonar booth in the expo hall if you have any further questions or would like to, talk about it. Thank you again.