在 2026 年旧金山举办的 Code w/ Claude 大会上，Claude Code 与 Claude Cowork 工程总监 Fiona Fung 详细阐述了，当智能体编程成为默认工作方式后，团队流程与结构发生了怎样的变化。
- 分类Claude Code
- 产品Claude Code
- 日期2026 年 6 月 3 日
- 阅读时间5分钟
- https://claude.com/blog/running-an-ai-native-engineering-org
多年来，工程人力一直是构建应用成本高昂的部分。我们过去围绕软件规划和交付所采用的所有流程——先是瀑布模型，后是敏捷开发——都是基于这一成本构建的。
我的职业生涯始于 2000 年代初期，当时在 Visual Studio 团队工作。那个年代，我们通过 CD-ROM 交付软件，受制于硬性的制造截止日期。一旦我们能够在线分发软件，便开始持续增加更新频率。如今，我们再次改变工作方式，这次变革的核心是编写软件所需的时间和人力。
在 Claude Code 团队，编写代码、编写测试和重构已经很少再拖慢我们的速度。但当智能体编程消除了实际键入代码的需求后，瓶颈并未消失。取而代之的是验证、代码审查和安全问题。
现在，我们所有人都能非常快速地生成大量代码，但这同时也带来了新的问题：这段代码正确吗？如何维护它？以及我从其他工程领导者那里收到的最常见问题之一：“人类如何跟上你们进行代码审查的速度？”
那些悄然失效的流程
我们当初设立所有流程都是有原因的——为了弥补某个缺口或让某件事运作得更好。但当那个缺口不复存在、这些流程变得过时时，它们很少会自行消失。当 Claude Code 团队开始将智能体编程作为默认工作方式后，我们许多现有的流程都失效了。以下是我们重写的规范及其原因。
规划：将路线图转变为即时模式
过去的常态是花大量时间进行预先规划，因为编码时间很昂贵。当我刚加入 Claude Code 团队时，我们制定了一份相当不错的六个月路线图，但由于 Claude Code 的出现，太多事情发生了变化，导致这份路线图在第三个月就过时了。
工程速度和吞吐量如今已截然不同，因此我们规划冲刺的方式也发生了变化。我称之为即时（JIT）规划，几乎就像即时编译：如何在正确的时间做恰到好处的事？我们的规划流程已从设计文档转向在 PR 或原型中进行讨论。这个领域发展太快，所以我们不做大量的产品评审。我们现在的流程是：先做原型，让大量内部用户试用，然后根据他们的反馈采取行动。
上下文收集：问 Claude，而不是问作者
过去工程师写代码时，要回答大多数问题，第一步是找到写代码的人。现在，由于我们所有的 PR 都有 Claude 辅助，“谁做了这个改动？”已经不够了。我们的新常态是深入一层：你真正需要知道的是什么？例如：你是想找导致性能回退的人？找能回答客户问题的专家？还是想了解某个决策的背景？你向 Claude 提出那个问题，并考虑 Claude 是否可以直接回答，同时还能提供更多数据和上下文。
在 Claude Code 团队，无论问题是什么，我们的流程都会问一句：“有没有办法自动化？”例如，让 Claude 每天早上汇总客户反馈渠道，这件事从我以前边喝咖啡边手动完成的习惯，变成了我在后台自动运行的任务。
代码审查：信任但要验证
我们大量使用代码审查。Claude 负责所有的代码风格和 lint 检查、PR 反馈请求、在完整提交前捕获并修复 bug，以及添加测试。而我们仍然明确需要人类介入的地方是专业知识。
新的常态是在关键之处进行人工审查：对于法律审查，我始终希望我的法务合作伙伴参与风险容忍度的判断。对于信任边界和安全敏感的代码，我需要领域专家。产品经理和设计师也需要参与产品感觉和品味的把控。
不过，持续评估很重要，因为信任与验证之间的恰当平衡会随着模型的改进而不断变化。今天需要人类来做的事情，到了下一代模型可能就不同了。
团队构成：角色界限模糊
Claude 和 AI 已经重塑了整个团队的角色。现在我们的产品经理经常写代码，这很有趣。有了 Claude，非传统意义上的编码人员现在能够承担更多工程工作，而工程师们则开始涉足内容和设计等传统上不属于技术侧的工作。
在 Claude Code 工程团队，我重点考察两类人才。一类是具有产品直觉的创意型构建者：那些充满好奇心、对交付能解决问题的产品充满热情的梦想家。另一类是拥有深厚系统专业知识的工程师。例如，当我加入团队时，我注意到我们缺少具有系统背景的专家，而在 Web 端构建 Claude Code 时，我们需要确保 Claude 能在任何地方运行。
另一方面，我不太看重的是原始吞吐量；模型会处理这个。更重要的问题是你仍然需要人类专业知识的领域，而这正是我关注的重点。
| 过去 | 现在 | |
|---|---|---|
| 规划 | 六个月的产品路线图。 | 即时（JIT）规划：先做原型，让内部用户试用，然后根据他们的反馈采取行动。 |
| 上下文收集 | 找到写那段代码的人，直接去问他们。 | 先问 Claude。然后再问你所问的事情是否可以被自动化。 |
| 代码审查 | 人类审查所有内容。 | Claude 负责处理代码风格、错误和测试。人类负责审查需要领域专业知识的部分。 |
| 团队构成 | 固定角色：工程师写代码，产品经理做规划，设计师搞设计。 | 角色模糊化：产品经理做原型，工程师承担设计和上下文收集工作。招聘时侧重创意型构建者和深厚系统专业知识人才。 |
我们如何推行新规范
随着这些规范的变化，有些方面被定为团队必须遵守的原则，而其他方面我们则让小型子团队自行摸索。Claude Code 核心团队有一套不可妥协的“必须执行”原则：
- 坚持不懈地吃自己的狗粮：每一位 Claude Code 团队成员，包括跨职能合作伙伴，都要使用 Claude Code（以及 Claude Cowork）。我们一直在思考如何让 Claude 帮助我们更快、更高效地完成工作。
- 尽可能保持团队扁平化。我加入 Claude Code 时，希望每位管理者首先以独立贡献者的身份起步，通过交付产品学会如何成为团队中高效的工程师，并真正经历和理解在 Anthropic 做一名工程师是怎样的体验。我们在 Claude Code 和 Claude Cowork 上有一个统一的团队使命。管理者在支持各个工作小组的同时，保持团队的敏捷性，让人们能够灵活地转移到需要他们的地方去。
- 果断淘汰不再有效的流程：最后，我们会不断追问为什么我们要以现在这种方式做事。当某件事不再合理时，团队成员被明确授权可以质疑并废除旧的流程。
不过，在这些为数不多的规则之下，每个工作小组都拥有很大的自主权。他们可以灵活调整如何使用 Claude 进行任务分类，如何开展任何规划仪式或站会，以及哪些工作流程会优先实现“Claude 化”。
如何判断你的新流程是否被真正采纳
以下是每位工程领导者在推行变革时，现在就应该开始追踪的三个关键指标。
- 新员工上手时间缩短：一名工程师、设计师或产品经理需要多久才能开始高效工作？在我们团队，这个时间比一年前快得多，工程师现在入职第一周就能交付真实代码。
- 拉取请求周期缩短：这个指标值得深入分析，因为它可能帮助你找出流程中难以扩展的瓶颈。随着我们生成的代码量大幅增加，有时构建系统和持续集成可能难以跟上节奏。
- Claude 辅助的提交量上升：对我们来说，默认情况下，每一次提交都是 Claude 辅助完成的。我想在过去四个月里，我都没见过一次非 Claude 辅助的提交。
关于第三点，不要把吞吐量等同于成功。吞吐量只是一个指标，但真正的衡量标准是看你是否解决了你试图解决的问题。在正确的对齐下，吞吐量可以帮助你更快地解决问题。
如何开始
如果我只留给你一句话：选择你团队中最令人头疼的工作流程。它可能是你最昂贵的工作流程，也可能是你害怕面对、或者你的团队不期待去做的那个。然后问一问：它是否还在发挥其应有的作用？如果是，你能把它自动化吗？
我曾在一个团队工作，当时我们每周都要开一次成本高昂的评审会，会议室里坐满了人。我注意到，除了轮到每个人汇报进度时，大家全程都在低头看笔记本电脑。他们会抬起头，说完进度，然后又埋头回到电脑前。我问了一个简单的问题：“我们为什么还要开这个会？这看起来既费钱又费时。”就这一个问题，让所有人都意识到这个会确实没必要开。于是我们把它取消了。
所以，问问你自己：在你的工程工作流中，有哪些环节可以考虑自动化，甚至直接砍掉？
用 Claude 改变你组织的运作方式。
At Code w/ Claude SF 2026, Director of Engineering for Claude Code and Claude Cowork Fiona Fung walked through how the team’s processes and structure changed once agentic coding became the default way of working.
- Category
- ProductClaude Code
- DateJune 3, 2026
- Reading time5min
- https://claude.com/blog/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.
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.
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.
Planning: shift roadmaps to 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.
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.
Context gathering: ask Claude, not the author
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.
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.
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.
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.
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.
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.
| Before | After | |
|---|---|---|
| Planning | Six-month product roadmaps. | Just-in-time (JIT) planning: prototype, put internal users on it, and act on their feedback. |
| Context gathering | Find the person who wrote the code and ask them. | Ask Claude first. Then ask whether what you are asking about can be automated. |
| Code review | Humans review everything. | Claude handles style, bugs, and tests. Humans review where domain expertise is important. |
| Team makeup | Fixed roles: engineers write code, PMs plan, designers design. | Roles blur: PMs prototype, engineers take on design and context. Hire for creative builders and deep systems expertise. |
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”:
- 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.
- 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.
- 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.
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.
- 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.
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?