"The engineer of the future is the person who is able to choose what is worth doing." — Addy Osmani

频道: AI Engineer
视频: https://www.youtube.com/watch?v=n97BCfyFIvw
原文语言: en
统计: 共 10 轮 · Addy 10

[0:01] Addy

[music]

[音乐]

[0:20] Addy

Howdy, folks. So, good afternoon or good whatever time it is when you're watching this on YouTube. I'm really excited to be here. And um today I want to talk to you about really uh what it takes to keep the human in the loop where engineering is concerned. I really want to start with a human side before we talk about the architecture here. I think that the engineer of the future is going to be really defined by the person who is able to choose what is worth doing. They're going to own the evidence. They're going to own the understanding as well as the verdict. around increasingly automated work that's being done by agents. Now, when I use the term verdict, I don't mean that we're suddenly all going to be Judge Judy. We're not. But what I mean really is something just a little bit different. I mean, we're going to be accountable for the production decisions. Does something ship? Do we block it? Do we redirect it or accept the risk? Quality is something that we all talk about a lot, but quality produces evidence. A verdict assigns responsibility. And answerability is really what lets us stand behind a verdict. And this of course is not the only way that our industry is starting to think about our roles evolving. Boris Cherney recently put some useful language around what many teams are starting to feel. The old craft boundaries are getting blurry, and roles are re-bumbling around the work itself. And the important question here becomes a lot less about what is your title and more what part of the system can you own? Now, I like this taxonomy quite a lot. Um it's optimistic without being overly vague. So, things like prototype, build, sweep, grow, and maintain. And these are real engineering modes. Agents are going to help with all of them, but the scarce thing is not merely doing the task. It's going to be knowing which mode your product needs and what quality bar applies and who owns the result at the end of the day. Now, we've been talking about harnesses and loop engineering and software factories over the last couple of days. We can talk why this shift is happening. We moved past the model as the whole story, right?

大家好。下午好——或者说，不管你在 YouTube 上看到这段视频时是什么时间，都问个好。很高兴能来到这里。今天我想聊聊：在工程领域，要让人真正留在 loop 里（human in the loop），到底需要什么。在谈架构之前，我想先从「人」这一面讲起。我认为，未来的工程师，将由这样一种能力来定义——能够选择什么事情值得做。他们要掌握证据（evidence），掌握理解（understanding），也要掌握最终裁决（verdict）——面对越来越多由 agent 完成的自动化工作，这些都得由人来负责。我说「裁决」，并不是说我们都要突然变成朱迪法官（Judge Judy）。不是的。我的意思稍有不同：我们要为生产决策负起责任。这个东西要不要上线？要不要拦下来？要不要转向，还是接受风险？「质量」是我们天天挂在嘴边的词，但质量只是产出证据，而裁决是分配责任。而「可问责性（answerability）」正是让我们能够为一个裁决背书的东西。当然，这不是业界思考角色演变的唯一方式。Boris Cherny 最近给很多团队正在感受到的东西提供了一套有用的语言：旧的职业边界正在变得模糊，角色正在围绕工作本身重新组合。这时候，重要的问题不再是「你的头衔是什么」，而是「你能拥有（own）系统的哪一部分」。我很喜欢这个分类法——它乐观，但又不空泛。比如 prototype（原型）、build（构建）、sweep（清扫）、grow（增长）、maintain（维护），这些都是真实存在的工程模式。agent 会在所有这些模式上帮忙，但稀缺的不是把任务做完这件事本身，而是知道你的产品需要哪种模式、适用什么样的质量标准、以及最终谁为结果负责。过去这两天我们一直在聊 harness、loop engineering、software factory 这些话题。我们可以说说这个转变为什么会发生——我们已经走过了「模型就是全部」的阶段，对吧？

[2:45] Addy

With harness engineering, the coding agent is the model plus the harness around it, right? Your context, your tools, your file system, Git. And the harness is what turns intelligence into something that you can delegate to. The next move was loop engineering, where we weren't just prompting one run anymore. We were designing systems that kept prompting, checking, and remembering, and deciding what happened next. And that's really when agents [clears throat] started to feel like infrastructure. And once you start putting all of those things together, you get that software factory. Dex covered this well in his talk, where you have agents that are running inside that inner loop and evidence that comes out. Humans still end up making the production decisions in this loop. And the wind really isn't moving us from it. The wind is moving human judgments the highest leverage checkpoint, I think. And this is why it starts to matter now. AI-generated and AI-assisted code is becoming normal code for a lot of us. One of Sonar's 2026 survey said that AI-assisted code is no longer marginal. It's increasingly having a large role in our code bases. And once that happens, answerability stops being this philosophical world. It becomes an engineering requirement. And there's a quality point here as well, right? Like we used to care about clean code, code that people could read. But cleaner code is actually not just going to help the next human and the next person on your teams. It actually helps the next agent. Another one of Sonar's research uh studies found that clean and messy repos had roughly the same pass rates, but clean code actually used fewer tokens and caused fewer revisits. So there's a lot of benefit to maintainability that can fuel efficiency for your factories. Now, making generation cheaper does not automatically make review cheaper, right? I think a lot of us are facing this moment and we know that engineers are not naive. The Sonar numbers say that almost everybody is skeptical of AI code. Now, I love working in my software factory. I love building my engineering loops. But the problem is still capacity.

在 harness engineering 里，coding agent 等于模型加上围绕它的 harness——你的上下文、你的工具、你的文件系统、Git。正是 harness 把「智能」变成了一个你可以放心委托的东西。接下来的一步是 loop engineering：我们不再只是提示一次运行，而是在设计能够持续提示、持续检查、持续记忆、并决定下一步做什么的系统。也正是从那时起，agent 开始像基础设施了。当你把这些东西全部组合起来，你就得到了 software factory（软件工厂）。Dex 在他的演讲里讲得很好：agent 在内循环（inner loop）里运行，产出证据。而在这个循环里，生产决策依然由人来做。风向并没有把我们从循环中吹走，而是把人类判断推向了杠杆率最高的检查点——我是这么看的。这也是为什么这件事现在开始变得重要。对我们很多人来说，AI 生成、AI 辅助的代码正在变成「普通代码」。Sonar 2026 年的一份调研说，AI 辅助的代码已经不再是边缘现象，它在我们的代码库中占的比重越来越大。一旦到了这个地步，可问责性（answerability）就不再是个哲学话题，而变成了一项工程需求。这里还有一个关于质量的点：我们过去讲究 clean code，讲究写人读得懂的代码。但更干净的代码不只是在帮团队里的下一个人——它其实也在帮下一个 agent。Sonar 的另一项研究发现，干净的仓库和混乱的仓库通过率大致相同，但干净的代码消耗的 token 更少、返工更少。所以可维护性带来的好处，能实实在在地转化为你的「工厂」的效率。不过，让生成变便宜，并不会自动让评审（review）变便宜，对吧？我想很多人都正面临这个时刻，而且我们知道工程师并不天真。Sonar 的数据显示，几乎所有人都对 AI 代码持怀疑态度。我很喜欢在我的 software factory 里干活，也喜欢搭建我的 engineering loop。但问题依然出在容量（capacity）上。

[4:50] Addy

If 96% of people don't fully trust that code, but only about half always verify before committing, we have this danger that we've got distrust without bandwidth. And so safety comes from making verification cheaper, clearer, and harder for people to skip. And if you zoom out from the individual reviewer to the organization, review and validation start becoming a bottleneck when governance isn't able to catch up and adoption is already moving way faster than any company can go and set their policies. And this means that we have some hard questions we have to deal with, like did a model actually touch this file? And the hard questions are also like what constraints guided that work? What evidence was produced? What risk was accepted and who owned the result? Now, the agent can ship more than any of us can review, right? So what are we still good for? I think it's a question that's on a lot of our minds, right? And you know, if Homer Simpson's experience automating computers can teach us anything, maybe this is our future. I don't think it is. But it's one direction things could take. Now, let's try that again. If change is where humans enter the loop, if generation scales faster than comprehension, the scarce resource becomes judgment that's backed by evidence. So, the question is no longer how much can the agent do, but where does human judgment still create leverage? Now, I want to talk to you about two terms that I'm going to use for the career part of this talk, alpha and decay. Alpha is the gap between what you can do today and what current models can do. That gap is a very real thing, and decay is the clock on that gap. If the thing that makes you special is a capability, the frontier is eventually going to come for it. Right? And there's a whole conversation around this. This is one of the reasons why taste keeps coming up. Paul Graham had a point here that I think is very right. When anyone can make anything, choosing what to make becomes very important, and I buy that. But I also think that we have to be very careful because taste can become a magic word for whatever part of the work we don't want to explain just yet.

如果 96% 的人不完全信任那些代码，却只有大约一半的人会在提交前坚持验证，那我们就陷入了一种危险境地：有不信任，却没有带宽。所以，安全感来自于让验证变得更便宜、更清晰、更难被跳过。如果你把视角从单个评审者拉远到整个组织，当治理（governance）跟不上、而采用速度已经远远快于任何公司制定政策的速度时，评审和验证就会变成瓶颈。这意味着我们必须面对一些棘手的问题，比如：模型到底有没有碰过这个文件？还有更难的：那项工作受到了什么约束的引导？产出了什么证据？接受了什么风险？谁为结果负责？agent 能交付的东西，已经超过了我们任何人能评审的量，对吧？那我们还有什么用？我想这是很多人心里都在盘旋的问题。如果 Homer Simpson 用电脑搞自动化的经历能教给我们什么，也许那就是我们的未来。我不这么认为，但那确实是事情可能走向的一个方向。好，我们换个说法再来一遍：如果「变更」是人类进入 loop 的地方，如果生成的扩张速度快于理解的速度，那么稀缺资源就变成了有证据支撑的判断力。所以问题不再是「agent 能做多少」，而是「人类判断还能在哪里创造杠杆」。接下来我想介绍两个术语，用于这个演讲关于职业发展的部分：alpha 和 decay（衰减）。alpha 是你今天能做到的事和当前模型能做到的事之间的差距。这个差距是实实在在存在的。而 decay 是悬在这个差距头上的倒计时。如果让你与众不同的是某种「能力」，那么前沿（frontier）终究会追上它。围绕这一点有一整场讨论，这也是「品味（taste）」这个词不断被提起的原因之一。Paul Graham 有个观点我认为非常对：当任何人都能做出任何东西时，选择做什么就变得非常重要。这我买账。但我也认为我们必须非常小心，因为「品味」很容易变成一个魔法词，用来指代工作中我们暂时不想解释清楚的那部分。

[7:05] Addy

Mitchell Hashimoto gave us a more useful version of this definition. Taste is the ability to make high-quality qualitative judgments where no objective metric exists yet. That matters because it puts taste before the benchmark and before the market has fully voted. When you try out a model and you see the kind of UX and the kind of experiences that it builds, you can often tell when you think it has taste or lacks taste or where there's a gap there that humans can fill. Now, this is also only useful if we can turn some of this concept around taste into critique, examples, and better judgment over time. So, yes, taste matters when production gets cheaper. And if anyone can generate 10 options, the scarce skill is really knowing which option deserves to exist. But taste is not some eternal moat. It's alpha as well. Now, the people with taste are still going to matter. I personally think they're still going to matter for a long time. But the best version of that skill is not mystique. It's making better calls and leaving behind examples that your team and the system can learn from. Now, let's apply the decay test. Well, we used to have speed. That decayed. We used to have recall. You know, harnesses have memory. Verification is moving into harnesses, evals, static checks, and model critique. Taste, I continue to think this is going to decay much more slowly, but it still resets as models learn from examples and preferences. Even judgment in some ways is a slope rather than a wall. So, the strategy is not to cling to any one capability. It's for us to keep moving our edges up a level. So, this is one of the reasons why what can the agent do is not the best strategic question anymore. The list of things that agents can't do just keeps shrinking. The better question for us is really what can only a human be answerable for. Not because, you know, any of us are are magical in any way, but because some decisions actually require ownership. They require context, risk acceptance, and responsibility after that work ships. This is why the word engineer has to get just a little bit stricter. More people than ever can now make computers do things, and I think that's truly awesome.

Mitchell Hashimoto 给了我们一个更有用的定义版本：品味，是在尚不存在客观度量标准的地方，做出高质量的定性判断的能力。这个定义之所以重要，是因为它把品味放在了 benchmark 之前、放在了市场充分投票之前。当你试用一个模型，看到它构建出来的 UX 和体验时，你往往能分辨出它是有品味还是缺品味，或者哪里存在人类可以填补的空隙。当然，这个概念只有在我们能把「品味」转化为批评（critique）、示例（examples）以及随时间不断改进的判断力时，才真正有用。所以，是的，当生产变便宜时，品味很重要。当任何人都能生成 10 个方案时，稀缺的技能是知道哪个方案配得上存在。但品味并不是什么永恒的护城河——它同样是 alpha。有品味的人依然会重要，我个人认为他们还会重要很长一段时间。但这项技能最好的形态不是故弄玄虚，而是做出更好的决策，并留下你的团队和系统都能学习的示例。现在，让我们做一下衰减测试（decay test）。我们曾经拥有速度优势——它衰减了。我们曾经拥有记忆力优势——你看，harness 现在有 memory 了。验证能力正在被搬进 harness、评估（evals）、静态检查和模型自我批评里。至于品味，我仍然认为它的衰减会慢得多，但随着模型从示例和偏好中学习，它也会被重置。甚至连判断力，在某种程度上也是一个斜坡，而不是一堵墙。所以，正确的策略不是死守任何一项能力，而是不断把我们的优势往上挪一个层级。这也是为什么「agent 能做什么」不再是最好的战略问题——agent 做不了的事情清单只会越来越短。对我们来说更好的问题是：什么事情只有人类能够为之负责（answerable）？不是因为我们中任何人有什么魔力，而是因为有些决策确实需要所有权（ownership）——需要上下文、需要接受风险、需要在工作上线之后继续担责。这就是为什么「工程师」这个词必须变得再严格一点。现在能让计算机做事的人比以往任何时候都多，我认为这真的很棒。

[9:25] Addy

The total addressable market for builders has never been larger, and that's so cool. But it's a huge expansion of leverage. An engineer is not merely somebody who can code, you know, and and get things to exist. An engineer can reason about systems. They think about constraints, you defend trade-offs, you can manage risk, and you're the person that can be reached out to when things start to break. So, what are things that engineers should avoid if we want to stay effective and accountable in this moment? Well, the first thing to avoid really is cognitive debt. Now, cognitive debt is the erosion of your understanding and memory around how to solve problems. I think a lot of us start to feel this the more that we're using agents every single day. I know that I feel this a lot. And it's because we're deferring more and more to AI to solve our problems. For code, it's the gap between how much code exists in your repo and how much any human on your team genuinely understands. And this is why things like delegation debt end up mattering. You can have a build that passes, you know, your tests, a PR that you can merge, but your team can still end up losing its ability to actually explain the system that they are shipping to production. Now, a very real pressure is all much is also how much we delegate. So, agents can now stay inside the system long enough for the human to lose the thread. So, a 30-second run, right, can feel like an interaction, but an hour or a day-scale task, so something long horizon, that's a work stream. And when tasks can end up, you know, lasting that long, especially when you begin running many of them in parallel, review can't just be a glance at the end. It has to become a whole control system. The second thing to avoid is cognitive surrender. Now, this is when you blindly accept AI's um responses. Like, delegation is important cuz delegation says, "Do the work, then show me enough evidence that I can judge it." I still make a judgment in that situation. Surrender is really saying, "Hey, your answer is now my answer before I have formed any opinions myself. Now, um Wharton did a study that kind of offers us a warning light here.

建造者（builder）的潜在市场从未如此之大，这太酷了，是杠杆的巨大扩张。但工程师不只是「会写代码、能把东西做出来」的人。工程师能对系统进行推理：思考约束、为权衡辩护、管理风险，并且是出问题时大家能找得到的那个人。那么，在这个时刻，如果我们想保持高效且可问责，工程师应该避免哪些东西？第一个要避免的是认知负债（cognitive debt）。认知负债是指你对「如何解决问题」的理解和记忆的侵蚀。我想，随着我们每天越来越多地使用 agent，很多人都开始感觉到这一点——我自己就深有体会。因为我们把越来越多的问题解决工作推给了 AI。落到代码上，它就是你仓库里存在的代码量，和你团队里任何一个人类真正理解的代码量之间的差距。这也是为什么「委托负债（delegation debt）」会变得重要。你可以有一个通过测试的构建、一个可以合并的 PR，但你的团队仍然可能逐渐丧失解释「他们正在上线到生产环境的这个系统」的能力。另一个非常现实的压力，在于我们委托了多少。agent 现在可以在系统里待足够长的时间，长到人类会跟丢线索。一次 30 秒的运行感觉像一次交互，但一个小时级、一天级的长程（long horizon）任务，那是一条工作流（work stream）。当任务能持续那么久，尤其是当你开始并行跑很多个任务时，评审就不能只是最后瞄一眼——它必须变成一整套控制系统。第二个要避免的是认知投降（cognitive surrender）。这是指你盲目接受 AI 的回答。委托（delegation）之所以重要，是因为委托的意思是：「把活干了，然后给我看足够的证据，让我能做出判断。」在那种情况下，判断依然由我来做。而投降是在说：「在我自己形成任何看法之前，你的答案就已经是我的答案了。」Wharton 商学院做过一项研究，给我们亮了一盏警示灯。

[11:36] Addy

When AI was wrong, 73% of people still thought that they they you know they picked the wrong answer and they felt more sure. So, the failure mode is not using AI, but it's borrowed confidence. The third thing to avoid is orchestration tax. Now, if you've been in the Bay Area, you will see people who for better or worse are still walking around with their laptops open or talking to you about cloud agents. And we're increasingly trying to run more and more and more in parallel or telling each other that we're shipping with hundreds of agents or thousands of agents. More AI agents running does not mean that there is more of you available. Your cognitive bandwidth does not parallelize. So, every loop that you create ends up causing more decisions to route, merge, verify, and integrate. And the fix is not necessarily fewer agents, but it's about designing your attention like a system. Like where you enter, what you require, what you reuse. You just want to be very intentional about it. Now, accountability can be a scary word for a lot of people. And I wouldn't be surprised if it made you want to go hide in the bushes and just tell your agent to deal with it. But, accountability is not what remains after agents get good. It's what lets the rest of the whole system scale. If agents can do more work, if they can do it faster and parallel, better than what many of us could do, the scarce thing becomes the ability to explain intent, to inspect evidence, to accept risk, and improve the system when the decision was wrong. Now, here is the career math. The half-life of an edge might be one model release. Speed, recall, verification, even taste all move as the frontier moves. But, the half-life of a signature, your credibility, your expertise is much longer. And by signature, I really mean the name on the work, the person, the team, the institution, whoever stands behind what's actually shipped. So, skills can earn leverage, accountability can turn leverage into trust. And this is one of the lines that I want to draw pretty clearly. Agents can choose, they can route, they can merge, they can escalate, they can operate inside policy. And in many systems, you know, they can, they should.

当 AI 答错的时候，73% 的人依然选了那个错误答案，而且他们反而觉得更有把握了。所以失败模式不是「使用 AI」，而是「借来的自信」。第三个要避免的是编排税（orchestration tax）。如果你在湾区待过，你会看到有些人——不管是好是坏——走到哪儿都开着笔记本电脑，或者跟你大谈云端 agent。我们越来越倾向于并行跑更多更多的任务，或者互相吹嘘自己在用几百个、几千个 agent 交付。但跑着更多的 AI agent，并不意味着「你」变多了。你的认知带宽是无法并行化的。你创建的每一个 loop，都会带来更多需要路由、合并、验证、集成的决策。解决办法不一定是减少 agent 数量，而是像设计系统一样设计你的注意力：你在哪里介入、你要求什么、你复用什么——你只需要对此非常有意识、有意图。「问责（accountability）」这个词对很多人来说挺吓人的。如果它让你想躲进灌木丛里，把一切丢给 agent 去处理，我一点也不意外。但问责并不是 agent 变强之后剩下的残余物——它恰恰是让整个系统得以扩展的东西。如果 agent 能做更多的工作、做得更快、并行度更高、比我们许多人做得更好，那么稀缺的就变成了这些能力：解释意图、检查证据、接受风险，以及在决策出错时改进系统。接下来是职业发展的数学题：一项优势的半衰期，可能就是一次模型发布。速度、记忆力、验证能力，甚至品味，都会随着前沿的推进而移动。但你的「签名（signature）」——你的信誉、你的专业声望——半衰期要长得多。我说的签名，指的是署在工作上的名字：那个人、那个团队、那个机构，为实际交付的东西背书的主体。所以说，技能能赢得杠杆，而问责能把杠杆转化为信任。这也是我想画得非常清楚的一条线：agent 可以选择、可以路由、可以合并、可以上报、可以在政策框架内运作——在许多系统里，它们不但可以，而且应该这样做。

[13:55] Addy

But execution and responsibility are very different things. The agent can follow your runbook, but it can't inherit the consequences. When something fails, the question is, who understood the policy? Who accepted the risk and who owns the blast radius? High agency is something that a lot of us talk about these days as being like this thing that we're looking for when we're hiring. High agency is actively taking ownership of your outcomes. So, knowing when to delegate, when to inspect, when to stop, and when to put your name on the result. High agency in this world is not I personally do everything. You know, that version doesn't really scale. It's not just hustle theater, but it's ownership with judgment attached. This agency ladder tries to make that a little bit more concrete. At the bottom, you've got someone that flags a problem and leaves it for the system. Higher up, they execute, diagnose, propose, recommend, and resolve. And the rare top movement is discernment. You know, maybe you find a problem and you decide whether or not it's worth investing in. Maybe it's not, and maybe you move on. But when agents make more paths possible, agency is not chasing every single path. It's really just deciding which paths deserve your ownership and attention. So, translate that into an operating model. Agents can run much more of the inner execution loop. They can investigate, implement, test, and report. I think that there's leverage in that, but that outer loop is still engineering. So, deciding, verifying, approving, owning, that inner loop is capability. The outer loop is agency. And this is a boundary that I really care about. Your agent returns evidence. It returns diffs, tests, logs, rationale, traces, trajectories, screenshots, whatever the work itself requires. But then the engineering really begins. We decide whether the work was worth doing. We verify whether the evidence is enough, and we approve or redirect or own what reaches production. It doesn't matter if you're someone that's just working with a small number of agents, or whether you're working with thousands of agents. I still very much think that these ideas apply. So, the boundary is not human looks at AI output.

但执行和责任是两码事。agent 可以照着你的 runbook 走，但它无法继承后果。当出问题的时候，要问的是：谁理解那条政策？谁接受了那个风险？谁为爆炸半径（blast radius）负责？「高能动性（high agency）」是如今很多人在招聘时挂在嘴边的词。高能动性意味着主动为你的结果负责：知道什么时候委托、什么时候检查、什么时候叫停、什么时候把自己的名字签在结果上。在这个时代，高能动性不是「所有事我亲自干」——那个版本根本没法扩展；它也不是表演式的拼命（hustle theater），而是附带判断力的所有权（ownership）。这个「能动性阶梯（agency ladder）」试图把这件事讲得更具体一点。在最底层，是发现问题、然后丢给系统了事的人。往上走，是执行、诊断、提议、建议、直到解决问题的人。而最顶端那个稀有的动作，是辨别力（discernment）：也许你发现了一个问题，然后你来判断它值不值得投入——也许不值得，那就继续前进。当 agent 让更多的路径变得可能时，能动性不是追逐每一条路径，而恰恰是决定哪些路径配得上你的所有权和注意力。把这些翻译成一个运作模型：agent 可以承担更多的内层执行循环——调查、实现、测试、汇报。我认为那里有杠杆。但外层循环（outer loop）依然是工程：决策、验证、批准、担责。内循环是能力（capability），外循环是能动性（agency）。这条边界是我非常在意的。你的 agent 返回证据：diff、测试、日志、rationale、trace、trajectory、截图——工作本身需要什么就返回什么。但真正的工程从那之后才开始。我们来决定这项工作值不值得做，我们来验证证据是否充分，我们来批准、转向，或者为最终进入生产环境的东西负责。不管你手上只有几个 agent，还是同时驱动着几千个 agent，我都认为这些原则同样适用。所以，这条边界不是「人类看一眼 AI 的输出」那么简单。

[16:07] Addy

The boundary is evidence and responsibility. So, here's an operational rule. Explain it or don't ship it. And it's not because humans have to type every line or read every line, but because someone has to understand the work well enough to defend it. If you've ever worked in a large code base or an enterprise code base, some code bases have this concept of an owners file or certain subdirectories where there are people who are on the hook for that part of the system. You can think about this in a very similar way. Who is accountable for that part of your architecture and your code base? Your model might write the code, and the question is really still whether you can explain those changes that the agent is shipping, whether you've got the evidence where you understand the risks. Now, this is one of the things I want you to remember near the end. Automation moves the floor for all of us. Engineering continues to move up a level, and our new work might be loop design, evidence design, and brownfield stewardship, but fewer keystrokes doesn't mean less engineering over the next few years. It means that there is more surface area that needs taste, verification, ownership, and ultimately care. I don't think I've ever been more excited about the future of this field. Every time that we have made it easier to write software, we've predicted that the world would need less of it. And in fact, the opposite happened. Higher-level languages happened, frameworks, cloud, low code. The pattern always went the other way. And when you lower the cost, latent demand ends up appearing. Those ideas that people didn't think were feasible to build and get out there are suddenly unlocked. And agents are going to do the same thing for a lot of people. It's not going to remove engineering work. It's going to move the bottleneck from can we build this to should this exist and can we answer for it? So, build the factories, keep the lights on, own the verdict. I hope this was useful. Thank you.

边界在于证据和责任。所以这里有一条可操作的规则：解释不了，就别上线（Explain it or don't ship it）。这不是说人必须亲手敲每一行代码、读每一行代码，而是说必须有人对这份工作理解得足够深，深到能为它辩护。如果你在大型代码库或企业级代码库里干过，就知道有些代码库有 owners 文件的概念，某些子目录会指定专人对系统的那一部分负责。你可以用类似的方式来思考：你的架构、你的代码库里，每一块到底由谁来负责？模型可以写代码，但真正的问题依然是：agent 交付的这些改动，你能不能解释清楚？你有没有掌握证据、理解其中的风险？临近结尾，这是我希望你们记住的一点：自动化抬高的是所有人的地板。工程这门手艺会继续往上走一层，我们的新工作可能会变成 loop 设计、证据设计和存量系统（brownfield）的守护。但未来几年里，敲键盘变少不等于工程变少——它意味着有更大的面需要品味、验证、所有权，归根结底是需要用心。我从没像现在这样对这个领域的未来感到兴奋。历史上每一次我们让写软件变得更容易，人们都预测世界会需要更少的软件，而事实恰恰相反。高级语言出现了，然后是框架、云、低代码——规律总是朝反方向走。当你把成本降下来，潜在需求就会冒出来：那些人们原本觉得不可行、做不出来的想法，突然就被解锁了。agent 会为很多人做同样的事。它不会消灭工程工作，而是把瓶颈从『我们能不能做出来』挪到『这东西该不该存在，我们能不能为它负责』。所以——把工厂建起来，让灯一直亮着，守住最终裁决权。希望这些对大家有用，谢谢。

[18:23] Addy

[music]

[音乐]