Anthropic自曝内部是如何使用AI的

这次的 Anthropic，把自己给曝光了。

这家推出 Claude 的公司，刚刚发布了一份报告，调查了 132 名内部工程师，进行了 53 场深度访谈，还分析了 20 万条 Claude Code 的使用记录—— 就是想搞清楚 AI 到底是怎么改变他们自己的工作的。

结果嘛，有点像照镜子： 既看到了希望，也看到了隐忧。

生产力确实涨了

工程师们自报的数据是这样的： 一年前，他们在 28% 的工作中使用 Claude，获得 20% 的生产力提升；现在，他们在 59% 的工作中使用 Claude，生产力提升了 50%。

这意味着，一年之内，使用率和生产力提升都翻了不止一倍。

而且这不是「 干得更快 」，而是「 干得更多 」——调查显示， 大多数任务类别的时间消耗略微减少，但产出量却大幅增加。

而有意思的是， 27% 的 Claude 辅助工作，是以前根本不会去做的事情 。比如做一些「 有了更好，没有也行 」的小工具、交互式数据看板、或者手动做起来不划算的探索性工作。

大家都变「全栈」了

Claude 正在模糊专业的边界。

后端工程师开始写前端界面，研究人员开始做数据可视化， 甚至非技术人员也在用 Claude 做数据分析和解决 Git 问题。

一位后端工程师说，他用 Claude 做了一个复杂的 UI，设计师看了都惊了：「 等等，这是你做的？ 」他回答说：「 不，是 Claude 做的——我只是提需求。 」

从 Claude Code 的使用数据也能看出来：

六个月前，Claude 平均连续执行 10 个动作就需要人类介入；现在，它可以连续执行 20 个动作，处理更复杂的工作流程，需要人类干预的频率更低了。

但，技能会生锈吗？

能力边界扩展的同时，一些工程师开始担心另一个问题： 自己的核心技能会不会退化？

有人说：「以前自己去 debug 一个难题，会花时间读文档、读代码——这些东西虽然和问题本身没有直接关系，但你在这个过程中建立了对整个系统的理解。现在 Claude 可以直接带你到问题所在，这种『顺带学习』的机会就少了很多。」

还有人提到了一个悖论： 有效使用 Claude 需要监督能力，而监督 Claude 需要的正是那些可能因为过度依赖 AI 而退化的编程技能。

一位资深工程师说，如果自己是刚入行的新人，会更担心这个问题：「我主要在那些我已经知道答案应该是什么样的任务上使用 AI。这种判断力是靠『笨办法』练出来的……但如果我还是个新人，我觉得需要非常刻意地去锻炼自己的能力，而不是盲目接受模型输出。」

有人开心，有人怀念

工程师们对这种变化的感受 分歧很大 。

有人觉得是解放：「我以为我真的很喜欢写代码，结果发现，我喜欢的其实是写代码能带来的东西。」

有人则有些怀念：「整天提示 Claude 并不那么有趣或有成就感。自己戴上耳机、进入心流状态、亲手实现一个东西，那种感觉要好多了。」

还有人直接接受了这个 trade-off：「确实有些东西我会怀念——比如重构代码时进入那种禅定般的心流状态。但我现在生产力高了太多，这点代价我愿意付。」

同事之间的互动变少了

Anthropic(@AnthropicAI) 引用了一位员工的话：

我喜欢和人一起工作，现在「需要」他们的时候变少了，这让我有点难过。

这是调查中一个明显的主题： Claude 成了大家遇到问题时的第一选择，而不是同事。

有人觉得这样挺好：「我不用担心占用同事的时间了。」

但也有人不喜欢这种变化：「我真的不喜欢大家遇到问题就说『你问过 Claude 了吗？』我非常珍视和人面对面工作的机会。」

传统的导师制度也在受到冲击。一位资深工程师说：「 现在初级员工不太来问我问题了，虽然他们的问题确实解决得更快、学得也更快，但这让我有点难过。 」

未来会怎样？

很多工程师说，自己的角色正在从「 写代码的人 」变成「 管理 AI 的人 」。

有人估计自己 70% 以上的工作已经从「 写新代码 」变成了「 审代码和改代码 」；有人已经在同时运行好几个 Claude 实例，并且预见未来自己要对 1 个、5 个、甚至 100 个 Claude 的工作负责。

但对于更长远的未来， 不确定性是普遍的 。

有人说：「 短期我很乐观，但长期来看，我觉得 AI 最终会做所有事情，让我和很多人变得无关紧要。 」

有人更直接：「 感觉每天上班就是在让自己失业。 」

也有人更乐观：「 我担心初级开发者，但我也知道初级开发者往往是对新技术最渴望的群体。总体来说，我对这个职业的发展方向感到乐观。 」

但更多人承认：「 没人知道会发生什么……重要的是保持适应力。 」

接下来的打算

Anthropic 表示，他们正在和内部的工程师、研究人员、管理层讨论如何应对这些机遇和挑战，包括如何促进团队协作、如何支持职业发展、如何建立 AI 辅助工作的最佳实践。

他们也在把这项研究扩展到工程师之外的更多员工群体，并计划在 2026 年分享更具体的方案。

用他们自己的话说：

Anthropic 是一个「负责任的职场转型实验室」，不仅要研究 AI 如何改变工作，还要试验如何周全地应对这种转型，从自己开始。

原文：

How AI is transforming work at Anthropic

2025年12月3日

AI如何改变Anthropic的工作方式

URL来源：https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

AI如何改变我们的工作方式？我们 之前的研究 关注AI的经济影响，涵盖了整个劳动力市场的各种不同工作。但如果我们更详细地研究一些最早采用AI技术的人——也就是我们自己——会怎样呢?

将镜头对准内部，2025年8月我们调查了132名Anthropic工程师和研究人员，进行了53次深入的定性访谈，并研究了内部 Claude Code 使用数据，以了解AI使用如何改变Anthropic的工作。我们发现AI的使用正在根本性地改变软件开发人员的工作性质，既带来希望也带来担忧。

我们的研究揭示了一个正在经历重大转型的工作场所：工程师完成了更多工作，变得更加"全栈"(能够胜任超出其正常专业领域的任务)，加快了学习和迭代速度，并处理了以前被忽视的任务。这种广度的扩展也让人们思考权衡问题——一些人担心这可能意味着失去更深层的技术能力，或变得不太能够有效地监督Claude的输出，而另一些人则拥抱这个机会，以更广阔和更高层次的方式思考。一些人发现更多的AI协作意味着他们与同事的协作减少了；一些人想知道他们是否最终会让自己失业。

我们认识到，研究AI在一家构建AI的公司的影响意味着代表一个特权地位——我们的工程师可以早期访问尖端工具，在一个相对稳定的领域工作，并且他们自己也在为影响其他行业的AI转型做出贡献。尽管如此，我们认为研究和发布这些发现总体上是有用的，因为Anthropic内部工程师正在发生的事情可能仍然是更广泛社会转型的启示性预兆。我们的发现暗示了一些可能需要跨行业早期关注的挑战和考虑因素(尽管请参阅 附录 中的局限性部分了解注意事项)。在收集这些数据时，Claude Sonnet 4和Claude Opus 4是最强大的可用模型，而能力还在继续提升。

更强大的AI带来了生产力收益，但也提出了关于保持技术专长、保留有意义的协作以及为可能需要在AI增强工作场所中采用新的学习、指导和职业发展方法的不确定未来做准备的问题。我们在下面的"展望未来"部分讨论了我们正在采取的一些初步步骤来在内部探索这些问题。我们还在最近的博客文章中探讨了潜在的政策应对措施，关于 AI相关经济政策的想法 。

主要发现

在本节中，我们简要总结了调查、访谈和Claude Code数据的发现。我们在下面的后续章节中提供详细的发现、方法和注意事项。

调查数据

Anthropic工程师和研究人员最常使用Claude修复代码错误和了解代码库 。 调试和代码理解是最常见的用途(图1)。

人们报告Claude使用量增加和生产力提升。 员工自我报告在60%的工作中使用Claude，实现了50%的生产力提升，比去年同期增加了2-3倍。这种生产力表现为每个任务类别的时间略有减少，但输出量显著增加(图2)。

27%的Claude辅助工作包括原本不会完成的任务 ， 例如扩展项目、制作好用但非必需的工具(如交互式数据仪表板)以及如果手动完成不具成本效益的探索性工作。

大多数员工频繁使用Claude，同时报告他们只能"完全委托"0-20%的工作给它。 Claude是一个持续的合作者，但使用它通常涉及主动监督和验证，尤其是在高风险工作中——而不是完全不需要验证就交出任务。

定性访谈

员工正在培养AI委托的直觉 。工程师倾向于委托容易验证的任务，即他们"可以相对容易地嗅探正确性"的任务、低风险的任务(例如"一次性调试或研究代码")或无聊的任务("我越兴奋做这个任务，就越不可能使用Claude")。许多人描述了一个信任进展过程，从简单任务开始，逐渐委托更复杂的工作——虽然他们目前保留大多数设计或"品味"任务，但随着模型改进，这个界限正在重新协商。

技能集正在扩展到更多领域，但有些人的练习在减少。 Claude使人们能够将技能扩展到软件工程的更多领域("我可以非常胜任地处理前端或事务性数据库...而以前我会害怕触碰这些东西")，但一些员工也担心，矛盾的是，编写和批评代码所需的更深层技能可能会退化——"当产生输出如此容易和快速时，真正花时间学习东西变得越来越困难。"

与编码工艺的关系发生变化。 一些工程师拥抱AI辅助并专注于结果("我以为我真的喜欢写代码，但我认为我实际上只是喜欢从写代码中得到的东西")；其他人说"我确实怀念[写代码]的某些部分。"

工作场所的社交动态可能正在改变。 Claude现在是以前会问同事的问题的第一站——一些人因此报告指导和协作机会减少。("我喜欢与人一起工作，我现在'需要'他们的次数减少了，这很令人难过...初级员工不像以前那样经常来问我问题。")

职业演变和不确定性。 工程师报告转向管理AI系统的更高级别工作，并报告显著的生产力提升。然而，这些变化也引发了关于软件工程作为一种职业的长期轨迹的问题。一些人对未来表达了矛盾的感受："我对短期感到乐观，但从长期来看，我认为AI最终会做所有事情，让我和许多其他人变得无关紧要。"其他人强调真正的不确定性，只是说"很难说"他们的角色在几年后会是什么样子。

Claude Code使用趋势

Claude正在更自主地处理越来越复杂的任务 。 六个月前，Claude Code会在需要人类输入之前自行完成约10个操作。现在，它通常处理约20个操作，需要更少的人类引导来完成更复杂的工作流程(图3)。工程师越来越多地将Claude用于复杂任务，如代码设计/规划(从1%增加到10%的使用率)和实现新功能(从14%增加到37%)(图4)。

Claude修复了很多"小麻烦"。 8.6%的Claude Code任务涉及修复改善生活质量的小问题，比如为了可维护性重构代码(即"修复小麻烦")，人们说这些通常会被降低优先级。这些小修复可能累积成更大的生产力和效率收益。

每个人都变得更加"全栈"。 不同团队以不同方式使用Claude，通常是为了增强他们的核心专业知识——安全团队用它来分析不熟悉的代码，对齐与安全团队用它来构建数据的前端可视化，等等(图5)。

调查数据

我们调查了来自整个组织的132名Anthropic工程师和研究人员关于他们的Claude使用情况，以更好地了解他们日常如何使用它。我们通过内部沟通渠道和直接联系代表研究和产品职能的不同团队的员工来分发调查。我们在附录中包含了局限性部分，提供了更多方法论细节，我们正在分享 我们的调查问题 ，以便其他人可以评估我们的方法并将其调整用于自己的研究。

人们将Claude用于什么编码任务？

我们要求被调查的工程师和研究人员评估他们多久使用Claude进行各种类型的编码任务，例如"调试"(使用Claude帮助修复代码中的错误)、"代码理解"(让Claude解释现有代码以帮助用户理解代码库)、"重构"(使用Claude帮助重组现有代码)和"数据科学"(例如让Claude分析数据集并制作条形图)。

以下是最常见的日常任务。大多数员工(55%)每天都使用Claude进行调试。42%的人每天使用Claude进行代码理解，37%的人每天使用Claude实现新功能。不太频繁的任务是高级设计/规划(可能是因为这些是人们倾向于保留在人手中的任务)，以及数据科学和前端开发(可能是因为它们总体上是不太常见的任务)。这大致与"Claude Code使用趋势"部分报告的Claude Code使用数据分布一致。

图1：各种编码任务(y轴)的每日用户比例(x轴)。

图1：各种编码任务(y轴)的每日用户比例(x轴)。

使用和生产力

员工自我报告，12个月前，他们在28%的日常工作中使用Claude，并从中获得了+20%的生产力提升，而现在，他们在59%的工作中使用Claude，平均实现了+50%的生产力提升。(这大致证实了我们在 整个工程组织采用Claude Code 时看到的每个工程师每天合并的拉取请求——即成功合并到代码中的更改——增加了67%。)年度比较非常显著——这表明这两个指标在一年内增加了2倍以上。使用率和生产力也高度相关，在分布的极端，14%的受访者通过使用Claude将生产力提高了100%以上——这些是我们内部的"超级用户"。

为了对这一发现(以及下面其他自我报告的生产力发现)进行说明，生产力很难精确测量(参见 附录 了解更多局限性)。 METR最近的工作 ，一个AI研究非营利组织，显示有经验的开发人员在高度熟悉的代码库上使用AI工作时高估了他们从AI获得的生产力提升。话虽如此，METR确定的导致生产力低于预期的因素(例如AI在大型复杂环境中表现较差，或需要大量隐性知识/上下文的地方)与我们员工说他们不委托给Claude的任务类型密切对应(见下面的 AI委托方法 )。我们跨任务自我报告的生产力提升可能反映了员工发展战略性AI委托技能——这是METR研究中没有考虑的。

当询问员工，对于他们目前使用Claude的任务类别，它如何影响他们的总体时间花费和该任务类别的工作输出量时，出现了一个有趣的生产力模式。在几乎所有任务类别中，我们看到时间花费净减少，以及更大的输出量净增加：

图2：按任务(y轴)划分的时间花费(左图)和输出量(右图)的影响。每个图上的x轴对应于自我报告的减少(负值)、增加(正值)或没有变化(垂直虚线)在Claude辅助任务类别的时间花费或输出量，与不使用Claude相比。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude进行每个任务类别的受访者。

图2：按任务(y轴)划分的时间花费(左图)和输出量(右图)的影响。每个图上的x轴对应于自我报告的减少(负值)、增加(正值)或没有变化(垂直虚线)在Claude辅助任务类别的时间花费或输出量，与不使用Claude相比。误差条显示95%置信区间。圆圈面积与每个评分点的响应数量成正比。仅包括报告使用Claude进行每个任务类别的受访者。

然而，当我们深入挖掘原始数据时，我们看到时间节省响应集中在两端——一些人在Claude辅助的任务上花费 更多 时间。

为什么会这样？人们通常解释说，他们必须对Claude的代码进行更多调试和清理(例如"当我把代码写进死胡同时")，并承担更多认知开销来理解Claude的代码，因为他们自己没有编写它。一些人提到在使能意义上花费更多时间——一个人说使用Claude帮助他们"坚持完成我以前会立即放弃的任务"；另一个人说它帮助他们进行更彻底的测试以及在新代码库中进行更多学习和探索。似乎总体而言，经历时间节省的工程师可能是那些为Claude设定快速可验证任务范围的人，而那些花费更多时间的人可能正在调试AI生成的代码或在Claude需要更多指导的领域工作。

从我们的数据中也不清楚报告的时间节省被重新投资到哪里——是投入到额外的工程任务、非工程任务、与Claude互动或审查其输出，还是工作之外的活动。我们的任务分类框架没有捕捉到工程师可能分配时间的所有方式。此外，时间节省可能反映了自我报告中的感知偏差。需要进一步研究来理清这些影响。

输出量增加更直接和显著；所有任务类别都有更大的净增加。当我们考虑到人们报告的是任务类别(如整体的"调试")而不是单个任务时，这种模式是有道理的——即人们可以在调试作为一个类别上花费略少的时间，同时总体上产生更多的调试输出。生产力很难直接测量，但这些自我报告的数据表明，AI主要通过更大的输出量在Anthropic实现生产力提升。

Claude实现新工作

我们好奇的一件事是：Claude是否实现了质量上新的工作类型，还是Claude辅助的工作最终会由员工完成(尽管可能速度较慢)?

员工估计，如果没有Claude，他们27%的Claude辅助工作不会完成。工程师提到使用AI进行扩展项目、好用但非必需的东西(例如交互式数据仪表板)、有用但乏味的工作如文档和测试，以及手动操作不具成本效益的探索性工作。正如一个人解释的那样，他们现在可以修复更多以前损害生活质量的"小麻烦"，例如重构结构不良的代码，或构建"帮助更快完成另一项任务的小工具"。我们也在使用数据分析中寻找这一点，并 发现 8.6%的Claude Code任务涉及"小麻烦修复"。

另一位研究人员解释说，他们同时运行了许多版本的Claude，所有版本都在探索问题的不同方法：

人们倾向于将超级强大的模型视为单个实例，就像获得一辆更快的汽车。但拥有一百万匹马...允许你测试一堆不同的想法...当你有额外的广度去探索时，它是令人兴奋和更有创造性的。

正如我们将在下面的部分中看到的，这项新工作通常涉及工程师处理超出其核心专业知识的任务。

有多少工作可以完全委托给Claude？

尽管工程师经常使用Claude，但超过一半的人表示他们只能"完全委托"0-20%的工作给Claude。(值得注意的是，受访者对"完全委托"的解释可能存在差异——从完全不需要验证的任务到只需要轻度监督就足够可靠的任务。)在解释原因时，工程师描述了与Claude主动和迭代地工作，并验证其输出——特别是对于复杂任务或代码质量标准至关重要的高风险领域。这表明工程师倾向于与Claude密切合作并检查其工作，而不是在没有验证的情况下交出任务，并且他们为"完全委托"设定了高标准。

定性访谈

虽然这些调查结果揭示了显著的生产力提升和工作模式的变化，但它们提出了工程师实际上如何日复一日地体验这些变化的问题。为了了解这些指标背后的人性维度，我们对53名回应调查的Anthropic工程师和研究人员进行了深入访谈，以更深入地了解他们如何看待和感受工作场所的这些变化。

AI委托方法

工程师和研究人员正在开发各种策略，以在工作流程中有效利用Claude。人们通常委托以下任务：

超出用户上下文且复杂度低 ：

"我将Claude用于我上下文较少但认为总体复杂度也较低的事情。"

"我遇到的大多数基础设施问题并不困难，可以由Claude处理...我不太了解Git或Linux...Claude很好地弥补了我在这些领域的经验不足。"

容易验证： "对于验证工作量与创建工作量相比不大的所有事情，它绝对令人惊叹。"

定义明确或自包含： "如果项目的子组件与其余部分充分解耦，我会让Claude尝试一下。"

代码质量不是关键： "如果是一次性调试或研究代码，它会直接交给Claude。如果概念上困难或需要某种非常特定类型的调试注入，或者是设计问题，我自己做。"

重复或无聊： "我越兴奋做这个任务，就越不可能使用Claude。而如果我感到很多阻力...我经常发现与Claude开始关于任务的对话更容易。" 在我们的调查中，平均而言，人们说44%的Claude辅助工作包括他们不愿意自己做的任务。

提示比执行更快： "[对于]我预计需要不到10分钟的任务...我可能不会费心使用Claude。" "冷启动问题可能是现在最大的阻碍。所谓冷启动，我是指我对我们团队的代码库如何工作有很多内在信息，而Claude默认不会有...我可以花时间尝试迭代完美的提示[但]我只会自己去做。"

我们员工在委托决策中提到的这些因素与 METR的外部研究 中发现解释AI相关生产力放缓的因素(如开发人员对代码库的高度熟悉、大型和复杂的存储库)相似。我们访谈中对这些委托标准的趋同表明，适当的任务选择是AI生产力提升的重要因素(在未来的生产力研究中应该仔细控制)。

信任但验证

许多用户描述了他们的Claude使用进展，涉及随着时间的推移委托越来越复杂的任务："起初我用AI工具问关于Rust编程语言的基本问题...最近，我一直在用Claude Code进行我所有的编码。"

一位工程师将信任进展比作采用其他技术，如Google地图：

一开始我只会用[Google地图]查找我不知道的路线...这就像我使用Claude编写我不知道的SQL，但不要求它编写我知道的Python。然后我开始在我大致知道的路线上使用Google地图，但也许我不知道最后一英里...今天我一直使用Google地图，即使是日常通勤。如果它说走不同的路，我就会走，并相信它考虑了所有选项...我今天以类似的方式使用Claude Code。

工程师们对是否在专业领域内外使用Claude存在分歧。一些人将其用于"边缘"领域以节省实施时间；其他人更喜欢他们可以验证输出的熟悉领域("我以这样一种方式使用Claude，即我仍然完全理解它在做什么")。一位安全工程师强调了当Claude提出"以危险方式非常聪明的解决方案，那种非常有才华的初级工程师可能会提出的东西"时，经验的重要性。也就是说，这是只有具有判断力和经验的用户才能识别为有问题的东西。

其他工程师对两种类型的任务都使用Claude，要么以实验方式("我基本上总是使用Claude对任何编码问题进行第一次尝试")，要么根据他们在任务中的专业水平调整他们的方法：

我将工具用于核心专业领域的事情(作为加速器，我知道期望什么并可以有效地指导代理)，以及略微超出我专业领域的事情，我大致知道期望什么，但Claude能够填补我记忆中的空白或对特定定义的熟悉程度。

如果是我特别精通的东西，我会更加自信并告诉Claude它需要追踪什么。如果是我不确定的东西，我经常要求它成为专家，并给我选项和关于我应该考虑和研究的事情的见解。

人们为自己保留什么任务？

人们一致表示，他们不会将Claude用于涉及高级或战略思维的任务，或需要组织上下文或"品味"的设计决策。一位工程师解释说："我通常保留高级思维和设计。我从新功能开发到调试委托任何我能做的事情。"这反映在我们的调查数据中，显示设计和规划任务的生产力提升最少(图2)。然而，许多人将委托界限描述为"移动目标"，随着模型改进定期重新协商(下面，Claude Code使用数据显示现在编码设计/规划使用率相对比六个月前更高)。

技能转型

新能力...

调查发现，27%的Claude辅助工作在没有它的情况下不会完成，这反映了一个更广泛的模式：工程师使用AI在核心专业知识之外工作。许多员工报告完成以前超出其专业知识的工作——后端工程师构建UI；研究人员创建可视化。一位后端工程师描述通过与Claude迭代构建复杂UI："它做得比我做得好得多。我不可能做到，绝对不可能按时做到...[设计师们]说'等等，你做了这个？'我说'不，Claude做了这个——我只是提示它。'"

工程师报告"变得更加全栈...我可以非常胜任地处理前端、事务性数据库或API代码，而以前我会害怕触碰我不太专业的东西。"这种能力扩展实现了更紧密的反馈循环和更快的学习——一位工程师说，"几周的流程"包括构建、安排会议和迭代，可以变成"几个小时的工作会议"，同事在场进行实时反馈。

总的来说，人们对他们快速原型设计、并行工作、减少辛劳以及普遍提高雄心水平的新能力感到热情。一位高级工程师告诉我们，"这些工具肯定使初级工程师更有生产力，对他们将承担的项目类型更加大胆。"一些人还说，使用Claude降低的"激活能量"使他们能够更容易地克服拖延，"大大减少了我想开始处理问题所需的能量，因此我愿意处理更多额外的事情。"

...以及更少的实践

与此同时，一些人担心"随着[他们]委托更多，技能会退化"，并失去在手动解决问题过程中发生的偶然(或"附带")学习：

如果你出去自己调试一个困难的问题，你会花时间阅读对解决你的问题没有直接用处的文档和代码——但在整个过程中你正在建立系统如何工作的模型。现在这种情况少得多，因为Claude可以直接让你找到问题。

我过去会探索每个配置以了解工具可以做什么，但现在我依赖AI告诉我如何使用新工具，所以我缺乏专业知识。在与其他队友的对话中，我可以立即回忆起事情，而现在我必须问AI。

使用Claude有可能跳过我通过解决简单实例来学习如何执行任务的部分，然后稍后努力解决更复杂的实例。

一位高级工程师说，如果他们更初级，他们会更担心自己的技能：

我主要在我知道答案应该是什么或应该看起来像什么的情况下使用AI。我通过"艰难的方式"做软件工程开发了这种能力...但如果我[处于职业生涯的早期]，我认为需要付出很多刻意的努力来继续增长我自己的能力，而不是盲目接受模型输出。

编码技能退化令人担忧的一个原因是"监督悖论"——如上所述，有效使用Claude需要监督，而监督Claude需要可能因过度使用AI而退化的编码技能。一个人说：

老实说，我更担心监督问题，而不是我的技能集...让我的技能退化或无法发展主要会在我安全地将AI用于我关心的任务的能力方面产生问题，而不是我独立完成这些任务的能力。

为了对抗这一点，一些工程师刻意在不使用AI的情况下练习："每隔一段时间，即使我知道Claude可以解决一个问题，我也不会要求它。这帮助我保持敏锐。"

我们还需要那些实际编码技能吗？

也许软件工程正在向更高层次的抽象发展，它在过去就是这样做的。早期的程序员工作离机器更近——手动管理内存、用汇编语言编写，甚至切换物理开关来输入指令。随着时间的推移，出现了更高级、更易于人类阅读的语言，自动处理复杂的低级操作。也许，特别是随着"氛围编码"的兴起，我们现在正在将英语作为编程语言。我们的一位员工建议有抱负的工程师"擅长让AI[编写代码]，并专注于学习更高级别的概念和模式。"

一些员工表示，他们觉得这种转变使他们能够在更高层次上思考——"关于最终产品和最终用户"，而不仅仅是代码。一个人通过将其与以前必须学习计算机科学中的链表进行比较来描述当前的转变——高级编程语言现在自动处理的基本结构。"我很高兴我知道如何做到这一点...[但]做那些低级操作在情感上并不特别重要。我宁愿关心代码允许我做什么。"另一位工程师进行了类似的比较，但指出抽象是有代价的——随着向更高级语言的转移，大多数工程师失去了对内存处理的深入理解。

继续在某个领域发展技能可以带来对Claude更好的监督和更高效的工作("我注意到，当是我熟悉的东西时，我自己做往往更快")。但工程师们对这是否重要存在分歧。一些人保持乐观：

我不太担心技能侵蚀。AI仍然让我仔细思考问题，并帮助我学习新方法。如果有的话，能够更快地探索和测试想法加速了我在某些领域的学习。

另一个人更务实："我作为软件工程师的技能肯定在退化...但如果需要，这些技能可以恢复，我只是不再需要它们了！"一个人指出，他们只失去了不太重要的技能，如制作图表，"关键的代码类型我仍然可以写得很好。"

也许最有趣的是，一位工程师质疑前提："'生疏'的框架依赖于这样一个假设，即编码有一天会回到Claude 3.5之前的方式。我不认为会这样。"

软件工程的工艺和意义

工程师们对是否怀念实际编码存在严重分歧。一些人感到真正的失落——"对我来说这是一个时代的结束——我已经编程25年了，在这个技能集中感到有能力是我职业满足感的核心部分。"其他人担心不喜欢工作的新性质："整天提示Claude并不是很有趣或充实。自己实施某些东西、放一些音乐并进入状态要有趣和充实得多。"

一些人直接解决了权衡并接受了它："[写代码]的某些部分我确实怀念——重构代码时进入禅流状态，但总的来说，我现在的生产力高得多，我愿意放弃那个。"

一个人说与Claude迭代更有趣，因为他们可以比与人类更挑剔地给出反馈。其他人对结果更感兴趣。一位工程师说：

我预计到这个时候我会感到害怕或无聊...然而我并没有真正感受到这两种感觉。相反，我感到非常兴奋，我可以做得更多。我以为我真的喜欢写代码，但实际上我只是喜欢从写代码中得到的东西。

人们是拥抱AI辅助还是哀悼实际编码的丧失似乎取决于他们认为软件工程的哪些方面最有意义。

工作场所社交动态的变化

一个更突出的主题是，Claude已经成为曾经向同事提问的第一站。"我现在[总体上]问更多问题，但大约80-90%的问题都给Claude，"一位员工指出。这创建了一个过滤机制，Claude处理常规查询，让同事处理超出AI能力的更复杂、战略性或上下文繁重的问题("它使我对[我的团队]的依赖减少了80%，[但]最后20%至关重要，我会去找他们谈")。人们也向Claude"抛出想法"，类似于与人类合作者的互动。

大约一半的人报告团队协作模式没有改变。一位工程师说，他仍在与人们会面、分享上下文和选择方向，他认为在不久的将来仍会有很多协作，但"你不会做标准的专注工作，而是会与很多Claude交谈。"

然而，其他人描述与同事的互动减少("我与Claude一起工作的时间远远超过与任何同事一起工作的时间。")一些人欣赏减少的社交摩擦("我不觉得占用同事时间很不好意思")。其他人抵制这种变化("我实际上不太喜欢常见的回应是'你问过Claude吗？'我真的很享受与人面对面工作，高度重视这一点")或怀念旧的工作方式："我喜欢与人一起工作，现在我'需要'他们的次数减少了，这很令人难过。"几个人指出了对传统指导动态的影响，因为"Claude可以为初级员工提供很多指导"，而不是高级工程师。一位高级工程师说：

更令人难过的是，初级员工不像以前那样经常来问我问题，尽管他们肯定更有效地得到了问题的答案，学习得更快。

职业不确定性和适应

许多工程师描述他们的角色从编写代码转变为管理AI。工程师越来越将自己视为"AI代理的管理者"——一些人已经"不断至少运行几个[Claude]实例"。一个人估计他们的工作已经转变为"70%以上是代码审查者/修订者，而不是全新的代码编写者"，另一个人将"对1、5或100个Claude的工作负责"视为他们未来角色的一部分。

从长远来看，职业不确定性很普遍。工程师们将这些变化视为更广泛行业转型的预兆，许多人说"很难说"他们的职业在几年后可能会是什么样子。一些人表达了短期乐观和长期不确定性之间的冲突。"我对短期感到乐观，但从长期来看，我认为AI最终会做所有事情，让我和许多其他人变得无关紧要，"一个人说。其他人说得更直接："感觉我每天上班都是为了让自己失业。"

一些工程师更加乐观。一个人说，"我为初级开发人员感到担忧，但我也很欣赏初级开发人员可能是最渴望新技术的。我对这个职业的轨迹总体上感到非常乐观。"他们认为，虽然存在缺乏经验的工程师发布有问题代码的潜在风险，但更好的AI护栏、更多内置的教育资源以及从错误中自然学习的组合将帮助该领域随着时间的推移而适应。

我们询问人们如何设想他们未来的角色以及他们是否有任何适应策略。一些人提到计划进一步专业化("发展有意义地审查AI工作的技能需要更长时间，需要更多专业化")，一些人预计未来会专注于更多人际和战略工作("我们将花更多时间寻找共识，让AI花更多时间在实施上")。一个人说他们专门使用Claude进行职业发展，从中获得关于工作和领导技能的反馈("我可以学习东西或甚至只是在不完全学习东西的情况下有效的速度完全改变了。我几乎感觉天花板刚刚为我打破了")。

总的来说，许多人承认深度不确定性："我对我认为未来有用的具体技能信心很低。"一位团队负责人说："没有人知道会发生什么...重要的是要真正适应。"

Claude Code使用趋势

调查和访谈数据显示，Claude使用量的增加正在帮助人们更快地工作并承担新类型的工作，尽管这伴随着围绕AI委托和技能发展的紧张关系。尽管如此，自我报告的数据只讲述了部分故事。为了补充这一点，我们还分析了Anthropic团队的实际Claude使用数据。由于调查受访者报告Claude Code是他们使用的大部分，我们使用我们的 保护隐私的分析工具 分析了2025年2月和8月的200,000份内部Claude Code记录。

以更少的监督处理更困难的问题

Claude Code的使用在过去六个月中转向更困难和自主的编码任务(图3)：

员工使用Claude Code处理越来越复杂的任务。 我们估计每个记录的任务复杂度为1-5分，其中1对应"基本编辑"，5是"需要人类专家数周/数月工作的专家级任务"。任务复杂度平均从3.2增加到3.8。为了说明分数之间的差异：平均3.2分的任务包括"排除Python模块导入错误"，而平均3.8分的任务包括"实施和优化缓存系统"。

Claude Code每个记录的最大连续工具调用数增加了116%。 工具调用对应于Claude使用外部工具采取的操作，如编辑文件或运行命令。Claude现在在不需要人类干预的情况下将21.2个独立工具调用连接在一起，而六个月前为9.8个工具调用。

人 类 回合数减少了33%。 每个记录的平均人类回合数从6.2减少到4.1，这表明与六个月前相比，现在完成给定任务所需的人类输入更少。

图3. Claude Code使用在2025年8月和2025年2月之间的变化(x轴)。平均任务复杂度随时间增加(左图)，每个记录的平均最大连续工具调用数随时间增加(中图)，人类回合数随时间减少(右图)。误差条显示95%置信区间。数据表明人们越来越多地委托给Claude更多自主权。

图3. Claude Code使用在2025年8月和2025年2月之间的变化(x轴)。平均任务复杂度随时间增加(左图)，每个记录的平均最大连续工具调用数随时间增加(中图)，人类回合数随时间减少(右图)。误差条显示95%置信区间。数据表明人们越来越多地委托给Claude更多自主权。

这些使用数据证实了调查数据：工程师委托给Claude越来越复杂的工作，Claude需要更少的监督。似乎这很可能是推动观察到的生产力提升的原因。

任务分布

我们将Claude Code记录分类为一种或多种编码任务类型，研究不同任务的使用在过去六个月中如何演变：

图4. 各种编码任务(y轴)占记录总数(x轴)的百分比分布。我们比较6个月前(粉色)与现在(紫色)的分布。y轴按2025年2月的频率排序。

图4. 各种编码任务(y轴)占记录总数(x轴)的百分比分布。我们比较6个月前(粉色)与现在(紫色)的分布。y轴按2025年2月的频率排序。

从使用数据估计的总体任务频率分布与自我报告的任务频率分布大致一致。2025年2月至8月之间最显著的变化是，现在有相对更多的记录使用Claude实现新功能(14.3% → 36.9%)和进行代码设计或规划(1.0% → 9.9%)。Claude Code任务相对分布的这种转变可能表明Claude在这些更复杂的任务上变得更好，尽管它也可能反映团队如何为不同工作流程采用Claude Code的变化，而不是绝对工作量的增加(参见附录了解更多局限性)。

修复小麻烦

我们从调查中发现，工程师现在花更多时间进行小的生活质量改进；与此一致，当前8.6%的Claude Code任务被分类为"小麻烦修复"。这些包括较大的任务，如创建性能可视化工具和为可维护性重构代码，以及较小的任务，如创建终端快捷方式。这可能有助于工程师报告的生产力提升(解决以前被忽视的生活质量改进可能会随着时间的推移带来更多效率)，并可能减少日常工作中的摩擦和挫折。

跨团队的任务变化

为了研究任务目前如何跨团队变化，我们改进了分类方法，将每个8月记录分配给单个主要编码任务，并按内部团队(y轴)拆分数据。堆叠条形图显示了每个团队的编码任务细分：

图5. 每个水平条代表一个团队(y轴)，段显示该团队Claude Code使用中不同编码任务(x轴)的比例，按编码任务颜色编码(图例)。顶部条("所有团队")代表总体分布。

图5. 每个水平条代表一个团队(y轴)，段显示该团队Claude Code使用中不同编码任务(x轴)的比例，按编码任务颜色编码(图例)。顶部条("所有团队")代表总体分布。

"所有团队"条显示总体分布，最常见的任务是构建新功能、调试和代码理解。这为特定团队的比较提供了基线。

值得注意的特定团队模式：

预训练 团队(帮助训练Claude的人)经常使用Claude Code构建新功能(54.6%)，其中大部分是运行额外的实验。

对齐与安全 和 后训练 团队使用Claude Code进行最多的前端开发(7.5%和7.4%)，通常是为了创建数据可视化。

安全 团队经常使用Claude Code进行代码理解(48.9%)，特别是分析和理解代码库不同部分的安全影响。

非技术 员工经常使用Claude Code进行调试(51.5%)，例如排除网络问题或Git操作，以及进行数据科学(12.7%)；Claude似乎在弥合技术知识差距方面很有价值。

这些特定团队模式中的许多展示了我们在调查和访谈中观察到的相同能力扩展：实现团队成员否则没有时间或技能完成的新类型工作。例如，预训练团队运行了许多额外的实验，非技术员工能够修复代码中的错误。虽然数据表明团队确实将Claude用于其核心任务(例如，基础设施团队最常使用Claude Code进行基础设施和DevOps工作)，但Claude也经常增强他们的核心任务(例如，研究人员使用Claude进行前端开发以更好地可视化他们的数据)。这表明Claude正在使每个人在工作中变得更加全栈。

展望未来

Anthropic员工在过去一年中大大增加了对Claude的使用，不仅用它来加速现有工作，还用它来学习新代码库、减少辛劳、扩展到新领域以及处理以前被忽视的改进。随着Claude变得更加自主和有能力，工程师正在发现使用AI委托的新方法，同时也在弄清楚他们未来需要什么技能。这些转变带来了明显的生产力和学习收益，同时也带来了关于软件工程工作的长期轨迹的真正不确定性。AI会类似于过去的软件工程转型——从较低级到较高级的编程语言，或从个人贡献者到管理者，正如几位工程师建议的那样？还是会走得更远？

现在还处于早期阶段——Anthropic内部有许多早期采用者，格局正在迅速变化，我们的发现可能目前不适用于其他组织或环境(参见附录了解更多局限性)。这项研究反映了这种不确定性：发现是微妙的，没有单一共识或明确的指令出现。但它确实提出了关于我们如何能够深思熟虑和有效地应对这些变化的问题。

为了跟进这项初步工作，我们正在采取几个步骤。我们正在与Anthropic工程师、研究人员和领导层交谈，以解决提出的机遇和挑战。这包括研究我们如何将团队聚集在一起并相互协作，我们如何支持专业发展，和/或我们如何为AI增强工作建立最佳实践(例如由我们的 AI流利度框架 指导)。我们还将这项研究扩展到工程师之外，以了解AI转型如何影响整个组织的角色，并支持CodePath等外部组织，因为他们为AI辅助的未来调整计算机科学课程。展望未来，我们还在考虑随着AI能力的进步可能变得越来越相关的结构性方法，如组织内角色演变或技能再培训的新途径。