Running

an

AI-native

engineering

org

For years, engineering bandwidth was the expensive part of building applications. Every process we used to have around software planning and shipping, first waterfall and then agile, was built around that cost. 多年来，工程带宽是构建应用程序的昂贵部分。我们围绕软件规划和交付的所有流程——先是瀑布式，后是敏捷——都是围绕这一成本构建的。

I started my career in the early 2000s working on Visual Studio. In those days we shipped software on CD-ROMs with hard manufacturing deadlines. Once we could distribute software online, we began increasing to shipping updates continuously. Now we’re changing the way we work again, this time around the time and people it takes to write software. 我在 2000 年代初期开始职业生涯，参与 Visual Studio 的开发。那时我们通过 CD-ROM 发放软件，必须在硬性制造期限前完成。一旦我们能够在线分发软件，就开始不断发布更新。现在我们再次改变工作方式，这一次围绕编写软件所需的时间和人员。

On the Claude Code team, writing code, writing tests, and refactoring rarely slows us down anymore. But the bottlenecks didn’t go away when agentic coding took away the actual need to type code. Verification, code review, and security took their place.在 Claude Code 团队，编写代码、编写测试和重构已经很少再拖慢我们的进度。但当代理编码消除了实际敲代码的需求时，瓶颈并没有消失。验证、代码审查和安全性取而代之。

We can all generate a lot of code really fast now, but this also brings up new questions: Is this code correct? How is it maintained? And one of the top questions I get from fellow engineering leaders: “How are humans keeping up with how you’re doing code reviews?” 我们现在可以非常快速地生成大量代码，但这也带来了新问题：这些代码正确吗？如何维护？我从其他工程领袖那里收到的最常见问题之一是：“人类如何跟上你们的代码审查速度？”

The processes that quietly stopped working悄然失效的流程

We all put processes in place for a reason, to close a gap or make something work better. But when that gap no longer exists and those processes become obsolete, they rarely go away on their own. When the Claude Code team began using agentic coding as our default way of working, a lot of our existing processes stopped working. Here are the norms we rewrote, and why. 我们之所以制定流程，是为了解决某个痛点或让事情运行得更好。但当这个痛点不复存在、这些流程变得过时时，它们很少会自行消失。当 Claude Code 团队把代理编码作为默认工作方式时，许多既有流程失效了。以下是我们重新制定的规范以及原因。

Planning: shift roadmaps to just in time规划：将路线图转为即时（just‑in‑time）

The old norm was to spend a lot more time pre-planning because coding time was expensive. When I first joined the Claude Code team, we wrote a pretty good six month roadmap, and then because of Claude Code, so many things changed that it was out of date by month three. 过去的常规是花大量时间进行前期规划，因为编码时间很昂贵。当我刚加入 Claude Code 团队时，我们制定了相当不错的六个月路线图，但由于 Claude Code 的出现，很多事情在第三个月就已经过时。

Engineering speed and throughput is different now, so the way we plan sprints has changed. I call it just-in-time (JIT) planning, almost like JIT compiling: how do you do just the right amount at the right time? Our planning ritual shifted away from design docs toward discussions in PRs or prototypes. The space moves fast so we don’t do a lot of product reviews. Our process now is let's prototype, get a lot of internal users on it, and start acting on their feedback.工程速度和吞吐量现在不同了，冲刺的规划方式也随之改变。我把它称为即时（JIT）规划，几乎像 JIT 编译一样：如何在恰当的时间做恰当的量？我们的规划仪式从设计文档转向 PR 中的讨论或原型。节奏非常快，所以我们不做大量的产品评审。现在的流程是：先做原型，让大量内部用户使用，然后根据反馈行动。

Context gathering: ask Claude, not the author上下文获取：询问 Claude，而不是作者

When engineers wrote code, the first step to getting an answer to most questions was to find the person who wrote the code. Now, since all our PRs are assisted by Claude, "Who made this change?" is no longer sufficient. Our new norm is to go a level deeper: what do you actually need to know? For instance: Are you looking for who caused a regression? An expert to answer a customer question? Or context on a decision? You ask Claude that question, and consider whether Claude can answer it directly, also with more data and context.当工程师编写代码时，获取大多数问题答案的第一步是找到代码的作者。现在，由于所有 PR 都有 Claude 辅助，"是谁做了这次改动？" 已不再足够。我们的新常规是再深入一层：你到底需要了解什么？例如：你在寻找导致回归的原因？要找专家回答客户问题？还是想了解某个决策的背景？你把这个问题问 Claude，并考虑 Claude 是否能直接回答，同时提供更多数据和上下文。

On the Claude Code team, no matter what that question is, our process is to also ask “Is there a way to automate it?” For example, having Claude summarize customer feedback channels every morning went from a ritual I did manually with my coffee to something I just have running automatically in the background.在 Claude Code 团队，无论问题是什么，我们的流程还会问“有没有办法自动化？”例如，让 Claude 每天早上汇总客户反馈渠道，从我手动端着咖啡做的仪式，变成了后台自动运行的任务。

Code review: trust but verify代码审查：信任但要验证

We use Code Review heavily. Claude handles all the style and linting, PR feedback requests, catching bugs and fixing them before a full commit, and adding tests. Where we still definitely want a human is expertise. 我们大量使用代码审查。Claude 负责所有风格和 lint 检查、PR 反馈请求、在完整提交前捕获并修复 bug、以及添加测试。我们仍然明确需要人的地方是专业知识。

The new norm is human review where it matters: for legal review, I always want my legal partner involved in risk tolerance. For trust boundaries and security-sensitive code, I want the domain experts. Product managers and designers also need to be involved with product sense and taste. 新的常规是在人类审查关键环节介入：法律审查时，我总是希望我的法务伙伴参与风险容忍度的评估。对于信任边界和安全敏感代码，我需要领域专家。产品经理和设计师也需要参与，以提供产品感知和审美判断。

It’s important to continually evaluate, though, because the right balance of trust vs. verify will keep changing as the models improve. What you need humans for today might look different with the next model.不过，这一点需要持续评估，因为信任与验证的平衡会随着模型的提升而不断变化。今天需要人类介入的地方，下一代模型可能会有不同的表现。

Team makeup: blurring roles团队构成：角色模糊化

Claude and AI have reshaped roles across the team. Our PMs code a lot now, which is fun to see. With Claude, you have nontraditional coders now being able to do more engineering, and you have engineers who take on things like content and design, work that were traditionally not on the technical side. Claude 和 AI 重塑了团队中的角色。我们的产品经理现在也大量写代码，这很有趣。借助 Claude，非传统的编码者现在能够做更多工程工作，而工程师们也开始承担内容和设计等传统上不属于技术范畴的任务。

On the Claude Code engineering team, I’ve indexed heavily on two profiles. One is creative builders with product sense: the dreamers who are deeply curious and passionate about shipping products that solve problems. The other one is engineers with deep systems expertise. For example, when I joined the team, I noticed we were missing experts with systems backgrounds and we needed that when building Claude Code on the Web, to ensure we can run Claude everywhere. 在 Claude Code 工程团队，我主要关注两类画像。一类是具备产品感知的创意构建者：对解决问题的产品充满好奇和热情的梦想家。另一类是拥有深厚系统专业知识的工程师。例如，我加入团队时注意到缺少系统背景的专家，而在 Web 上构建 Claude Code、确保 Claude 能在各处运行时，这类人才至关重要。

What I index on less, on the other hand, is raw throughput; the models handle that. The more important question is where you still need human expertise, and that’s where I’d focus.相对而言，我对原始吞吐量的关注较少——模型会处理这些。更重要的问题是你仍然需要人类专业知识的地方，这正是我会重点关注的。

How we rolled out our new norms我们如何推出新规范

As these norms changed, some aspects were mandated as team principles and others we let small sub-teams (pods) figure out on their own. There is a set of the Claude Code core team principles that are non-negotiable “must dos”:随着这些规范的变化，有些方面被设定为团队原则，其他则交由小子团队（pods）自行决定。以下是 Claude Code 核心团队的不可协商的“必须做”原则：

• Relentlessly dogfood your product: Every Claude Code team member, including cross-functional partners, uses Claude Code (and also Claude Cowork). We’re always thinking of ways to get Claude to help us do our work faster, and more efficiently. 坚持自家产品：每位 Claude Code 团队成员，包括跨职能合作伙伴，都使用 Claude Code（以及 Claude Cowork）。我们始终在思考如何让 Claude 帮助我们更快、更高效地完成工作。
• Keep the team flat as possible. When I joined Claude Code I wanted every manager to start out as an IC first, learn how to be an effective engineer on the team by shipping, and really live through and understand what it’s like to be an engineer at Anthropic. We have one overall team mission on Claude Code and Claude Cowork. Managers support pods of work while keeping the team agile so people can move to where the work is.尽可能保持团队扁平。当我加入 Claude Code 时，我希望每位经理先以个人贡献者（IC）身份开始，通过交付工作学习如何成为高效工程师，真正体验并理解在 Anthropic 做工程师的感受。我们在 Claude Code 和 Claude Cowork 上有统一的团队使命。经理们支持各个 pod 的工作，同时保持团队敏捷，让人们可以随需求流动。
• Don’t  hesitate to kill processes that no longer work: Finally, we relentlessly question why we do things the way we do. When something doesn’t make sense anymore, team members have explicit permission to question and kill old processes. 不要犹豫去淘汰不再有效的流程：最后，我们始终质疑为何要按既定方式行事。当某件事不再有意义时，团队成员拥有明确的权限去质疑并终止旧流程。

Within these few rules, though, each pod has a lot of agency. They have room to adapt how they use Claude to do triage, how they run any planning rituals or standups, and which workflows get “Claudified” first. 在这几条规则之内，每个 pod 仍拥有很大的自主权。他们可以自行决定如何使用 Claude 进行分流、如何开展规划仪式或站会，以及哪些工作流先进行“Claudified”。

How to know your new processes are sticking如何判断新流程是否落地

Here are three numbers every engineering leader should start tracking now as they roll out changes.以下是每位工程领袖在推行变革时应立即开始跟踪的三个指标。

• Onboarding ramp time goes down: How soon can an engineer, a designer, or a PM start being effective? On our team this is much faster than a year ago, and engineers ship real code now within their first week.新人上手时间缩短：工程师、设计师或产品经理多久能开始产生有效贡献？在我们团队，这一速度比一年前快得多，工程师现在在第一周就能交付真实代码。
• PR cycle time goes down: This one's interesting to dig into because it might help you identify where your pipeline is struggling to scale. As we’re generating so much more code, sometimes build systems and continuous integration (CI) may struggle to keep up.PR 周期时间下降：这个指标值得深入挖掘，因为它可能帮助你发现流水线在哪些环节难以扩展。随着我们生成的代码量激增，构建系统和持续集成（CI）有时会跟不上。
• Claude-assisted commits going up: For us, by default, every commit is Claude-assisted. I don't think I've seen a non-Claude-assisted commit in the last four months.Claude 辅助的提交比例上升：对我们而言，默认情况下每一次提交都是 Claude 辅助的。我觉得在过去四个月里已经没有看到过非 Claude 辅助的提交。

On the third bullet, don't confuse throughput with success. Throughput is one metric, but the real metric is measuring the thing you're trying to solve. With the right alignment, throughput can help you solve problems faster.在第三点上，别把吞吐量误认为成功。吞吐量是一个指标，但真正的指标是衡量你想要解决的事情。只要对齐正确，吞吐量可以帮助你更快地解决问题。

Getting started入门指南

If I were to leave you with one thing: pick your noisiest workflow. That could be your most expensive workflow, the one you might be dreading, or that your team doesn't look forward to. And ask: is it still serving its purpose? If so, can you automate it? 如果让我给你留下唯一一件事：挑选出你最嘈杂的工作流。它可能是最昂贵的工作流、你最害怕的工作流，或者是团队不期待的工作流。然后问自己：它仍在发挥作用吗？如果是，能否将其自动化？

I was once on a team that had an expensive weekly review, with a large number of  people in a meeting room. I noticed everybody was on their laptops except when it was their time to give a status report. They would pop their head up, say the status, and go back down to their laptops. I asked one simple question: “Why are we having this meeting again? It seems like an expensive use of our time.” And just that one question made everyone realize it wasn’t needed. So we canceled it.我曾在一个团队里参加每周一次的昂贵评审，会议室里坐满了人。我注意到大家都在笔记本电脑前，只有轮到他们汇报进度时才抬头说几句，然后又低头继续工作。我问了一个简单的问题：“我们为什么还要开这个会？这似乎是对时间的昂贵浪费。”仅仅这个问题就让大家意识到会议没有必要，于是我们取消了它。

So, ask yourself: what's one piece of your engineering workflow that you might consider automating or even dropping altogether? 所以，问问自己：你们的工程工作流中，有哪一环节可以考虑自动化，甚至彻底去掉？

‍