AI 写了代码，工程师还要做什么？Laurie Voss 谈产品判断与人才培养

简要描述Brief Description

Laurie Voss 认为，廉价代码会让工程瓶颈转向理解用户、定义质量以及培养产品工程师。Laurie Voss argues that cheap code shifts the engineering bottleneck toward understanding users, defining quality, and training product engineers.

目录Table of Contents

• 编写代码的成本越来越低；代码审查成了瓶颈
  Code becomes cheap; review becomes the bottleneck
• 自动化审查者仍会忽略的内容
  What automated reviewers still miss
• 瓶颈正转移到问题定义上。
  Bottlenecks move toward defining the problem
• 产品工程师与初级职业发展阶梯
  The product engineer and the junior career ladder
• 构思、过渡与切实可行的后续步骤
  Craft, transition, and practical next steps

编写代码的成本越来越低，审查则成了瓶颈Code becomes cheap; review becomes the bottleneck

我叫 Laurie，是 Rise AI 的开发者关系负责人。曾经我与人共同创立了 NPM Inc.。所以你们当中有些人可能还记得我在 JavaScript 时代的经历。不过如今，我关注的是 AI 智能体，以及在这种情况下，它们会给我们的工作带来什么影响。三年多以前，Swix 写了一篇名为《AI 工程师的崛起》的文章。他的观点是，在交付 AI 产品时，你需要的是工程师，而不是研究人员。我认为这个观点引起了所有人的共鸣，尤其是来参加这次会议的人。于是，他创造了“AI 工程师”这个职位名称，此后各家公司也开始招聘 AI 工程师。今天我来这里要做的事情之一，就是说服你们：他实际上还没有走得足够远。正在发生的并不只是一场 AI 工程师革命。My name is Laurie. I'm head of developer relations at Rise AI. in a former life I co-founded NPM Inc. So some of may you some of you may remember me from JavaScript days. but these days I think about AI agents and in this case what they are doing to our jobs. so a little bit over 3 years ago Swix wrote an essay called the rise of the AI engineer and his argument was that when it comes to shipping AI products you want engineers not researchers. I think that is a message that resonated with everybody especially who the people who come to this conference. and so he created the job title of the AI engineer and companies since then have been hiring for it. and part of what I'm here to do today to do is to convince you that he did not in fact go far enough. there's not just an AI engineer revolution happening.

一场波及各类工程师的革命正在发生。所有工程类岗位都在被一种新型岗位取代，而并不是所有人听到这个消息都会高兴。引发这一切的根本变化是，智能体让编写代码几乎变得免费了。没错，你还是要为令牌付费，但与过去编写代码所耗费的时间成本相比，这几乎等于免费。编写代码之后的所有工作，并没有同时变得免费。于是，瓶颈从“编写代码很慢，其他事情的速度大致相同”，变成了“编写代码快得惊人，现在我们又被新的事情卡住了”。眼下，也就是这个月，首先卡住我们的事情是代码审查。但我的观点是，这种情况不会止步于此。There is a revolution happening to every kind of engineer. all engineering jobs are being replaced by a new type of job and not everybody is going to be happy to get that news. the underlying change that kicked all of this off is that agents have made writing code basically free. Like you pay for the tokens but relative to the cost of the time it used to take you it is basically free. everything that comes after writing the code did not become free at the same time. So the bottleneck moved from writing code is really slow and all of this other stuff happens at roughly the same speed to writing code is super fast and now we get stuck behind new things. So the first the thing it's stuck behind right this second like this month is code review. but my thesis is that it's not going to stop there.

我们要弄清楚如何自动化代码审查。我们要让代码审查以智能体的速度推进，然后我们会遇到一个又一个瓶颈，直到某个时候停下来。我们会碰上一个无法突破的瓶颈，而那就是留给人类去做的事情——无论那个智能体无法突破的瓶颈是什么。We are going to figure out how to automate code review. We are going to make code review move at the speed of agents, and then we are going to run into another bottleneck, and another bottleneck, and another bottleneck, and at some point we're going to stop. We're going to hit one that we can't get past. and that is what is going to be left for the humans to do. Whatever the bottleneck is that we can't get agents past.

所以，我打算打个赌：我能想到一件智能体确实做不到的事。一旦我们遇到这个瓶颈，就得想办法培养新一代工程师，让他们能够胜任这项工作，因为我们现在并没有按这个方向培养他们。先快速提醒一下，也算是道个歉：我有18分钟，因为瑞士方面给演讲规定的时长就是这么长。So, I'm making a bet that I can think of a thing that agents really are not going to be able to do. and then once we've come to that bottleneck, we're going to have to figure out how do we train the next generation of engineers to be able to do that job because we're not training them to do that job right now. So, a quick warning / apology. I have 18 minutes because that is how long Swiss gives for talks.

而且我有一大堆数据。为此我做了很多研究，但没时间全都讲给你听，也没时间逐一引用来源、把那些东西都做全。所以我就直接给你甩一堆数字，幻灯片上会附上一大堆引用，然后只能请你姑且相信我了，兄弟。and I have a really big pile of data. I did a ton of research for this. and I don't have time to give it all to you. I don't have time to like quote my sources and do all that stuff. So, I'm just going to throw numbers at you with a bunch of citations on the slides, and I'm just going to have to sort of ask you to trust me, bro.

所以，so,

自动化审阅者仍会遗漏什么What automated reviewers still miss

启用自主编程代理的开发者，编写的代码多了741%，也就是多了八倍。但他们的交付速度只快了30%。当然，快30%也不是小事，快30%已经很了不起了。我们交付的代码确实比以前多得多，但考虑到我们写的代码多了八倍，实际交付量只增加了三分之一，这就有点糟糕了，对吧？这意味着我们卡在了某个环节。而我们卡住的地方就是代码审查。我们之所以卡住，是因为人类没办法单纯靠加快速度来完成审查。20年前，思科做过一项规模庞大的研究，探讨代码审查的速度和准确度。结果发现，人类理解代码中发生了什么的能力，在每小时审查约450行代码之后会急剧下降。developers who switch on autonomous coding agents write 741% more code, eight times as much. and but they ship only 30% faster. Like, 30% faster is not nothing. 30% faster is amazing. We are shipping a lot more code than we used to, but given that we're writing eight times more code, only a third more actual shipping is kind of bad, right? It means that we're stuck somewhere. and where we're stuck is code review. and the reason that we're stuck is because humans can't just review faster. there is an enormous study done by Cisco 20 years ago about how fast you can do code review, and how accurately you can do code review. and it turns out that humans' ability to like parse what's going on in code falls off radically after about 450 lines of code per hour.

所以，如果你让智能体生成了一个包含 10,000 行代码的差异，你可能得花上一周时间才能合理地审查完这些代码。So, if you've produced a 10,000 line diff with your agent, it would take you like a week to reasonably review that code.

答案是，其实根本没人这么做，对吧？因为如今我们都在随随便便地抛出一万份 diff。所以，我之前在一次 AIE 上专门做过一场关于这一现象的演讲，题目叫《代码审查之死》。如果你想了解《代码审查之死》的全部内容，可以去看那场演讲。不过，我们眼下面临的问题，和我想通过这场演讲从整体上解决的问题并不是一回事：生成看似可信的代码，成本已经大幅下降；但判断这段代码是否值得信任，成本却依然和以前一模一样。所以，眼下最显而易见的审查方式，就是像我刚才说的，让机器来做审查。而这已经在发生了。And the answer is that nobody's actually doing that, right? Cuz we're all throwing 10,000 diffs around willy-nilly these days. so, I did a whole talk about this phenomenon at a previous AIE, and that talk is called the death of the code review. And if you want all of the information about the death of the code review, you can watch that talk. but the problem facing us right now, which is not the same as the problem I'm trying to solve with this overall with this talk, is that the cost of producing plausible code has collapsed while the cost of knowing whether to trust that code has stayed exactly the same. so, the obvious review move right now is to make the machines do the review, like I said. And that is already happening.

截至上个月，GitHub 上五分之一以上的代码审查由 GitHub 的 Copilot 完成。GitHub's Copilot does more than one in five of the code reviews on GitHub as of last month.

如果你愿意，可以选择让 Copilot 担任某项内容上线生产环境前的最终审查者。你甚至可以赋予它批准权限，这简直不可思议。我不知道谁会启用这个选项，但你愿意的话确实可以这么做。OpenAI 表示，在 OpenAI，人工可以审查他们的拉取请求，但并非必须这么做。不过问题在于，机器审查者目前还不太靠谱。我找到的数据是这样的：让四个 AI 审查者接受全面考验后，它们都发现了一堆 bug，但彼此发现的 bug 没有一个是相同的。you can, if you want to, opt in to let Copilot be the final reviewer before something goes to production. You can make it have the approval power, if you want to, which is crazy. I don't know who's turning on that option, but you can do it if you want to. OpenAI says that at OpenAI, humans may review their pull requests, but aren't required to. but the problem is that the machine reviewers aren't very good yet. the data says that there's the data that I found put four AI reviewers through their paces, and they all found a bunch of bugs, but none of the same bugs.

它们对任何一个具体的 bug 都没有达成一致。它们都确实发现了代码中的问题，而且发现的问题各不相同。所以值得运行，但如果你真的认真对待这件事，就绝不会只运行其中一个。They did not agree on any individual bug. they all found actual issues in the code. They all found different issues in the code. so, they're worth running, but if you are serious about this, you're never going to run just one of them.

因为它们目前还不够可靠。还有些人走得更远。他们会说：“我以后不再审查代码了。我就假设我的智能体能一次就把这事完美做好。”Dexter Horty就在这里，我不知道他是不是在观众席里，可能不在。他花了6个月告诉大家不要读代码，6个月后，他走上台说：“不，我错了。”because they are not reliable enough yet. And there are some people who went all the way. They were like, "I'm just not going to review the code anymore. I'm just going to assume my agent has one shot at this perfectly." Dexter Horty, who is here, I don't know if he's in the audience, probably not. he spent 6 months telling people not to read the code, and then after that 6 months, he got on stage and said, "Nope, I was wrong.

你不能真的完全跳过代码审查。我们试过了。那简直是一场灾难。我们不得不彻底替换整个系统。”这不是一个选项。You can't actually skip code review entirely. We tried that. It was a disaster. We had to rip replace whole systems." that's not an option.

这些智能体还不够好，没法一次性把代码写对。亚马逊接连发生了几次服务中断，他们事后复盘后认定，原因是编码智能体生成了一堆劣质代码，而他们想都没想就把这些代码放到了线上。The agents are not good enough. They're not one shotting the code. Amazon had a run of outages that they did postmortems on and decided that it was because their coding agent had produced a bunch of slop and they just released it into the wild without thinking.

所以现在他们不再允许他们这么做了。在亚马逊，代码审查必须由资深工程师签字批准。Anthropic 发布了一份事后分析，讲述了那些绕过了所有审查者——无论是人工还是机器——的漏洞。问题在于，我们迄今构建的、用于检查代码是否足够好的自动化工具，本身还不够好。Claude Fable 5 在标准编码基准测试中有 80% 的测试通过。然后，Cognition——Devin 的开发者——构建了一个基准测试，提出了一个不同的问题：它通过测试了吗？他们问的其实是：作为审查者、作为这个代码仓库的维护者，你会合并这个 PR 吗？and so now they don't let them do that anymore. senior engineers must sign off on code reviews at Amazon. and Anthropic published a postmortem on bugs that had got past every reviewer that they had, both human and machine. So, the problem is that the automations that we've built so far to check whether our code is good enough are not themselves good enough. Claude Fable 5 passes the tests on 80% of a standard coding benchmark. and co- So, Cognition, the makers of Devin, they built a benchmark that asks a different question, which is not does it pass the tests? The question is would you as the reviewer, as the maintainer of this repo, merge this PR?

而如果你改为提出那个问题，通过率就会从87%降到54%。因为在决定是否合并它时，还需要考虑大量额外信息。And if you ask that question instead, the pass rate falls from 87% to 54%. because there's a lot of extra information that goes into deciding whether you would merge it.

有代码风格，有副作用，有外部系统，还有一些没有编码进代码库的历史，而是存在维护者的脑海里。所以，维护者带来的东西——维护者确实带来的东西——是我们还没有赋予智能体的东西。他们缺少一些信息，也缺少一种技能，那就是对何为“好”的判断。There's code style, there's side effects, there's external systems, there's history that is not encoded into the code base. It is encoded into the brain of the maintainer. So, what the maintainer is adding, what maintainer is demonstrably adding, is something that we haven't given the agents yet. There is information they don't have, there is a skill they don't have. and it is the sense of what good means.

这就是我们的本质。这正是智能体目前还不具备的，而这是一个关键的洞见，我稍后会再谈到。That is what we are That is what the agents don't have yet. and that is a critical insight that I'm going to come back to.

瓶颈正转向问题定义。Bottlenecks move toward defining the problem

伊利亚胡·高德拉特，如果我没念错的话，原本是一位物理学家，后来成了管理学大师。1984年，他写了一部关于经营工厂的小说。你觉得这听起来像是一本有趣的小说吗？这本书叫《目标》。而他的核心理念就是约束理论。Eliyahu Goldratt, if I'm pronouncing that correctly, was a physicist who became a management guru and in 1984 he wrote a novel about running a factory. Does that sound like an interesting novel to you? it is called The Goal. and his big idea was the theory of constraints.

每个系统都有一个瓶颈，除非你加速的环节正是瓶颈，否则加快速度也没用。这就是我们的代码审查问题：我们加快了写代码的速度，却没有加快审查速度。他的第二个观点才是今天的重点：当你解决了瓶颈，它并不会消失，只会转移到别处，成为新的瓶颈。所以，尽管我刚才说了现在的代码审查员有多糟糕，我们姑且假设我们已经解决了这个问题，把自动化代码审查提升到了更高的标准，从而挪开了这个瓶颈。接下来它会遇到什么瓶颈？如果我们解决了审查问题，下一个瓶颈很可能就是运维。我要怎么部署这个东西？又要怎么扩展它？every system has one bottleneck and speeding things up does not work unless the thing that you were speeding up is the bottleneck. that is our problem with code review. we've sped up the code and we have not sped up the review. his second idea is the one that matters today, which is that when you fix the bottleneck, it doesn't go away, it just moves and finds another bottleneck to pile up against. so let's assume, despite everything that I've said about how bad the code reviewers are right now, that we figured that out, that we get automated code review to a higher standard and we move that bottleneck. What is the next bottleneck that it is going to run into? if we figure out review, the next bottleneck is probably going to be operations. How do I deploy this thing? How do I scale it up?

然后你可能就会遇到安全问题。怎样才能让这东西在大规模应用时依然安全？怎样确保它保护隐私？怎样确保它不会严重偏离轨道？不过，我要做一个决定——这也是我在这场演讲中迈出的一大步：我打算假设这些问题也都已经解决了，因为人类已经很好地解决了这些问题。and then you're probably going to run into security. How do I make this thing safe at scale? how do I make sure that this thing is private? How do I make sure that it's not radically going off the rails? but I'm going to make and this is the big leap that I'm making in this talk. I'm going to assume we figured those things out as well because those things are very heavily solved by humans.

关于它们的数据量非常庞大。如果我们能弄清楚如何用越来越先进的智能体来开展运维、实现扩展、保障安全，那我们还剩下什么事可做？在这种情况下，人类的角色是什么？这既是个大问题，也是个长期问题。我不是在告诉你未来 12 个月会发生什么。There's an enormous amount of data out there about them. If we can figure out how to do operations, how to do scaling, how to do security using progressively more advanced agents, what is it that we are left to do? Like, what is the role of a human in that situation? it's also it's a big question and it's also a long-term question. I'm not telling you what is going to happen in the next 12 months.

未来12个月里，我认为我们很可能会在代码审查方面取得一些实质性进展。我不认为再过12个月，我们就能解决运维、扩展和安全问题。我觉得要解决这些问题，得花5到10年。尽管有些人会说“2027年实现AGI”。不，我们会在这些事情上慢慢迭代。但要让我的论点成立，你还需要作出另一个假设：我们需要的软件量实际上是无限的。In the next 12 months, I think we'll probably make some real progress on code reviews. I do not think 12 months from now we'll have sorted out operations and scaling and security. I think that is going to take somewhere between 5 and 10 years to get done. despite people who are like, "AGI 2027." No, we're going to slowly iterate on this stuff. But the other assumption that you need to make for my for the my thesis to be correct is that the amount of software that we need is effectively infinite.

而且我觉得，这个观点要论证起来容易得多。想想你在现实中遇到过的所有已上线网站，它们很可能都相当糟糕。它们之所以糟糕，并不是因为我们不知道怎样才能做出非常出色的网站，而是因为人手不够，没法把所有网站都做好。And I feel that one is a much easier case to make. Think of every website you've ever run into in the world in production, and it's probably pretty bad. and the reason it's bad is not because we don't know how to make really great websites. The problem is that there's not enough people to make all of the websites good.

每次你在理发店、政府部门，或者比如说银行的网站上遇到糟糕透顶的体验，都不是因为没人知道怎么把网站做好。而是因为，第一，把网站做好非常贵；第二，负责做这件事的人正忙着做别的事情。你知道的，他们很可能在推出 AI 智能体。所以，假设我们基本上可以免费制作想要的任意数量的软件，而且人们对制作软件的热情几乎是无限的。这是个非常美妙的局面。我们既有无限的需求，也突然有了无限的供给。那么，瓶颈最终会出在哪里呢？Every time you run into a terrible website at your hairdresser or the government or like, you know, your bank, like it's not because there's not somebody who knows how to make that website good. It's because A, it's very expensive to make it good, and B, the people who are doing that are busy doing other things. you know, probably shipping AI agents. so assume that we can make as much software as we want basically for free, and that the appetite for making software is essentially infinite. That is a wonderful situation in which to be in. We've got infinite demand and also suddenly infinite supply. where does the bottleneck end up?

我们认为智能体不会吃掉哪些工作？为了弄清楚这一点，我把软件开发工作尽可能拆分成多个部分，并按照智能体会多快接手这些工作进行排序。What do we think the agents are not going to eat? to try and figure that out, I split up the job of software development into as many pieces as I could think of, and I sorted them by how soon the agents get to them.

编写代码已经被压缩到几乎不值一提，代码审查和维护也很快会如此。将产品发布到生产环境并进行扩展，是接下来可能被淘汰的环节，不过目前这方面的数据还不多。然后还有我认为大概比较稳妥的事情：决定要构建什么、定义什么才算做好，最后让它变得令人愉悦。剩下的就是弄清楚人们真正想要什么。每一款软件，都是对某个人想要完成的某件事的一种形式化表达。所以，如果客户告诉你：“我需要跟踪我的订单”，那么就有一万款软件可以帮你跟踪订单。writing code is already collapsed, reviewing and maintaining code is going soon. shipping to production and scaling are next on the chopping block, although there isn't a lot of data there yet. and then there's the stuff that I think is probably safe, which is deciding what to build, defining what good means, and finally making it delightful. What's left is finding out what people actually want. Every piece of software is a formalization of something that a human wanted to get done. So, if a customer tells you, "I need to keep track of my orders," there are 10,000 pieces of software that keep track of your orders.

他们就是这么做的。不过，如果你经营的是一家面包店，那么这些做法里只有一种（如果你运气好的话）才适用。如果你经营的是一家汽车零配件店，情况就会不一样。That's what they do. but only one of those, if you're lucky, is good if the thing that you're doing is you're running a bakery. If you're running like an auto parts store, that's going to be different.

如果你经营的是一家大型制造企业，情况就会完全不同。这个要求还不够。整个工作的关键在于弄清楚，你说想跟踪订单时，具体指的是什么。这对你的业务意味着什么？If you are running you know, a giant manufacturing concern, it's going to be completely different. The That requirement is not sufficient. The whole job is figuring out what exactly do you mean when you say that you want to keep track of your orders. What does that mean for your business?

它需要做什么？这是如何运作的？而这些知识并不在训练数据中，也不在权重里，而是在经营那家企业的人的头脑中。What does it have to do? How does that work? and that knowledge isn't in the training data. It isn't in the weights. It is in the mind of the person who runs that business.

而要把这些信息弄出来，唯一的办法就是冲着他们挥动你的肉体部件，让他们也冲着你挥动他们的肉体部件。也就是说，你得跟他们交谈。这是获取信息的唯一办法。而这项工作有一个非常重要的特性：它无法迁移。想想看，日历应用要做到什么才算好，日程安排应用要做到什么才算好——它们解决的几乎是同一个问题，对吧？And the only way to get it out is by flapping your meat parts at them and having them flap their meat parts back. Like, you have to talk to them. That is the only way to get the information out. And that work has a very important property, which is that it doesn't transfer. if you think about what good means for like a calendar app and what good means for a scheduling app, those are solving almost the same problem, right?

日历应用和日程安排应用是两种完全不同的软件。它们的需求截然不同，对什么才算好也有完全不同的定义，尽管这两种使用场景非常相近，而且我们的使用场景多得数不胜数。你肯定用过那种配置选项多到数不清、却还是满足不了你需求的软件。说的就是你，Jira。你遇到的问题就是：软件试图包办一切，结果还是做不好。所以，瓶颈转移到了描述问题，以及定义怎样才算解决了问题上。我对这场演讲和未来十年的最大押注，就是这个瓶颈会一直在这里。A calendar app and a scheduling app, but they're completely different pieces of software. They have totally different requirements and a totally different definition of good, even though those two use cases are so close together, and we have a zillion use cases. Anytime that you've used software that has a zillion configuration options and it still doesn't do what you need. I'm looking at you, Jira. like that is the problem you're running into of software that is trying to do everything and still failing at it. so the bottleneck moves to describing the problem and defining what it means to have solved the problem and my big bet for this talk and for the next 10 years is that is where it stays.

曾负责 IBM System/360 项目并撰写《人月神话》的弗雷德·布鲁克斯，在 1986 年写过这件事。Fred Brooks, who ran IBM System 360 project and wrote The Mythical Man-Month, he wrote about this in 1986.

他把软件开发的难度分成两类。偶然复杂性是工具或语言带来的难度，比如打字、语法；然后还有本质复杂性，也就是问题本身的难度。他预言，没有任何单一工具能让我们的生产力提高十倍，因为本质部分才是难点。布鲁克斯的预言看起来相当准确：我们让编写代码的速度提高了八倍，但交付速度并没有快多少，因为难点就在于本质部分。两年前，OpenAI 的肖恩·格罗夫也表达过同样的观点。不，抱歉，是一年前。现在是哪一年？他说，代码是对规格说明的一种有损投影，而无论编写规格说明的是产品经理、立法者、工程师还是营销人员，他们都会成为程序员。He split the difficulty of software into two kinds. Accidental complexity is the difficulty of the tools or the languages, the typing, the syntax, and then there's the essential complexity, which is the prob- difficulty of the problem itself. and he predicted that no single tool would make us 10 times more productive because the essential part is the hard part. and Brooks's prediction is looking pretty solid because we made code eight times faster and we still didn't get very much faster at shipping because the hard part is the essential part. Shawn Grove from OpenAI made the same point 2 years ago. no, sorry, a year ago. what year is it? he said that code is a lossy projection of the specification and whoever writes the spec, if it's a PM or a lawmaker or an engineer or a marketer, they become the programmer.

所以，现在价值所在就是把什么算作“好”写下来。我开始有点来不及了，因为时间没安排好。如果你是模型开发者，任何能够低成本验证的东西，都可以拿来训练，直到模型胜过它。所以，Cognition 围绕他们的基准测试，试着写下合并某项内容的标准：这段代码能合并吗？他们想的是，我们看看能不能设计出一个基准测试，真正定义清楚什么叫“可合并”。再看看能不能把所有其他相关信息都纳入这个基准测试，然后就可以据此训练模型。and so writing down what good means is where the value is now. I'm beginning to run out of time because I haven't timed this well. anything that you can verify cheaply, you can train against until you beat it if you are model maker. so Cognition tried to write down because of their benchmark about what it counts to merge something, does it, you know, is this code mergeable? They were like, let's see if we can figure out a benchmark that defines what mergeable really means. Let's see if we can get all of that other information into the benchmark, and then we can train a model on it.

Cursor 的审查机器人 BugBot 会把你们团队给它的每一个差评都转化成一条规则，他们现在大概已经有 44,000 条规则了。所以，一旦维护者把脑中的知识提取出来，写下来供模型训练，瓶颈就会再次转移。Cursor's reviewer BugBot turns every thumbs down that you that your team gives it into a rule, and they have like 44,000 rules now. so the moment the maintainer takes knowledge out of their brain and puts it somewhere written down that a model can train on it, the bottleneck moves again.

这就是为什么我认为安全部分可以删掉，运维部分也可以删掉。我认为我们最终可以把这些内容写下来，尽管我们还没这么做。That is why I think security can go. That is why I think operations can go. I think we can write those things down eventually, even though we haven't done it yet.

产品工程师与初级职业发展阶梯The product engineer and the junior career ladder

谷歌大脑和 Coursera 的联合创始人 Andrew Ng 表示，他团队中有人提议让产品经理的数量达到工程师的两倍。他说这是他人生中第一次听到这样的提议，但此后他的答案一直不是多招产品经理，而是让这些工作融合在一起。用他的话说，当工程师了解用户、能够决定要开发什么，并直接动手开发时，他们就能以惊人的速度执行；我认为我们正开始找到答案。20 世纪 60 年代有一种叫作系统分析师的工作，他们的工作不是编写代码。Andrew Ng, the co-founder of Google Brain and Coursera, says that one of his team proposed having twice as many product managers as engineers, and he said that was a first in his life, but his answer is since then hasn't been hire more PMs. It's to blur the jobs together. In his words, when an engineer understands users and can make decisions on what to build and build it directly, they can execute incredibly quickly, and that is where I think we are beginning to hit on the answer. in the 1960s, there was a job called the systems analyst. Their job was not to write code.

他们的工作是与业务部门沟通，弄清楚问题所在。Their job was to talk to the business and find out what the problem was.

后来，那个分析师变成了我们今天所说的产品经理，于是原本一个半职业变成了两个职业。我认为现在发生的事情是，它们正在重新合并为一个。我们正在回到 60 年代。所以，那不是 AI 工程师。then that analyst turned into something that we call a product manager today, and we've had two professions where there used to be one and a half. I think what is happening is they are collapsing back into one. We are going back to the '60s. So that is not an AI engineer.

他们不只是在构建 AI，也不只是在借助 AI 构建。他们正在构建一切，构建所有软件。而我决定把这份工作称为“产品工程师”。They're not just building AI. They're not just building with AI. They are building everything. They are building all software. and I've decided to call this job the product engineer.

这类人会弄清楚人们需要什么，定义什么才算好，并让智能体负责敲代码、交付成果。Gergo Orosz（我可能把他的名字念得一塌糊涂）撰写《The Pragmatic Engineer》通讯；他在2019年将有产品思维的工程师描述为工程师的一项不错特质，而我现在要说的是，它已经从“不错”变成了必不可少。This is somebody who finds out what people need, defines what good looks like, and ships it with agents doing the typing Gergo Orosz whose name I have probably butchered he writes the pragmatic engineer newsletter he described the product-minded engineer back in 2019 as a nice trait for an engineer to have and what I'm saying now is it has gone from nice to essential.

这项技能已经从过去只有高级工程师才需要具备的技能，变成了每个想成为工程师的人都必须掌握的技能。市场已经开始为此买单。前线部署工程师的职位看起来很像产品工程师；2025年前九个月，这类职位的招聘信息增长了800%。如今他们无处不在，所有人都在想方设法招聘他们。It has gone from the from a skill that senior engineers used to have to a skill that every engineer has to have if they're going to be an engineer. And you can see the market already paying for this. Forward deployed engineers who look very much like product engineers job postings for them rose 800% in 9 months of 2025. They are everywhere everybody is trying to hire them.

在座有谁正在招聘前沿部署工程师？请举手。好吧，嗯，我原本以为会有更多人举手呢。算了。那么，顺便说一下，前沿部署工程师的平均薪酬是24万美元，也就是说，薪酬水平和高级工程师差不多，因为他们本来就是高级工程师。这是一类非常有用的工程师。Who in this room is trying to hire a forward deployed engineer show of hands. Okay, well more I was expecting more hands oh well. So The average comp for forward deployed forward deployed engineer by the way is $240,000 which is to say that it pays like a senior engineer because it is a senior engineer. It's a very useful kind of engineer.

但目前还没人能就该如何称呼它达成一致。我所描述的这个职位有大约上千种不同的头衔，而我随意决定把它叫作“产品工程师”。But nobody agrees on what to call it yet. There are like a thousand different job titles for this thing that I am describing and have decided arbitrarily to call the product engineer.

此时你们中的一些人可能会想，这不是编程，而你们想得没错。这确实不是编程。编程是由代理完成的。不过，这显然仍然属于软件开发，而到了 2026 年，我们必须开始接受这样一个事实：软件开发者和程序员已经不再是同一回事了。And probably at this point some of you are thinking that isn't programming and you are correct. It is not programming. The programming is being done by an agent. It is however recognizably still software development and we are going to have to wrap our minds around the idea that being a software developer and being a programmer have become divorced in 2026.

而且，当我说“嗯，我觉得难点在于决定什么才算好”之类的话时，我意识到自己掉进了一个很多 AI 圈里的人都会掉进去的陷阱：所有事情、所有领域的方方面面都能被 AI 自动化，唯独我擅长的那件事不行，因为那太难了。前几天我听一位风投这么说，我当时就想：“老兄，别这样。说不定哪天你的工作就会被自动化了。所以这话你得打个折听。”And when I say stuff like well I think the hard part is deciding what good is I realize that I'm falling into a trap that lots of people in AI land fall into, which is all of the parts everything about everything can be automated by AI except the thing that I'm good at because that's too hard. I heard a VC say that the other day and I was like, "Buddy, like, no. No, someone is going to automate your job any day now. so you have to take this with a grain of salt.

我是不是，我是不是只是在想，我喜欢软件开发的地方——弄清楚问题是什么——才是软件开发中最难的部分？如果我错了，你可以告诉我。不过到目前为止，先假设你相信我。编程趋近于零，产品工程趋近于无穷大。这就引出了一个新的重要问题：初级开发者。因为过去我们培训初级开发者的方式，是给他们一些描述得非常明确的工单，上面写着：“按特定方式编写这款软件，然后交给我，这样我就能告诉你所有做错的地方。”而这种做法已经消失了，因为我们现在会把这件事交给——我们现在会把这件事交给编程代理来做。Am I Am I just thinking that the thing that I enjoy about software development, which is figuring out what the problem is, is the hard part of software? You can tell me if I'm wrong. but say you believe me so far. Programming goes to zero, product engineering goes to infinity. That brings us to a new and important problem, which is junior developers because the way we used to train a junior developer is we used to give them very well-specified tickets that said, "Write this software this way in particular and then give it to me so that I can tell you all the ways that you were wrong." and that is gone because that's what we do with the That's what we do with the coding agents now.

我们会说：“先把这件事写下来，然后我再告诉你哪里错了。”接着，我们会和他们聊一聊。We say, "Write this thing and then I'll tell you how you're wrong." And then we have a conversation with them.

而且，那已经不是一项还需要人来做的工作了。但我们仍然需要数量庞大的前线部署工程师或产品工程师，而我们得从某个地方找到他们。我们不能就这样抛下这一代已经出现、并问“这些东西该怎么做？”的新开发者。我们只能说：“我不知道，因为我已经不知道你现在的工作是什么了。”and there's That is not a job that we need a human to do anymore. But we still need an enormous number of forward-deployed engineers or product engineers and we have to get them from somewhere. We can't just abandon the current generation of new developers who've showed up and said, "How do I do this stuff?" We're like, "I don't know because I don't know what your job is anymore."

这并非理论上的未来，而是自 2023 年 1 月以来实际的劳动力统计图表。图表按年龄排序。红线代表 22 至 25 岁的工程师。this is not a theoretical future. This is an actual graph of labor statistics since January 2023. It is sorted by age. The red line is engineers aged 22 to 25.

他们的就业正在崩塌。我们不招初级工程师。这不是我认为将会发生的事，而是已经持续发生了两年的事。Their employment is collapsing. We are not hiring junior engineers. This is not a thing that I think is going to happen. This is a thing that's been happening for 2 years.

他们的就业市场很糟糕。与此同时，41 到 49 岁的资深工程师的就业机会大幅增加，因为资深工程师依然极具价值，甚至比以前更有价值；但初级工程师却处境艰难。作为一个行业，我们需要解决这个问题。因此，如果我们想从这样一个世界中获益——在这个世界里，我们的代码产出提升了十倍，也理清了软件供应链的其他环节，以及人类需要做些什么——那么我们就需要很多人来完成这些工作。Job market sucks for them. Meanwhile, the job for older engineers 41 to 49 has gone way up because senior engineers are still super valuable, more valuable than before, but junior engineers are being screwed and we need to fix that as a profession. so if we're going to reap the benefits of a world where we 10x code output and figured out the rest of the software supply chain and figured out what humans need to do, then we are going to need a lot of people to do that.

我说过，软件的需求会趋于无穷大。我们需要无穷多的人。我们上哪儿去找这么多人？到目前为止，我们一直是在无意中培养他们，现在得想办法有意地培养。Google 有一个产品……有一个项目，叫作副产品经理项目，结果培养出来的人看起来非常像产品工程师。I said that the demand for the software is going to infinity. We need infinity people. Where are we going to get them? we've been creating them accidentally so far and we need to figure out a way to do them on purpose. Google has a product has a program called the associate product manager program which turns out people that look very much like product engineers.

他们每年培养出50名。我们每年需要1万人。即使看看其他所有……其他所有开设了类似谷歌 APM 项目的公司，这类项目也正在被广泛效仿。它们每年培养出的人才也只有大约1,000名，而至少需要这个数字的10倍才能满足需求。They turn out 50 of them per year. We need 10,000 of them per year. Even if you look at all of the other pro all of the other companies that have something a program like Google's APM, it's being extensively copied. They're only turning out about a thousand people a year and we need 10 times that number at minimum to keep up with demand.

大学教数据结构，训练营教 React，却没人教你去跟面包师待上一周，然后带着一份规格说明回来——而我们需要的正是这样的人。所以，如果你领导一支工程团队，就得有意识地培养他们。IBM 已经在重新设计入门级岗位，让员工把重点放在与客户沟通和编写规格说明上，而不是编程。你得想办法自己做到这一点。你得想清楚如何培训产品人员？而且得非常快地做到，因为我们早该两年前就开始了。现在有整整一届非常沮丧、失业的初级从业者正面临这个问题，而我们却没有雇用他们。我们必须对此采取行动，否则我们就要完蛋了，而且遭殃的不只是他们。universities teach data structures, boot camps teach React, nobody teaches go sit with a baker for a week and come back with a spec and that is the person that we need. so if you lead an engineering team, you're going to have to grow them on purpose. IBM is already redesigning its entry-level role around talking to customers and writing specs instead of programming. you're going to have to figure out how to do that for yourself. You're going to have to figure out how do you train product people? and you're going to have to do it very quickly because the time we should have started was two years ago and there's a whole cohort of very sad unemployed juniors right now who have this problem and we are not hiring them and we need to do something about that or we are going to be screwed and not just them.

创作、过渡与切实可行的后续步骤Craft, transition, and practical next steps

所以，如果这一切真的发生了，有件大事我不想轻描淡写地带过，那就是很多人入行学编程，是因为他们热爱这门手艺。他们喜欢干净利落的抽象，喜欢棘手的 bug 终于被攻克时的成就感，也喜欢让机器严格按照自己的指令行事。他们可不是为了去采访面包师、询问他们人生想要什么才入行的。这根本不是他们当初选择的工作。而他们会讨厌这一切。so if all of that happens, there's one big thing that I don't want to just gloss over or hand wave away, which is a lot of people got into programming because they love the craft. They love a clean abstraction, the feeling of a hard bug finally giving up, making a machine do exactly what you told it to do. They did not sign up to interview bakers about what they want in their lives. Like that is not the job that they signed up for. and they are going to hate this.

他们已经很讨厌这件事了，而且正大声抱怨。我没什么安慰奖可以给他们，不过我有个观察：很多人觉得自己喜欢打字，也许他们真正喜欢的是开始打字前的那一刻——弄清楚问题的时候。那部分不会消失。They already hate this. They are complaining about it very loudly. I have no consolation prize for them. but I do have an observation, which is that for a lot of people who think they love the typing, maybe what you loved was the moment just before you started typing, when you figured out the problem. That part doesn't go away.

那部分依然存在。那种创意火花——你会想：“我知道怎么把这件事变成一个可重复使用的系统，让它在我脑海中闪闪发光。”它不会消失。编程这门手艺也会继续存在，就像木工在家具工厂兴起后依然存在一样。程序员写代码，就像歌手唱歌，对吧？That part is still there. That creative spark when you're like, I know how to make this into a repeatable system that glows in my brain. That's not going away. and the craft of programming will survive in the same way that like woodworking survived the furniture factory. Like programmers program the way that singers sing, right?

他们会在一间空荡荡的房间里做这件事，没人看，只因为他们热爱它，而这种热爱不会消失。你仍然可以这么做，只是人们不会再每年花几十万美元雇你做这件事了。所以，这是我的预测：未来十年会很难熬。过去两年已经很难熬了。这些东西带来的巨大压力，在工具准备就绪之前就已经到来了。They do it in an empty room with nobody watching just because they love it and that won't go away. You can still do that. it just won't be the thing that people pay you hundreds of thousands of dollars every year to do. so here is my prediction. The next 10 years are going to be ugly. The last 2 years have been ugly. the load of this stuff is arriving before the tools are ready.

初级岗位的晋升通道已经消失，而我们还没弄清楚如何培养更多初级人才。许多热爱这门手艺的人将不得不决定，自己是否也热爱那个取而代之的工作。The junior ladder is gone before we have figured out how to train more juniors and a lot of people who love the craft are going to have to decide if they love the job that is replacing it.

但这种情况以前也发生过。编译器、框架，再到开源，每一次都让整整一代人曾经需要做的敲代码工作变得不再必要，而每一次过后，软件开发者反而更多了。我们只是改变了软件开发的定义。我认为这种情况还会再次发生。十年后，我们会拥有一个比今天规模更大、薪酬大致相当、且主要以产品工程为形态的职业群体。这就是我今天要向你们阐述的观点。but this has happened before. Compilers and then frameworks and then open source each made a generations worth of typing before them unnecessary and each time we came out of it with more software developers. We just changed what software development meant. and I think that's going to happen again. in 10 years time we will get a profession that is bigger than today's, pays about as well, and is mostly shaped like product engineering. That is the case that I'm making for you today.

但这些都是一大堆高层次的预测，我讨厌这些。说真的，这意味着什么？你今天究竟该怎么做？首先，要为这样一个世界做好准备：人类几乎不再参与代码的编写。所以，把那些影响范围很大的代码列出来，以后只审查这些代码，因为其余的代码都可以交给自动审查工具处理。But that is a whole lot of high-level predictions, and I hate those. What does this mean for real? What should you actually do with this today? first, be prepared for a world in which humans are barely involved in the production of code. So, write down your high blast radius code, and make that be the only thing that you are reviewing anymore, because the rest of it your automatic reviewers are going to get done.

然后，把所有容易验证的事情都交给别人去做。花大量时间思考，如何构建一种自动判断某件事——无论它是什么——好不好的方法，然后把这个方法交给你的智能体，而不是试图亲自摸索审查流程。最后，把你最优秀的人才的判断标准写进规范、评分标准和评估中。你知道，我这个评估方面的人本来就打算找个时机提一下评估。把那些只存在于人们脑子里的东西变成代码。这就是你作为产品工程师的工作。then delegate that everything that's cheap to verify. Spend a lot of time thinking about how would I build an automatic way of telling whether this thing, whatever that thing is, is good or not, and then feed that to your agent instead of trying to figure out the review process. and finally, put your best people's judgment into specs and rubrics and evals. You know, I the arise guy was going to say evals at some point. get stuff that exists only in people's heads into code. That is your job as a product engineer.

它是在把对问题的理解转化为问题的规格说明，这样智能体就能替我们构建它，并衡量正确的指标。代码量增加 741% 从来都不是重点。要衡量你实际交付了多少东西，也要衡量审阅者的意见有多少次得到了落实。It is turning the sense of the problem into a spec of the problem, so that the agents can build it for us. and measure the right thing. 741% more code was never the point. Measure how much stuff you are actually shipping. measure how often your reviewers comments get acted on.

衡量一下测试通过与维护者愿意合并代码之间的差距。记住，最后的审查者是生产环境。观察它在生产环境中的表现，再让另一个模型给它打分，这就是一次评估。我不是要推销 Arise；我们做的就是这些，这也是我们现在这么受欢迎的原因。就说到这里。三年前，Swyx 写过一篇关于 AI 工程师兴起的文章，讲的是工程师如何学会借助模型进行构建。而产品工程师的兴起，则关乎模型承担构建工作之后，剩下的事情：找出人们需要什么，明确什么才算做好，并把它做成大家喜欢的东西——这就是如今的工作。Measure the gap between the tests passed and a maintainer would merge this. and remember that the last reviewer is production. Watching what it does there with another model grading it, that is an eval. I'm not going to pitch arise, that's just what we do, and that's why we're so popular right now. and I'll leave it at that. 3 years ago, Swyx wrote about the rise of the AI engineer, which is engineers learning to build with models. And the rise of the product engineer is about what's left when the models do the building. finding out what people need, writing down what good means, and making it something people like, that is the job now.

无论我们是否愿意，这都将成为在座每个人的工作。如今，我们都是产品工程师。非常感谢大家抽出时间并给予关注。It is going to be the job for everyone in this room, whether we like it or not. We are all product engineers now. Thank you so much for your time and attention.