缺失的阶梯：当 AI 吞噬中层，工程师的晋升之路何去何从

文字记录Transcript

阿拉斯代尔·艾伦：不是五年前，而是就在12个月前，事实上几乎正好是同一天，另一个人在纽约一场完全不同的会议上站出来，在演讲中说了这样一番话。他说，12个月之内，AI基本上会写完所有代码。我想，今天在座的各位中，应该还有人仍在写代码；或者至少有些人带领的团队还在手写代码，活像野蛮人。说这番话的人是达里奥·阿莫代伊，他是RLHF（几乎所有现代AI背后的训练技术）的共同发明者，也是Anthropic的联合创始人。他说，3到6个月内，AI将会写出90%的代码；而12个月内，几乎所有代码都将由AI写出。到了六个月这个节点，阿莫代伊宣称自己的预测得到了验证，说90%这个数字完全属实——至少在Anthropic内部是这样。如今12个月过去了，几乎正好是同一天，事情显然并没有完全照他说的那样发展，不是吗？Alasdair Allan: Not 5 years ago, but 12 months ago now, almost to the day in fact, someone else stood up at an entirely different conference in New York, and during their talk they said this. They said that within 12 months AI will write essentially all of the code. I'd expect some of you in here today still write code, or at least some of you run teams that still write code by hand, like savages. The person who said this was Dario Amodei, the co-inventor of RLHF, the training technique behind virtually every modern AI, and the co-founder of Anthropic. He said that within 3 to 6 months, AI will be writing 90% of all the code, and within 12 months, virtually entirely all of it. At the six-month mark Amodei claimed vindication saying that 90% figure was absolutely true, at least within Anthropic. Twelve months on, almost to the day, and that's not exactly what happened, is it?

Redwood Research 的一项详细分析得出结论：他引用的 90% 这个数字具有误导性。如果只计算提交到代码仓库中的代码，比例更接近 50%；至少在我看来，这仍然是个相当惊人的数字。只有把一次性脚本、临时探索性代码，以及所有曾经哪怕只是短暂有用过的 AI 生成文本都算进去，这个比例才会膨胀到 90%。与此同时，Google 报告称，内部代码中由 AI 生成的略高于 25%；Microsoft 报告的比例约为 30%。GitHub Copilot 的企业级建议采纳率大约为 30%。这些数字在过去六个月里基本没有变化，而这与“几乎全部”相去甚远。A detailed analysis by Redwood Research concluded that the 90% number he quoted was misleading. If you count only code committed to repositories, it was closer to 50%, which, at least to me, is still a pretty shocking number. The figure inflates to 90% only if you include throwaway scripts, one-off explorations, and all AI-generated text that was ever even transiently useful. Meanwhile, at the same time, Google reports that there just over 25% of internal code was AI-generated. Microsoft reports about 30%. GitHub Copilot shows roughly a 30% enterprise suggestion acceptance rate. These figures haven't really changed over the last six months, and that's nowhere near essentially all.

AI 正在编写大量代码。开发者这一职业的面貌已经发生了巨大变化。我想这一点大家都能承认。Amodei 并非凭空捏造：Anthropic 自己的内部数据显示，工程师每天有 59% 的工作会使用 Claude，并且自我报告的生产力提升了 50%。如今，GitHub 上大约 4% 的提交是由 Claude Code 编写的。这些工具确实存在。在某些情境下，生产力提升也确实存在。问题在于，编写代码从来就不是我们这个职业的核心。有些人听到这话可能会感到意外。现在大多数人讨论的是 AI 编写代码。我们应该讨论、也已经开始讨论的是：当软件工程师不必编写代码时，软件工程会是什么样子。这场演讲讨论的不是这两种话题中的任何一种，而是那个在围绕代码争论的双方都忽略的问题。AI is writing a lot of code. The landscape of what being a developer is has massively changed. I think we can all acknowledge that. Amodei isn't making it up, Anthropic's own internal data shows engineers using Claude at 59% of their daily work, and self-reporting 50% productivity gains. Roughly 4% of all GitHub commits are now authored by Claude Code. The tools are real. The productivity is real in certain contexts. The problem is that writing code was never the point of our profession. That might surprise some of you. The conversation most people are having right now is about AI writing code. The conversation we should be having and are starting to have is around what software engineering looks like when software engineers don't have to write code. This talk isn't about either of those conversations. Instead, it's the question that both sides arguing about code are ignoring.

这一切背后的结构性问题是：如果 AI 接手了过去用来培养工程师的工作，下一代工程师又将从何而来？阿莫迪去年为自己的说法作出的保留，恰恰证明了这一点。他说，程序员仍然需要确定整体设计、代码如何协作，以及设计是否安全。他把编写代码和工程工作区分开来。直到大约三到六个月前，人们还一直是通过编写代码来学习工程的。 去年七月，路透社的一则标题几乎被转发到了全世界每一个工程师 Slack 群里：“研究发现，AI 会拖慢一些经验丰富的软件开发人员的速度。”作为一名前记者，我不觉得这个标题有多抓眼球，但它确实吸引了所有人的注意。其背后的 METR 研究是一项正规的随机对照试验，而不是厂商调查。研究发现，使用 AI 工具的资深开发人员完成任务所花的时间反而多了 19%。研究开始前，他们预计 AI 能让自己快 24%。完成后，他们仍然认为自己快了 20%。这种感知与现实之间的差距达到 43 个百分点。仅这一则标题就对 AI 叙事提出了质疑。而接下来发生的事，才是真正重要的。The structural question behind all of that. If AI handles the work that used to train engineers, where does the next generation of engineers come from? Amodei's own caveat to his claim last year proves the point. He said that programmers still need to specify the overall design, how code collaborates, whether the design is secure. He separated the writing from the engineering. Up until about three to six months ago, the writing was how people learned to do the engineering. Back in July last year, a Reuters headline got posted to pretty much every engineering Slack in the entire world. AI slows down some experienced software developers, study finds. As an ex-journalist, I don't consider that the most snappy of headlines, but it certainly grabbed everyone's attention. The METR study behind it, a proper randomized controlled trial, not a vendor survey, found that experienced developers using AI tooling took 19% longer to complete tasks. Before it started, they predicted the AI would make them 24% faster. After finishing, they still believed they'd been 20% faster. The gap between perception and reality was 43 percentage points. This headline alone challenges the narrative around AI. It's what happens next after this that really matters.

今年 2 月，METR 试图开展一项后续研究，但没能成功。不是因为研究方法失效，而是因为开发者如今拒绝在没有 AI 的情况下工作。他们找不到任何愿意参加研究的人。越来越多的开发者——越来越大比例的开发者——告诉 METR，他们不会参加任何要求自己一半任务都在没有 AI 助手的情况下完成的研究。这项研究变得无法衡量，不是因为这种影响已经消失，而是因为对 AI 的依赖已经深到无法控制的程度。没有对照组，就无法开展对照试验。不到一年，我们就从“AI 会让经验丰富的开发者变慢，但他们并未察觉”，走到了“开发者甚至不愿尝试在没有 AI 的情况下工作”。在人们还没弄清这项工具究竟对使用者产生了什么影响之前，它就从可有可无变成了不可或缺。关于近期 AI 编程能力的提升，有一点值得注意：这些进步是从哪里来的。In February this year, METR tried to run a follow-up study. They couldn't. Not because the methodology failed, but because developers now refuse to work without AI. They couldn't find anyone to take part in the study. An increasing percentage, an increasing share of developers told METR that they wouldn't participate in any study that required them to complete half their tasks without AI assistants. The study became unmeasurable not because the effect had disappeared, but because the dependency had become too deep to control for. You can't do a controlled trial if there's no control. In less than a year, we went from AI makes experienced developers slower, but they don't notice, to developers wouldn't even attempt to work without AI. The tool went from optional to load-bearing before anyone figured out what it was actually doing to the people using it. Something worth noting about recent improvements in AI coding is where they are coming from.

说清楚一点：在我看来，过去四五个月里，编码工具的易用性有了突破性进展。其中很大一部分得益于模型周边的工具和架构：智能体循环、来自代码检查工具和测试运行器的结构化反馈，以及反复迭代而非一次性生成的能力。得益于 AI 公司开展的定向训练，模型本身也有所进步，但幅度不大；它们周边的脚手架则改善了许多。过去四五个月里，我们看到的大部分进步——而且幅度非常大——都来自更紧密的反馈循环和架构，而非智能本身。To be clear, the last four to five months has seen what I consider a breakthrough in usability for coding tools. A significant part of that is the tooling and architectures around the model. Agentic loops, structured feedback from linters and test runners, the ability to iterate rather than generate in a single shot. The models got somewhat better thanks to targeted training by the AI companies. The scaffolding around them got a lot better. Most of the gains we've seen in the last four or five months, and they have been very large, have come from tighter feedback loops, architecture, not intelligence.

第二幕——数据Act II - The Data

过去一年，我在一家成长期公司担任临时首席技术官；这家公司是我们投资组合中的一家企业。我参与了大量招聘。凡是做过大量招聘、而且做了一年的人，肯定都懂我的痛苦。没做过招聘的人，就别做招聘了。此刻正在招聘的人都见识过这种情况：候选人的作品集看上去令人印象深刻，却经不起追问。更糟的是，有些人显然在实际面试中依赖 AI 辅助。如今，“这是我做的”意味着“这是我用提示词生成的”。当然也不总是这样。有些人确实在认真学习。信号很嘈杂。我们越来越难判断一个人是否真正理解自己做出来的东西。这让我开始真正担心眼下正在发生的事，担心职业阶梯和职业发展。我开始寻找数据。不是供应商调查，不是博客文章，更不是 LinkedIn 上那些随口发表的看法，而是真正具有统计显著性结果的研究。For the last year, I've been an interim CTO at a scale-up, one of our portfolio companies. I've been doing a lot of hiring. Anyone that's done a lot of hiring and done it for a year must know my pain. Anyone that hasn't done hiring, don't do hiring. Anyone hiring right now has seen it. Candidates with apparently impressive portfolios that fall apart under questioning. Or perhaps worse, are very obviously relying on AI augmentation during their actual interview. I built this now means I prompted this. Not always. Some people are genuinely learning. The signal is noisy. It's getting harder to tell who actually understands what they've produced. That's what made me really start worrying about what's going on here, about the ladder about career progression. I went looking for data. Not vendor surveys, not blog posts, and definitely not LinkedIn hot takes. Actual research with statistically significant results.

比你想象的更难找到，也可能和你想的一样难找。做这件事的人比你想象的要少。又是 METR。他们对一种称为“任务完成时间跨度（50%）”的指标进行基准测试：AI 智能体能够以 50% 的可靠性完成、按人类能力校准的任务时长。他们最引人注目的发现是：AI 能够完全自主、无需任何干预、一次性完成的任务时长，自 2019 年以来大约每七个月翻一番；自 2024 年以来，这一速度加快到大约每四个月翻一番。这里的 y 轴采用对数刻度，表示成功率。正是成功率曲线，让职业阶梯出现了断层。这里展示的是 Claude Sonnet 模型成功概率与人类完成任务所需时长之间的关系。S 形曲线在大约一小时后急剧下滑。对于初级开发人员第一年会做的任务，成功率接近 100%；而对于需要在多年处理这类初级任务的过程中积累判断力才能完成的任务，成功率则接近 0%。Harder to find than you might think, or possibly quite as hard to find as you might think. Fewer people doing it than you might think. METR again. They benchmark something they're calling the 50% task-completion time horizon. The length of a human calibrated task that AI agents can complete with 50% reliability. Their headline finding, the length of the tasks AI can handle entirely autonomously, without any intervention, single-shot, has been doubling roughly every seven months since 2019. Accelerating to roughly every four months since 2024. This y-axis here is a log scale. It's the success rate. It's this success rate where the career ladder breaks. Here we have Claude Sonnet model's successful probability plotted against human task duration. The S-curve drops off sharply after about an hour. The curve is at nearly 100% for tasks a junior developer would do in their first year. Nearly 0% for tasks that require judgment built on years of doing those junior tasks.

对于人类花不到四分钟就能完成的任务，比如小型 bug 修复、样板代码和简单实现，AI 现在几乎能以 100% 的成功率完成。把这些任务交给人类毫无意义，AI 能更快、更可靠地自主完成。 然而，对于人类需要花大约一小时的任务，AI 的成功率约为 50%；对于需要四小时以上的任务，成功率则低于 10%。话虽如此，这些基准测试分数严重高估了 AI 在现实世界中的能力。METR 自己的可合并性研究发现，在通过自动化测试的 AI 生成拉取请求中，大约有 50% 实际上不会被大多数代码库维护者合并。在针对成熟开源项目的 18 项真实任务中，Claude 3.7 Sonnet 虽然通过了测试用例，但在 38% 的情况下，审查的 15 个拉取请求中一个可合并的都没有。每个拉取请求至少都存在三类质量问题：缺少文档、测试覆盖不足、违反 lint 规则，或代码质量问题。维护者将 AI 生成的拉取请求修复到可合并状态，平均需要约 42 分钟，约为人类自己完成该任务所需总时间的三分之一。AI 能实现核心功能，但在工艺打磨上始终表现不佳，而这恰恰是职业阶梯中间层级本应培养的技能。For tasks that would take a human under four minutes, so small bug fixes, boilerplate, simple implementations, AI can now do these with a near 100% success rate. There's no point giving these to a human. The AI can do it faster and more reliably, autonomously. However, for tasks that will take a human around an hour, AI has roughly 50% success rate. For tasks over four hours, below 10% success rate. That said, these benchmark scores dramatically overstate real world capability. METR's own mergeability study found that roughly 50% of all AI-generated pull requests that passed the automated tests would not actually be merged by most repository maintainers. On 18 real tasks for mature open-source projects, Claude 3.7 Sonnet passed test cases, but 38% of the time produced zero mergeable PRs out of the 15 reviewed. Every single PR had at least three categories of quality issue: missing documentation, inadequate test coverage, linting violations, or code quality problems. The average time the maintainer took to fix the AI-generated PR into a mergeable state was about 42 minutes, about a third of the total time the human would have done to do the task themselves. AI can implement core functionality, but consistently fails with craft, the exact skills the middle rungs are supposed to build.

在继续之前，我想提醒你一下那项 METR 研究：使用 AI 工具的资深开发者完成任务所花的时间反而多了 19%。开始之前，他们预测 AI 会让自己快 24%。完成之后，他们仍然认为自己快了 20%。 再对比一下 Anthropic 做的一项随机对照试验：52 名以初级为主的软件工程师学习了一个新的 Python 库 Trio。Trio 自称是一款友好的 Python 库，用于异步并发和 I/O。无论是否使用 AI，他们完成这项任务所花的时间在统计学上都没有显著差异，p 值为 0.391。两组之间的差异在统计学上并不显著。使用 AI 的那组大约快了两分钟，但这完全处于随机波动范围内。AI 并没有显著提升他们学习这个库的方式和原理的速度。Anthropic 的论文对此有明确表述：在这项任务中，AI 助手带来的生产力提升未达到统计显著性。Before we move on, I'll remind you of that METR study, experienced developers using AI tools took 19% longer to complete tasks. Before starting, they predicted AI would make them 24% faster. After finishing, they still believed they were 20% faster. Contrast this to a randomized control trial done by Anthropic, where 52 mostly junior software engineers learned a new Python library, Trio, which bills itself as a friendly Python library for async concurrency and I/O. The time it took them to do this with or without AI was not statistically different. A p-value of 0.391. These were not statistically different. The AI group was about two minutes faster, but that's well within noise. The group using AI did not get any meaningful speed boost to learning how this library worked. Anthropic's paper says this explicitly. The productivity gain from AI assistants on this task failed to reach statistical significance.

尽管右侧的误差线略有重叠，但他们之后在掌握测验中的得分——该测验用于检验他们对这一过程中所学内容的理解——存在统计学上的显著差异。p 值为 0.01，远低于 0.05 的阈值。我们看到，使用 AI 辅助的组在特定库的技能、概念理解、代码阅读和调试方面都显著下降。使用 AI 助手的组在掌握测验中的得分低了 17%，为 50%，而另一组为 67%。差距最大的是调试题，而这恰恰是验证 AI 输出所必需的技能。AI 组学到的东西显著更少，完成任务的速度却并没有显著更快。他们并没有用学习来换取速度，而是白白失去了学习机会。这根本不是取舍，只有损失。那些得分较低的参与者主要表现出三种失败模式。第一种是完全委托给 AI：他们甚至没有尝试，从一开始就完全依赖 AI。Despite the slight overlap in those error bars there on the right, the score they got on the mastery quiz afterwards to test their understanding of what they had learned during this process was statistically different. A p-value of 0.01, well below the 0.05 threshold. We see a significant decrease in library-specific skills, conceptual understanding, code reading, debugging amongst the group that was AI-assisted. The group using AI assistants scored 17% lower on the mastery quiz, 50% versus 67%. The largest gap was on debugging questions, the very skill required to verify the output from the AI in the first place. The AI group learned significantly less while not even finishing the task significantly faster. They didn't trade speed for learning. They traded learning for nothing. There was no tradeoff. There was just loss. There were three major failure patterns among those low-scoring participants. Full AI delegation. They didn't even try, they wholly relied on the AI from the start.

逐渐依赖 AI。他们稍微尝试了一下，随后便放弃了，之后剩下的时间里全程依赖 AI。有意思的是，他们还会反复让 AI 调试：他们用 AI 来调试 AI 的输出，而不是尝试理解 AI 做了什么。所有归入这三类并表现出这些行为的开发者，得分都远低于 40%；相比之下，未获辅助组的得分为 67%。Anthropic 明确指出了其中的悖论：如果初级工程师的技能发展因使用 AI 而停滞，那么生产力提升可能要以削弱他们验证 AI 编写代码所需的技能为代价。他们将其称为“监督悖论”。实际上，使用 AI 需要监督，而监督又需要那些会因过度使用 AI 而退化的编码技能。Progressive AI reliance. They tried for a little bit, and then they gave up, and then they relied on the AI the whole rest of the time. Interestingly, iteratively AI debugging. They used the AI to debug the AI's output rather than trying to understand what the AI had done. All the developers that fell into these three cohorts and exhibited these behaviors scored well below 40%, compared to 67% on the unassisted group. Anthropic points out this as a paradox explicitly. Productivity benefits may come at this cost of the skills necessary to validate AI written code if junior engineers' skill development has been stunted by AI use. They call it the supervision paradox. Effectively, using AI requires supervision, and supervision requires the very coding skills that atrophy from AI overuse.

第三幕——人性的代价Act III - The Human Cost

不过，数据并不能告诉我们一切。我看到一位在业界有 25 年经验的资深工程师发了一篇 LinkedIn 帖子。对我来说，它确实捕捉到了数据没有呈现的东西。如果你现在正在带领一支抗拒 AI 工具的工程师团队，不妨想想他们的世界里究竟发生了什么。他们整个职业身份都建立在一项技能之上，而这项技能的市场价值正在迅速下降。通常那种“别担心，设计和架构一切仍然需要你们”的安慰，并不能真正说服人——毕竟，他们过往经验中有 90% 都是那种据说已经不再需要的东西。光说几句架构方面的话，是无法打动他们的。然而，这些资深程序员所具备的模式识别能力——知道系统该如何组织、复杂性藏在哪里，以及系统在规模扩大时会出现什么问题——如今已无法再通过传统方式习得。初级工程师不会再花好几年阅读遗留代码库，也不会在凌晨 3 点调试生产环境故障。Data doesn't tell us everything, though. I saw a LinkedIn post by senior engineers with 25 years' experience in industry. For me, it actually really captured what the data doesn't. For anyone leading a team of engineers right now who are resisting AI tooling, consider what's really happening in their world. Their entire professional identity is built on top of a skill that is rapidly losing market value. The standard reassurance of, "You'll still be needed to design and architect everything, don't worry," doesn't really land, when 90% of your lived experience is the thing you supposedly no longer need. A few words around architecture are going to bounce off that. However, the pattern recognition these veteran coders carry, how systems should be structured, where complexity hides, and what breaks its scale, can no longer be acquired the traditional way. Junior engineers won't spend years reading legacy codebases or debugging production incidents at 3:00 in the morning.

我们都经历过这种情况。他们只是把 AI 代理指向某个东西，让它总结一下。要真正理解软件在现实世界中的运行方式，正变得越来越难。也许如今，除了我们这群人之外，这种能力已经绝迹了；我们热爱这门手艺，而后人很可能会怀念地称之为“手艺时代”。实证数据也支持这种情绪化的叙述。Faros AI 的《生产力悖论》报告分析了约 1.2 万个团队中 1 万名开发者的遥测数据，发现 AI 采用率高的团队完成的任务多出 21%，合并的拉取请求多出 98%。PR 审查时间增加了 91%，每位开发者引入的 bug 增加了 9%，平均 PR 规模膨胀了 154%。瓶颈并没有消失，而是转移到了更靠后的代码审查环节——恰恰是资深开发者判断力发挥作用的地方。就我们观察到的情况而言，不少知名开源项目已经直接禁止提交 AI 生成的 PR。我不怪他们，但也不认为这种做法能永远持续下去。低质量 AI 垃圾提交激增，正在给当下的开源领域带来一个严重问题。We've all been there. They'll just point the AI agent at it and ask them to summarize. The deep intuition for how software actually behaves in the real world is becoming more difficult to obtain. Possibly now extinct outside a group of us who live for what will probably be fondly looked back on as the craft era. Empirical data supports this emotional narrative. Faros AI's Productivity Paradox reports, analyzing telemetry from about 10,000 developers across 1,200 teams, found that teams with high AI adoption completes 21% more tasks and merge 98% more pull requests. PR review time increases by 91%. Bugs per developer rise 9%. The average PR size inflates 154%. The bottlenecks don't disappear, it migrates upstream to code review, exactly where all of that senior judgment lives. Anecdotally, we've seen a number of high-profile open-source projects flat out ban PRs generated by AI. I don't blame them, but I also don't think it can continue forever. That surge in low-quality AI slop submissions has a significant problem for open source right now.

DX 最近发布的一份报告调查了约 20,000 名开发者，数据来自去年第三季度，也就是 AI 编程工具质量近期大幅提升之前。报告显示，采用这类工具的比例在资历较浅的工程师中更高，也就是初级工程师。高级工程师的采用率最低，但那些每天使用 AI 的高级工程师节省的时间最多。你可能马上会想：什么？你可能会问自己，这项 DX 研究和我之前提到的 METR 研究有什么区别。DX 调查了 20,000 名开发者，发现高级工程师表示自己节省的时间最多。METR 则在受控观察下对 16 名经验丰富的开发者进行了研究，发现使用 AI 让他们的工作速度慢了 19%，而他们却认为 AI 让自己快了 20%。这两件事完全可以同时为真。而它们确实可以同时为真，这本身就是个大问题。如果我们甚至无法衡量这些工具到底有没有帮助，又怎么知道使用它们的人有没有在学习？A report from DX of about 20,000 developers this time, dated from Q3 last year, so before the recent surge in quality from AI coding tools, shows the rate of adoption skews towards less tenured engineers, so the junior folks. Senior engineers, despite having the lowest adoption rates, who do use AI daily, save the most time. You're probably immediately going, what? Asking yourself the difference between this study by DX and the METR study I talked about earlier. DX surveyed 20,000 developers and found senior engineers report saving the most time. METR put 16 experienced developers under controlled observation and found they made them 19% slower, while they believed it made them 20% faster. Both of these things can be true simultaneously. The fact they can, it is in itself a real problem. If we can't even measure whether the tools are helping, how do we know whether the people using them are learning?

METR 的研究对象是经验丰富的开发者，他们对自己所使用的代码库非常熟悉。这些开发者的技能已经针对这些代码库进行了高度优化。DX 研究的数据涵盖了范围广泛得多的开发者整个工作周的工作，包括从零开始构建项目、处理陌生代码库、编写样板代码、撰写文档，等等。AI 确实能在其中一些工作上节省时间。很多都是简短、定义明确的任务，而 METR 自己关于时间跨度的研究表明，AI 很擅长处理这类任务。他们那份引人瞩目的随机对照试验（RCT）报告，研究的却是 AI 最不擅长助力的孤立情形：专家在熟悉的领域中处理复杂代码库。如果我们把视线从这个特殊情形上移开，就会看到一种规律：AI 能帮助已经熟练的人，却会让新手在缺乏理解的情况下产出结果。最能从刻意练习中受益的人，反而最有可能跳过练习。这大概不该让我们任何人感到意外。The METR study was of experienced developers working in codebases which they were deeply familiar with. These developers' skill sets were already highly optimized for those codebases. The data for the DX study covers work by a much wider sample of developers across their entire work week. Greenfield, unfamiliar codebases, boilerplate, documentation, the lot. AI does save time on some of this work. A lot of this is short, well-defined tasks that METR's own time horizon research shows AI handles well. While their headline-grabbing RCT report dealt with the isolated case where the AI helps least, experts on familiar ground with complex codebases. If we take a step away from that corner case, we see a pattern. AI helps the already skilled, while creating output without understanding for novices. The people who'd benefit most from deliberate practice are the most likely to skip it. That probably should surprise none of us.

Anthropic 自己的工程师正在实时讲述这一现象。一位高级工程师说，他们主要会在自己知道答案应该是什么，或者至少大致知道答案应该是什么样的情况下使用 AI。他还指出，他们之所以具备这种能力，是因为过去用传统而艰苦的方式从事软件工程。如果他们职业生涯还处于早期阶段，要培养这些能力，就必须刻意努力，避免盲目接受模型的输出。Anthropic 的另一位高级工程师形容 AI 的输出“聪明得很危险”：就像一位非常有才华的初级工程师可能提出的方案，只有经验丰富的人才能看出其中的问题。Anthropic 的工程师表示，他们有 80% 到 90% 的问题会问 Claude，而不是问同事。一位高级工程师说，令人难过的是，现在初级员工不再像以前那样常来向他们提问了。不过，他们提出的问题确实能得到更有效、更礼貌的回答。Anthropic's own engineers narrate this in real time. One senior engineer said they used AI primarily in cases where I know what the answer should be, or at least vaguely know what it should look like. Noting they developed the ability to do that by doing software engineering the old-fashioned hard way. If they'd be earlier in their career, developing those abilities would have required deliberate effort to avoid blindly accepting the model's output. Another senior engineer at Anthropic described AI output as really smart in a dangerous way. The kind of thing a really talented junior engineer might propose, recognizable as problematic only by someone with deep experience. Anthropic's engineers report asking 80% to 90% of questions to Claude instead of their colleagues. One senior engineer said it's sad that junior people don't come to them with questions as often anymore. Although they definitely get their questions answered more effectively and more politely.

对于那些长期从事这一领域工作的人来说，或许真正令人意外的是，资深工程师喜欢与人共事，在同事离开后也会想念他们。人与人互动带来的附带学习，以及在导师陪伴下经历调试过程、从中理解系统如何运作的收获，在 AI 不经这番历程就直接给出答案时，便被跳过了。Possibly the really surprising thing for those that have worked in this space for a long while is that the senior engineers liked working with people and missed them when they went away. The incidental learning that came from human interaction, understanding how systems work by struggling through debugging sessions with a mentor gets bypassed when AI gets you the answer without that journey.

第四幕——案例研究Act IV - The Case Study

我已经给你看了很多图表，但我认为，最近发生的一起问题——亚马逊事故——为我们分析究竟哪里出了问题提供了一个相当典型的案例。有人知道亚马逊现在出了什么事吗？对，这事挺有意思。2025 年 12 月中旬，AWS 工程师允许亚马逊的 Kiro AI 编程工具修改 AWS Cost Explorer。这个 AI 智能体获得了相当于人类工程师的操作员级权限，却认为最好的做法不是有针对性地修改，而是删除并重建整个环境。AWS 花了 13 个小时才恢复其中一个中国区域的 Cost Explorer。亚马逊称这是用户错误，具体来说是访问控制配置不当。但后来有四位消息人士告诉《金融时报》，这个决定是 Kiro 自主做出的。我们希望人类工程师都知道，删除并重建整个线上生产环境，绝不是应对配置变更的合理做法。这种认知来自亲眼见过事情如何出错，来自亲历生产事故，也来自内化了一条不成文的规则：不要把面向客户的生产环境中的状态一笔抹掉。I've shown you a lot of graphs, but I think a recent problem presents us with a rather elegant case study on what's going wrong, the Amazon incidents. Who's heard of what's going on with Amazon right now? Yes, it's interesting. In mid-December 2025, AWS engineers allowed Amazon's Kiro AI coding tool to make changes to AWS Cost Explorer. The AI agent, given operator-level permissions equivalent to a human engineer, decided the best approach was to delete and recreate the entire environment rather than make targeted changes. AWS spent 13 hours recovering Cost Explorer in one of two China regions. Amazon called it user error, specifically, misconfigured access controls. Four sources later told the Financial Times that Kiro autonomously made that decision. A human engineer, one would hope, would know that delete and recreate the entire operational production environment is not a sane response to a configuration change. That knowledge comes from having seen things go wrong, from having lived through production incidents, from having absorbed the implicit rule that you don't blow away state in a production customer-facing environment.

AI 拥有相应权限，却缺乏实战经验。随后，有趣的是，亚马逊零售网站接连发生了一系列服务中断。3月5日，一次持续约六小时的故障期间，超过22,000人报告遇到了问题。《金融时报》和 CNBC 均报道称，内部简报文件将 GenAI 辅助修改列为导致故障的因素。此类事故呈现出影响范围广的趋势，而 GenAI 的这种新颖用法，其最佳实践和防护措施尚未完全确立。五天后的3月10日，高级副总裁戴夫·特雷德韦尔将原本通常为自愿参加的“本周门店技术”（This Week in Stores Tech，TWiST）会议改为强制参加。据称，他在邮件中写道：“各位，你们可能也知道，最近网站及相关基础设施的可用性不太理想。”随后，多家新闻媒体报道称，亚马逊新增了审批要求：初级和中级工程师现在必须就 AI 辅助的生产环境变更取得高级工程师的签字批准。AI had the permissions. It lacked the battle scars. Then, interestingly, came a series of outages on the Amazon retail site. Over 22,000 people reported issues during a roughly six-hour disruption on the 5th of March. Both the FT and the CNBC reported the internal briefing documents identified GenAI-assisted changes as the contributing factor. With a trend of incidents characterized by a high blast radius, a novel GenAI usage for which best practices and safeguards are not yet fully established. Five days later, on the 10th of March, SVP, Dave Treadwell, made normally optional, This Week in Stores Tech, TWiST meeting mandatory. His email apparently began, "Folks, as you likely know, the availability of the site and related infrastructure has not been good recently." Multiple news outlets then reported that Amazon had introduced new approval requirements. Junior and mid-level engineers were now required to seek senior sign-off on AI-assisted production changes.

和那项 METR 研究一样，这件事几乎传遍了全球所有工程师 Slack 频道，你们当中有些人可能也听说过。不过，有意思的是，过去几天里，亚马逊强烈反驳了这种说法。他们在一份公开声明中表示，《金融时报》的报道存在不准确之处。亚马逊的说法是，近期零售业务事故中只有一起在某种程度上涉及 AI 工具。那起事故并非由 AI 编写的代码导致，而是一名工程师听信了 AI 工具根据过时的内部维基推断出的错误建议。其他故障则是彼此独立、互不相关的运营问题，完全没有涉及 AI。亚马逊并未出台针对使用 AI 工具的工程师的新审批要求。亚马逊将这起涉及 AI 的事故归咎于人为失误，而非 AI 失效。亚马逊表示，这些故障大多与 AI 毫无关系。也许他们说得对。我很愿意相信他们。Like that METR study, the story went around pretty much every engineering Slack channel in the world, some of you have come across it. However, interestingly, in the last few days, Amazon has really pushed back against this narrative. In a public statement, they said the FT reporting contained inaccuracies. Their version was that only one of the recent retail incidents involved AI tooling in any way. That incident was not caused by AI-written code. Instead, it was an engineer following inaccurate advice that an AI tool inferred from an outdated internal wiki. The other outages were separate, unrelated operational issues with no AI involvement whatsoever. No new approval requirements for engineers using AI tools had been introduced. Amazon characterized the AI-involved incident as human error, not AI failure. Amazon says that most of these outages have nothing to do with AI. Maybe they're right. I'm quite willing to believe them.

仔细看看亚马逊确实确认了什么。一款 AI 工具读取了一份过时的内部维基文档，并根据陈旧的文档推断出建议。一名工程师照着建议做了，网站随即宕机。这不是一个关于 AI 写出糟糕代码的故事，而是一个关于上下文的故事。AI 无法区分当前的维基页面和过时的页面，也无法判断它综合出的建议是否仍适用于如今的系统。它把上下文窗口中的所有内容都一视同仁，因为这类工具就是这么运作的。照着建议做的工程师，要么缺乏质疑建议的经验，要么相信了工具表现出的信心——我们都知道这些模型能有多么自信，远比它们对自身不确定性的表达强烈得多。Look carefully at what Amazon did confirm. An AI tool read an outdated internal wiki. It inferred advice from stale documentation. An engineer followed that advice. The site went down. That's not a story about AI writing bad code, it's a story about context. The AI couldn't distinguish current wiki page from an obsolete one. It couldn't assess whether the advice it was synthesizing still applied to the systems as it exists today. It treated everything in its context window with equal weight because that's what these tools do. The engineer who followed the advice either didn't have the experience to question it or trusted the tool's confidence, and we all know how confident those models can be, far more than their own uncertainty.

正如我在这场演讲开头所说，问题从来不在于编写代码，而始终在于代码周围的一切：设计决策、系统背景，以及对事物为何如此的累积性理解。过时的维基页面，意味着组织记忆的失灵。工程师不加质疑地照着它的建议行事，则意味着判断力的失灵。这两种失灵都直接对应着缺失的阶梯：依赖 AI，而不是依靠自己的判断。上个月的一篇 arXiv 论文追踪了团队如何管理 AI 上下文。一个项目最终积累了 26,000 行经过编码整理的上下文，其指令数量甚至超过了实际代码。与此同时，GitClear 对 2.11 亿行代码的分析显示，AI 工具的采用使代码量增加了 10%，但质量指标却全面下滑：重构减少了 60%，复制粘贴增加了 48%，代码变动率飙升了 44%。模型编写代码时，对既有代码的理解却越来越少。As I said at the start of this talk, the problem was never writing code, it was always about what surrounds the code. The design decisions. The system context. The accumulated understanding of why things are the way they are. An outdated wiki page is a failure of institutional memory. The engineer who follows its advice without questioning it is a failure of judgment. Both of these failures map directly to missing rungs. A reliance on AI rather than your own judgment. An arXiv paper from last month tracked how teams manage AI context. One project evolved into 26,000 lines of codified context, more instructions than actual code. Meanwhile, an analysis by GitClear of 211 million lines of code showed AI tools adoption increasing code volume by 10%, but collapsing quality metrics, refactoring dropped by 60%. Copy and paste rose by 48%. Code churn jumped by 44%. The models writing code with less understanding of what already existed.

这就是提示工程（你如何提问）与我们现在所说的上下文工程之间的区别：模型开始工作时能看到什么。真正做好这件事的团队，会把上下文当作基础设施来对待：文件写得像入职指南，记忆分层并逐步披露，架构决策不仅有记录，还附有背后的理由。上下文架构的 26,000 行代码并非额外负担，而是过去存在于人们脑海中的组织知识，如今被明确记录下来，让 AI 也能利用。新工程师也能从中学习。因为大多数工程工作都不是从零开始，而是在棕地环境中进行，或者像有些人开始称呼的那样，是在黑地环境中进行：遗留系统负载很高，大家都同意要走弃用路线，却真的抽不出时间去执行。我太熟悉这种情况了。业务等不及，于是功能还在不断地往上叠加。在黑地系统里，规范要么从未写过，要么虽然写过，却被几十年来那些没有记录的决策彻底架空了。This is the distinction between prompt engineering, how you ask, and what we now call context engineering. What the model sees as it starts working. The teams that get this right, treat context like infrastructure, files that read like onboarding documents, memory hierarchies with progressive disclosures, architectural decisions recorded with reasoning behind them. The 26,000 lines of context architecture is not overhead, it's the institutional knowledge that used to live in people's heads, made explicit so that AI can use it too. New engineers can learn from it. Because most engineering is not greenfield, it's brownfield or what some people have started calling blackfield. Legacy systems under high load, on a deprecation path everyone agrees on but literally no one has time to execute. Been there. Features still being bolted on because the business can't wait. In blackfield systems the spec was never written or was written and made totally irrelevant by decades of undocumented decisions.

业务规则被编码在那些早已无人理解的条件判断中。AI 智能体可以阅读代码、测试和文档，但它们无法读取生产环境。它们无法审视多年来的请求模式，理解哪些代码路径承载着关键负载，而这些信息并不会从代码本身显露出来。它们也无法区分一个已无人触及的边缘案例，和一个只影响你 0.1% 用户的案例——而一旦它消失，这些用户无一例外都会立刻投诉。Business rules are encoded in conditions that outlived everyone who understood them. AI agents can read the code, tests and documentation but what they can't do is read production. They can't look at years of request patterns and understand which code paths are load bearing in ways the code themselves does not reveal. They can't distinguish a dead edge case from one that runs for 0.1% of your users, every single one of whom will immediately complain as soon as it disappears.

亚马逊过时的 Wiki 只是这个问题最显眼的表现。每个代码库都充斥着未被记录下来的隐性知识；更糟的是，有些知识曾经被记录过，却再也没有更新。AI 能读取已有的内容，却无法知道缺失了什么，或哪些内容已经过时。只有真正长期与这个系统打交道的人才能做到这一点。对于非绿地系统，诚实的流程不是编写规范、生成代码、运行测试，而是观察生产环境、提取行为契约、将其编码为系统测试、以此作为规范，然后再引入智能体。相关工具早已存在：特征化测试、契约测试、流量影子测试、金丝雀分析。这些绝不是什么新理念，而是软件工程师在 AI 出现之前就摸索出来的做法。AI 对话需要继承这些做法，而不是假装只要改进提示词就能解决问题。无论你相信《金融时报》的说法还是亚马逊的说法，其结构性要点都一样。Amazon's outdated wiki is just the most visible form of this problem. Every codebase is full of implicit knowledge that hasn't been written down or perhaps worse yet was written down once and never updated. The AI can read what's there, it can't know what's missing or stale. Only someone who's lived with the system can do that. The honest sequence for non-greenfield systems isn't write spec, generate code, run tests. It's, observe production, extract behavioral contracts, encode the system tests, use that for the spec, and then bring in the agent. The tools for this already exist, characterization tests, contract testing, traffic shadowing, canary analysis. These aren't new ideas by any means. They're what software engineers worked out before AI entered the picture. AI conversation needs to inherit them rather than pretend the problem is being solved by better prompting. Whether you believe the FT's version or Amazon's version, the structural point is the same.

AWS Kiro 事件——删除并重建——正是 AI 智能体拥有权限却缺乏判断力时会发生的事。这种判断力来自多年的生产环境经验。已确认的零售业事件——过时的维基文档——正是上下文未经整理时会发生的事。整理上下文，恰恰是那些缺失的职业阶梯本应培养的机构知识。争论本身就揭示了组织如何抗拒将这些问题视为结构性问题。亚马逊称这是用户错误，也是例行运维审查。在工程领域，照着过时文档中自信却错误的 AI 建议行事，并非一次性的失误。这是一种模式，只要 AI 工具被部署到存在机构记忆缺口的系统中，就会不断重演；而这几乎就是所有大型企业系统的现状。问题不在于亚马逊的服务中断是否由 AI 导致。问题在于，当 AI 工具被部署到这样的环境中时会发生什么：它们所需的上下文、生产环境知识、机构记忆，以及对事物为何如此的理解，都存在于人类的头脑中，而这些头脑所积累的知识，来自数十年来亲身从事如今由 AI 承担的工作。当那些本该建立这些知识的人从未亲自做过这份工作时，这些上下文又从何而来？AWS Kiro incident, delete and recreate, is what happens when AI agents have permissions without judgment. Judgment that comes from years of production experience. Confirmed retail incident, the outdated wiki, is what happens when context isn't curated. Context curation is exactly the kind of institutional knowledge that the missing rungs were supposed to build. The dispute itself reveals how organizations resist framing these as structural problems. Amazon called it user error and routine operational review. In engineering, following confidently wrong AI advice from stale documentation is not a one-off mistake. It's a pattern that will reoccur everywhere AI tools are deployed into systems with institutional memory gaps, which pretty much is every large corporate system ever. The question isn't whether Amazon's outages were caused by AI. The question is what happens when AI tools are deployed into environments where the context they need, the production knowledge, the institutional memory, the understanding of why things are the way they are, lives in the human heads that were built by decades of doing the work AI now handles. Where does that context come from when the people who would have built it never did the work in the first place?

第五幕——小心站台间隙Act V - Mind the Gap

我不打算给你一个半截的答案。作为一个行业，我们正面临一个根本性的结构问题：阶梯缺了几级。当然，有意思的是，我们以前也经历过这种情况。20世纪80年代，家用电脑革命造就了一代通过动手折腾学会本领的工程师——我这一代人。我们伴随着 BBC Micro、Commodore 64、ZX Spectrum、Trash-80 长大；这些机器启动后会进入 BASIC 提示符，运气特别好的话则会进入 CP/M。孩子们编写游戏、工具，做各种实验，大多是些垃圾作品，但我们学到了东西。到了21世纪初，电脑已经变成了封闭的家用电器。台式机启动后进入的是 Windows，而不是命令提示符。游戏先是装在磁盘上，后来通过互联网获取。它们肯定不再附带源代码了。大多数家庭里，Xbox 取代了 BBC Micro。孩子们在家里的卧室里编写游戏或应用程序，并且能做到和专业软件公司开发的一样出色的能力。I'm not going to try and give you a part answer. As an industry, we are facing a fundamental structural problem. The ladder is missing rungs. Of course, the interesting thing is we've been here before. In the 1980s, the home computer revolution created a generation of engineers who learned by tinkering, my generation. We were brought up in the BBC Micro, the Commodore 64, the ZX Spectrum, the Trash-80, machines that booted to a basic prompt or CPM if you were really lucky. Kids wrote games, tools, experiments, mostly rubbish, but we learned. By the early 2000s, computers had become sealed appliances. Desktops booted into Windows, not to a prompt. Games came on disks, then over the internet. They definitely did not come with source code anymore. The Xbox replaced the BBC Micro in most homes. The ability for kids to write at home in their bedroom a game or an application that was just as good as a professional software house could.

这种情况在 20 世纪 80 年代很常见。当时，卖给我这样的孩子的许多磁带游戏，都是其他孩子在自己的卧室里编写的。如今，这种情况已经不复存在。到了 21 世纪 00 年代中期，计算机科学系开始注意到，入学的新生在上大学之前从未写过代码。他们一辈子都在使用电脑，却从未编程过。他们不了解电脑是如何工作的。这在学术界和业界都引发了一场大规模恐慌。人们推出了一大批旨在解决这个问题的计划，其中较为突出的一个就是 Raspberry Pi。Raspberry Pi 是对此作出的明确回应，是有意重新创造一种人人都能轻松参与的动手探索体验。重点并不是“我们需要一台便宜的电脑”，那只是解决方案。真正的问题是：我们怎样才能让孩子们拥有一台完全属于自己的机器，而且就算弄坏了也无所谓？一台启动后就进入命令提示符、配有 GPIO 引脚，让他们能够触碰现实世界的机器。That's something that happened a lot in the 1980s. A lot of the games sold in cassette tapes to kids like me were written by other kids in their bedrooms. That was now gone. Then by the mid-2000s, computer science departments started noticing that incoming students had never written code before coming up to university. They'd used computers their whole lives, but had never programmed one. They didn't understand how they worked. This started a mass panic in both academia and industry. There were a whole bunch of initiatives designed to deal with the problem. One of the more prominent ones was Raspberry Pi. Raspberry Pi was an explicit response, a deliberate recreation of accessible tinkering. Not, we need a cheap computer. That was the solution. The problem was, how do we get kids access to a machine they can own completely, that it didn't matter if it broke? One that boots to a prompt that had GPIO pins to allow them to touch the physical world.

它成功了。数百万台设备，一代人重新爱上了摆弄各种东西。这并不是为解决这个问题而推出的唯一产品，但它是其中比较引人注目的一款。物理计算——让 LED 灯闪烁起来——成了新的“自己编写电子游戏”。尤其是因为在 2010 年代中期的一段短暂时期，孩子们，或者至少是年轻人、大学生，可以在卧室或宿舍里制作，至少是原型设计物联网设备，而且做得几乎和我们这些专业人士一样好。在着手打造解决方案之前，人们花了多年时间思考这个问题；而它之所以奏效，只是因为问题诊断正确。It worked. Millions of units, a generation reintroduced to tinkering. It wasn't the only thing that was pushed to solve this problem, but it was one of the more prominent things. Physical computing, making an LED flash on and off again, was the new write-your-own video game. Not least because for a brief time in the mid-2010s, kids, or at least young adults, university students, could build or at least prototype IoT devices in their bedroom or dorm room that was just as good as us professionals could, just about. It took years of thinking about the problem before building the solution, and it only worked because the diagnosis was right.

当前的 AI 冲击正是同一种变化，只不过发生在职业层面，而不是发生在孩子们还没上大学的时候。那些曾经帮助工程团队成长的杂活——修 bug、写样板代码、胶水代码和文档——如今在初级工程师接触到它们之前，就已经被处理掉了。Anthropic 的内部数据量化了工程工作的全新面貌。工程师表示，他们日常工作中有 59% 会用到 Claude，高于一年前的 28%；他们自述生产力提升了 50%，不过请记住我之前提到的那些研究。超过半数的人表示，他们能完全交出去的工作量只有约 20%。一位工程师估计，自己的工作有 70% 已从编写代码转变为审查和修改代码，而非编写代码。去年 2 月至 8 月间，Claude Code 的自主操作次数从 9.8 次增至 21.2 次，翻了一倍多；与此同时，每份交互记录中的人工轮次从 6.2 次降至 4.1 次。剩下的工作越来越需要监督、架构设计和判断力。The current AI disruption is the exact same dynamic, but at the professional level, rather than with the kids before they even get to university. The scut work that built engineering teams, bugs, boilerplate, glue code, documentation, is now handled before juniors ever see it. Anthropic's internal data quantifies the new shape of engineering work. Engineers report using Claude in 59% of their daily work, up from 28% a year earlier, achieving a self-reported 50% productivity increase, although do bear in mind the studies I talked about. More than half say they can only fully delegate about 20% of their workload. One engineer estimated that their role had shifted to 70% from being code to being a code reviewer reviser, not a code writer. Claude Code autonomous actions doubled from 9.8 to 21.2 between February and August last year, while human turns per transcript fell from 6.2 to 4.1. The work that remains is increasingly supervisorial, architectural, and judgment heavy.

现在有证据表明，这条人才输送链不仅没能培养判断力，还没能招到本可以培养判断力的人。本月初，Anthropic 发布了自己的劳动力市场分析报告《AI 对劳动力市场的影响：一种新指标及早期证据》。论文提出了一种名为“观察到的暴露度”的新指标，将 LLM 的理论能力与 Claude 的实际使用数据结合起来，并对自动化用途和工作相关用途赋予更高权重。这份报告读起来很有意思。计算机程序员是暴露度最高的职业，达到 74.5%，这意味着在现实的专业工作场景中，四分之三的程序员日常任务如今都已大量使用自动化工具。另一端则是 30% 的劳动者完全不受影响，包括厨师、机械师、救生员和调酒师。我父母告诉我别去当救生员。至少眼下，现实世界仍未受到波及。不过我不确定，如果能回到 90 年代末、互联网泡沫破裂前的首轮热潮中发表评论，面对互联网和 iPhone 对出租车司机的影响——而它们确实改变了一切，各位——我当时会不会预测到 Uber 的出现。Now there's evidence that the pipeline isn't just failing to build judgment, it's failing to hire the people who would have built it. At the start of this month, Anthropic published its own labor market analysis, Labor market impacts of AI: A new measure and early evidence. The paper introduces a new measure called observed exposure that combines theoretical LLM capability with actual Claude usage data, weighing automated and work-related uses more heavily. The report makes interesting reading. Computer programmers are the most exposed occupation at 74.5%, meaning three-quarters of our programmers' daily tasks are now seeing significant automated usage in real world professional settings. At the other end, 30% of workers have zero coverage, cooks, mechanics, lifeguards, and bartenders. My parents told me not to become a lifeguard. The physical world remains untouched, at least for now. Although I'm not sure given the opportunity to comment back in the late '90s in the heat of the first dot-com boom before the bust, I would have predicted Uber. Given the effect the internet and the iPhone, which really did change everything, folks, would have on taxi drivers.

AI 距离实现其理论能力还很远。LLM 理论上能够做到的事情与它们实际上被用于做的事情之间，仍存在巨大差距。计算机和数学类职业的理论暴露度为 94%，但观察到的覆盖率只有 33%。在所有职业类别中，代表实际使用情况的红色区域都远小于代表理论能力的蓝色区域。这是演讲一开始就指出的一个不大的差距，而且经过了精确测量。美国劳工统计局（BLS）预测，暴露度较高的职业到 2034 年的增长幅度会较低。AI 任务覆盖率每提高 10 个百分点，政府的就业增长预测就会下降 0.6 个百分点。劳动力市场分析已经将就业岗位被取代的影响计入预期。不过，对于暴露度较高的劳动者，目前还没有出现系统性的失业率上升。自 ChatGPT 发布以来，AI 暴露职业的失业率一直没有偏离基准水平。这一点很重要。AI is far from reaching the theoretical capabilities. The gap between what LLMs could theoretically do and what they actually are being used for remains large. Computer and math occupations have 94% theoretical exposure, but only 33% observed coverage. The red area, actual usage, is much smaller than the blue area, theoretical capability, across every occupational category. This is a modest gap from the start of the talk, measured precisely. Occupations with higher exposure are projected by the Bureau of Labor Statistics in the U.S., the BLS, to grow less through 2034. For every 10 percentage points increase in AI task coverage, the government's growth projection drops by 0.6 percentage points. The labor market analysis is already pricing in job displacement. However, there is no systemic increase in unemployment for highly exposed workers, yet. The unemployment rate for AI-exposed occupations has not diverged from baseline since ChatGPT's release. This is important.

天并没有塌下来。到目前为止，那些预言灾难的人都错了。在受 AI 影响的职业中，年轻劳动者的招聘速度放缓了。从 2024 年开始，22 至 25 岁人群在受 AI 影响职业中的新就业数据，明显呈现出相较于未受影响职业向下分化的趋势。平均估计显示，与 ChatGPT 出现前的水平相比，受影响职业的求职成功率下降了 14%——这里说的是找到工作的比例，而不是招聘广告数量。25 岁以上劳动者的就业并未减少。这一现象只发生在刚进入行业的初级开发者身上。结果在统计上仅勉强显著，但与另一份基于 ADP 薪资数据的报告中的独立发现相呼应。那项调查发现，受影响职业中 22 至 25 岁劳动者的就业人数下降了 6% 至 16%；同样，这主要是招聘放缓所致，而不是离职人数增加。人们并没有被裁掉，只是一开始就没有被录用。这就是“缺失梯级”论点在劳动力市场上的实时体现。The sky has not fallen. The doom predictors are wrong so far. The hiring of young workers has slowed in exposed occupations. New job stats for 22 to 25-year-olds in AI-exposed occupations visibly diverge downwards from unexposed occupations starting in 2024. The average estimate is a 14% drop in job finding rate, not advertisements, finding, in exposed occupations compared to pre-ChatGPT levels. There is no decrease in work for workers over 25. This is just for junior developers just joining the industry. The result is barely statistically significant, but it echoes independent findings from another report based on ADP payroll data. That survey found a 6% to 16% fall in employment in exposed occupations from workers 22 to 25, again, primarily being driven by slowed hiring rather than increased separations. People weren't being sacked. They just weren't being hired in the first place. This is the missing rungs thesis measured in the labor market in real time.

职业阶梯上的各级岗位不仅正在失去培养人才的功能，岗位本身也在减少。公司并没有解雇有经验的员工，而是不再招聘新一代员工。被切断的是入口，而不是出口。再一次，是 Anthropic 发布了这项研究。打造 Claude 的这家公司正在记录证据，表明在最容易受到影响的职业中，Claude 的应用与年轻员工招聘减少相关。同一家公司发表了三项研究：AI 阻碍技能形成，AI 将工作转变为监督，如今 AI 又减缓了初级岗位的招聘。无论你如何看待其中的情绪化措辞，他们在学术上的诚实都令人赞叹。The rungs aren't just losing their educational function, the jobs themselves are contracting. Companies aren't firing experienced workers, they're not hiring the next generation. The pipeline is being cut off at the intake, not the output. Once again, it's Anthropic publishing this. The company that builds Claude is documenting the evidence that Claude's adoption correlates with reduced hiring in young workers in the most exposed professions. Three studies from the same company. AI stunts skill formation, AI transforms work into supervision, and now AI slows hiring at the entry level. Whatever you think of the emotives, their intellectual honesty is remarkable.

所有资料，包括 Anthropic 自己的内部研究，都对此达成一致。这个组织正竞相采用 AI 编码工具，却也在同时削弱培养能够监督这些工具的人才梯队。能够为 AI 构建良好上下文的人，是那些经过多年专业实践、早已把这些知识内化于脑海中的人。培养这些人才的渠道正在瓦解。如果你来这里是希望我能给出这个问题的答案，那我很抱歉让你失望，因为我没有答案。没有什么简单的解决办法，因为眼下我手头没有一块能填补 AI 这个缺口的树莓派拼图。有些事情我们可以在找到答案之前就开始做：设计有条理的学习路径，让人有计划地轮岗承担基础工作，即使 AI 做得更快也一样，就像医学住院医师培训一样。你要做那些繁琐的杂活，是因为它能让你学到东西，而不是因为它有效率。Every source, including Anthropic's own internal research, agrees on this. The organization is racing to adopt AI coding tools that are simultaneously degrading the pipeline that produces people capable of supervising those tools. The people who can build good context for AI are people that have the context in their heads through years of craft. The pipeline that produced these people is breaking. If you come here hoping for me to hear an answer to this, I'm really sorry to disappoint you because I don't have one. There are no easy answers because right now I don't have a Raspberry Pi piece shaped to fit the AI shaped hole. There are some things we can do now before we have the answers. Structured learning paths, deliberate rotation through fundamental work, even if the AI could do it faster, like medical residencies. You do the scut work because it teaches you, not because it's efficient.

要求先理解，再让 AI 提供帮助。这成本很高，大多数公司不会这么做。那些愿意这么做的公司，10 年后才会有资深开发人员留下，因为到那时我们其他人都已经退休了。医学博士之所以接受特定的培训，是有原因的。衡量理解程度，而不是开发速度。你能解释代码的作用吗？不借助 AI，你能调试吗？如果失败了会发生什么？结对编程是一种评估。观察他们如何思考，而不是他们产出了什么。把上下文当作基础设施。那些真正用好 AI 的团队，会把文档化的上下文当作教学材料，而不是配置文件。最好的这类文档读起来就像是写给资深工程师的入职指南：他们已经会写代码，只是不熟悉你的代码库。Require understanding before letting the AI help. It's expensive and most companies won't do it. The ones who do will be the ones who have senior developers left in 10 years because the rest of us will have retired by then. There's a reason why medical doctors are trained how they're trained. Measure understanding, not velocity. Can you explain what code does? Can you debug without AI? What happens if this fails? Pair programming is evaluation. Watch how they think, not what they produce. Treat context as infrastructure. The teams that get AI right are treating codified context as teaching documents, not config files. The best ones read like onboarding docs for a senior engineer who already knows how to code but doesn't know your codebase.

我们已经进入了一个文档优先编程的时代。我觉得颇具讽刺意味的是，开发者最讨厌的那部分，如今竟成了全部工作。作为曾经做文档的人，我真的很高兴。除此之外，我们还需要抱持诚实的预期。要告诉初级开发者，AI 是工具，不是老师。用它来跳过理解，就等于透支自己的未来。十年后真正有价值的人，是那些理解系统的人，而不是那些会写提示词的人。 回到最初的 METR 研究，并按照当前的翻倍速度做大胆、夸张的推算，到 2027 年，AI 智能体将能处理相当于一个完整工作日的任务；到 2029 年，则能处理相当于一个工作月的任务。不过，这个预测可得打个不小的折扣——至少我个人不相信我们最终真能做到。连摩尔定律最终都会失效。到了那时，中间的台阶不只是消失了，整架梯子都在朝着另一面墙重新搭建。We have entered an era of documentation first programming. I find it somewhat ironic that the part that most developers hate has become the whole job. As an ex-docs person, I'm really happy. Beyond that, we need honest expectations. Tell the juniors that AI is a tool, not a teacher. Using it to skip understanding is borrowing against your future. The people who are valuable in 10 years are the ones who understand the systems, not ones who can prompt. Going back to the original METR study and making wild, waving extrapolations at the current doubling rate, AI agents will handle tasks equivalent to a full work day by 2027, and a work month by 2029. Take that with more than a pinch of salt, mind you, because personally I don't believe we'll ever get there. Even Moore's Law broke eventually. At that point, the middle rungs aren't just missing, the ladder is being rebuilt against a different wall.

如果有 10 位面包师每月烤出 1,000 条面包，而新烤箱让其中 5 位可以继续完成同样的工作，你要么裁员，要么烤更多面包。Anthropic 的数据提供了一种可能的出路：Claude 协助完成的工作中，有 27% 原本不会在没有 AI 的情况下进行。这些是新的实验、锦上添花的工具和探索性工作——不是烤得更快，而是烤出以前不值得烤的东西。编写代码是一个巨大的瓶颈，过去也是如此。软件最初是由公司为自身用途定制开发的。随着需求超过现有供给，它变成了大规模生产的商品。整个 SaaS 市场都建立在供给短缺之上：开发人员短缺，也缺少为每个问题打造完美定制解决方案的时间。结果，我们只能将就于电子表格和面向大多数情况设计的 Web 应用程序。If you have 10 bakers producing 1,000 loaves a month and new ovens let 5 of them go on and do the same job, you either cut staff or bake more bread. Anthropic's data offers one possible escape, 27% of Claude-assisted work comes from tasks that would not have been done without AI. New experiments, nice to have tooling, exploratory work, not baking faster, but baking things that weren't previously worth baking. Writing code is a huge bottleneck, was a huge bottleneck. Software started out custom developed in companies for their own use. It became a mass-produced commodity when demand grew past available supply. The entire SaaS market sits on the shoulders of shortage, a shortage of developers, of time to build the perfect custom solution for every problem. Instead, we're stuck with spreadsheets and web applications designed for most cases.

我给你举个个人例子。过去几个月里，我一直在开发一种名为 Vera 的编程语言，它专为 AI 生成的代码而设计，是一种供机器编写的语言。要不是有 AI 工具，这种项目根本不值得我尝试。一个人要构建编译器、类型系统、测试套件和一致性框架——过去这得靠一群人才能完成。从历史上看，新技术带来的是更高的生产力，而不是更少的工作岗位。眼下，劳动力市场数据表明，这座城市正在减少对面包师的需求。亚马逊 10 月裁掉了 14,000 名企业职能员工，1 月又裁了 16,000 人。Anthropic 自身对 AI 暴露程度的观测数据表明，美国劳工统计局预计，大多数受 AI 影响的职业增长将放缓。问题不在于是否采用 AI。这个问题已经尘埃落定。我们一定会采用 AI。如果你认为自己或公司不会采用，那么 12 个月后，你就不会再有工作，也不会再有公司。I'll give you a personal example. Over the last few months I've been building a programming language, Vera, designed specifically for AI-generated code, a language designed for machines to write. It's exactly the kind of project I wouldn't even be worth attempting without AI tooling. A single person building a compiler, a type system, a test suite, a conformance framework, that used to take a village. Historically, new technology means more productivity, not less jobs. Right now, the labor market data says the city is choosing fewer bakers. Amazon laid off 14,000 corporate workers in October, 16,000 more in January. Anthropic's own observed exposure data shows the BLS projecting weaker growth for most AI-exposed occupations. The question is not whether to adopt AI. That's a closed question. We're going to adopt AI. If you think you or your company won't, then you won't have a job or a company in 12 months from now.

真正的问题是，我们该如何培养工程师，让他们能够监督自己从未学过如何做的事情？如果我们不解决这个问题，十年后就不会再有人拥有公司，因为缺失的不只是梯级，就连当初培养出那些搭建梯子的人才的机制也消失了。The real question is, how do we build engineers, ones that can supervise what they have never learned to do in the first place? If we don't solve that problem, nobody will have a company in 10 years' time, because the ladder isn't just missing rungs, it's missing the mechanism that created the people who built the ladder in the first place.

问题与解答Questions and Answers

参与者 1：我注意到，你的演示很大程度上依赖 AI 生成的内容。根据你自己估算的结果，你节省了多少时间，效率提高了多少？我还想从效果方面问一下，你觉得它在帮助你理解内容方面有多大作用？Participant 1: One thing that I noticed is that your presentation relied heavily on AI-generated content. According to your own self-reported estimate, how much time did you save and how much did it make you faster? I also want to ask in terms of effectiveness, how much do you think it helped understand your content?

阿拉斯代尔·艾伦：说实话，对我来说，最耗时间的事一直是制作有趣的幻灯片，把整套幻灯片填充起来。Midjourney 简直是我的救星。它至少能让我制作演示文稿的时间缩短 20%。也就是说，做起来会快这么多。这张幻灯片里有很多数字。没错，这些数字都是我用 AI 找到的。这不是真的。很多数字是出现在我的信息流里，我读了之后，再把它们交给 AI，试着让它们综合起来。你们得相信，我今天提到的每一个数字都核查过。你们得相信，我查阅了每一条参考资料，并确认它确实存在。这是因为我在这个行业里有二十五、三十来年的惨痛经验。是的，AI 也许让演讲准备得更快了。它让寻找资料、综合资料，以及了解它们如何关联起来变得更容易。但演讲稿不是 AI 写的，还是我自己写的。我觉得这证明了整场演讲的核心论点。Alasdair Allan: Actually, for me, always the most time-consuming thing has been creating amusing slides to fill the slide deck with. Midjourney is a savior for me. It cuts my time creating a presentation by at least 20%. That's how much faster it's going to be. There was a lot of numbers in this slide. Yes, I found all of these using AI. That's not true. A lot of them surfaced in my feed, and I read them, and I fed them into the AI to try and get a synthesis of them. You've got to believe, I checked every single number that I said today. You've got to believe that I went to every single reference and made sure it actually existed. That's because 25, 30 some years of bitter experience in the industry. Yes, AI may have been creating the talk faster. It made finding sources and synthesizing those sources and see how those came together easier. Didn't write the talk. I still did that. I think it proves the thesis of the entire talk.

 

查看更多带文字记录的演示文稿See more presentations with transcripts