Coding Agents Don't Scale Themselves. Neither Do Your Teams. — Patrick Debois, Tessl

频道: AI Engineer
视频: https://www.youtube.com/watch?v=zCJtYuqwm7E
原文语言: en
统计: 共 28 轮 · Patrick 27

[0:12] Patrick

Well, welcome. Um last day, I guess. That's what happens. Um I'm going to talk to you maybe not on the technical side, but more on the organizational side. So, if you're here for any technology, you can still leave if you want to. So, in 2009, um a lot of people were telling me the idea of continuous delivery was crazy. And I feel we're in kind of the same era or kind of the same thing right now with a dark factory. It will not work here. That's what I keep hearing over and over again. Um but what they're actually signaling to me, we're not ready yet. So, it's not the technology that can't make it work. It's not something they won't be able to do eventually, but they're just not set up for this.

好，欢迎各位。呃，我想这是大会最后一天了，该来的总会来。我今天要讲的可能不偏技术，更多是组织层面的东西。所以如果你是冲着技术来的，现在走也来得及。2009 年的时候，很多人跟我说持续交付（continuous delivery）这个想法太疯狂了。我觉得我们现在面对「黑灯工厂」（dark factory），正处在同样的阶段、同样的局面。「这在我们这儿行不通」——这句话我反反复复听到。但他们其实是在向我传递一个信号：我们还没准备好。所以不是技术做不到，也不是他们最终做不到，只是他们还没为此搭好架子。

[1:04] Patrick

And there's been a lot of conference talks here about optimizing agents with loops and harnesses and all those pieces, and I think that's great. But eventually, we'll get there, right? It's not that this is the rocket science. And yes, we'll have to assemble this in a good way, but one day, this will kind of become commodity. Somewhere maybe even going into one of the, you know, frontier labs that just offers this as a service and will kind of make this work. Uh and that's not going to be the differentiator um for your organization. So, I'm starting from there up. Assume we're heading towards the dark factory, some kind of form of autonomous working within an organization.

这次大会上有很多演讲都在讲怎么用 loop、harness 这些东西把 agent 调优，我觉得很好。但最终我们都会走到那一步，对吧？这又不是什么火箭科学。没错，我们得把这些东西好好拼装起来，但总有一天，这些都会变成大路货。说不定某个 frontier lab 直接把它做成服务提供给你，让它就这么跑起来。呃，到那时，这就不再是你们组织的差异化优势了。所以我是从这个前提往上讲的：假设我们正在奔向黑灯工厂，奔向组织内某种形式的自主工作方式。

[1:48] Patrick

Um what I've seen for the people adopting this within our organization, including here where I work at Tessal, it changes dynamic of the way you collaborate around us. And for those familiar, there's like Conway's Law, like, you know, the way you organize yourselves and the tools, there is a relationship on how they interact and kind of work together on this. But today, I'm not talking about like how do you become better with your agent, but it is about how will will change your team dynamics, your platform, and your organization. So, that's what I'll take you through. Enabling the team. I assume most of you somewhere work in a team and that you're not somewhere a solopreneur [music] working. So, it kind of works different than just you with your Claude code and a team working together around that with Claude or any of the coding agents there as well.

呃，我在我们组织里——包括我现在工作的 Tessl——观察到，采用了这种方式的人，围绕它协作的动态都变了。熟悉的人知道有个康威定律（Conway's Law），就是你们怎么组织自己、用什么工具，这两者之间是有关联的，会互相影响、一起起作用。但我今天不讲「你怎么把自己的 agent 用得更好」，而是讲它会怎么改变你的团队动态、你的平台、你的组织。这就是我要带大家走一遍的内容。先说赋能团队。我假设在座大多数人都是在团队里工作的，不是独自一人在单干的 solopreneur（音乐）。因为「就你一个人配一个 Claude Code」，和「一个团队围绕 Claude 或者随便哪个 coding agent 一起干活」，玩法是不一样的。

[2:46] Patrick

The narrative that I heard a lot is well, the developer eventually becomes more of a conductor and an orchestrator of agents. And then I think that's fair. That's been an evolution that we're on on the path where more like becoming the managers of the agent, they're kind of dealing with the agents. Now, what I've seen is that if eventually a lot of developers told me, "We didn't sign up for this. We didn't sign up for better prompting, writing better specs. We're engineers. We're technical." And that creates friction, like, is this the role that we really want to do? There was a thing that came around which maybe is more context engineering that put a first step around like, "Hey, it's not just a prompt. We'll test the prompt. We'll kind of evaluate the prompt. We'll kind of distribute the prompt and kind of optimize the prompt."

我经常听到一种叙事：开发者最终会更像 agent 的指挥家和编排者。我觉得这说得没错。我们确实走在这条演化路径上，越来越像 agent 的管理者，整天跟 agent 打交道。但我看到的是，最后很多开发者跟我说：「我们当初可没报名干这个。我们不是来学怎么写更好的 prompt、写更好的 spec 的。我们是工程师，我们是搞技术的。」这就产生了摩擦：这真的是我们想要的角色吗？后来出现了一个东西，也许更像是 context engineering，它算是往前迈了第一步：「嘿，这不只是一个 prompt。我们要测试 prompt、评估 prompt、分发 prompt、优化 prompt。」

[3:39] Patrick

So, yes, there's a little bit of engineering, but still a lot of developers kind of felt empty just working kind of with a prompt and a specification as such. What I've seen is that when we started introducing harness and loops and eventually more autonomous work within the whole organization, a new technical path opened. All of a sudden, we were helping the agent with tooling, building tooling for the agent, and that kind of reignited some of the developers who kind of felt that it wasn't for them. Now, all of a sudden, they were like, "Yes, we can do this. We have that knowledge. We're like somehow helping this even with a kind of programmatic way." So, I I think that's interesting that the identity, where we say abstraction, abstraction, abstraction, technically, all of a sudden, the craft created some new location for more engineering stuff to go to.

所以，没错，这里面有一点工程味，但很多开发者还是觉得空落落的，整天就跟一个 prompt、一份 spec 打交道。我观察到的是，当我们开始引入 harness 和 loop，最终在整个组织里推更自主的工作方式时，一条新的技术路径打开了。突然之间，我们在用工具帮 agent，在给 agent 造工具，这重新点燃了那些原本觉得「这不适合我」的开发者。一下子他们变成了：「对，这个我们能干。我们有这方面的知识。我们能用某种程序化的方式来帮它。」所以我觉得有意思的地方在于身份认同：我们一边在技术上喊抽象、抽象、再抽象，一边这门手艺突然又开辟出了一块新地盘，让更多工程性的活有地方可去。

[4:37] Patrick

Now, when I get the question, "Can we please help people?" And there's skeptical people, what do they do? And I always really say that these are really great people to engage in creating better context for the agent because you tell them, "Please improve. Please put all your knowledge to improve the result of the agent." And the same with the harness. So, if you have those kind of more resistant people that like complain maybe about the quality that things were produced by just the vanilla kind of coding agent, use almost that anger, use kind of that skepticism to kind of make it better. And the big mentality shift, if I would advise a a a a company right now for their developers, is kind of stop fixing the code that the agent kind of produced, but improve the system.

然后，经常有人问我：「能不能帮帮大家？」团队里有些持怀疑态度的人，他们该干什么？我一直很认真地说，这些人恰恰是最适合拉进来给 agent 做更好的 context 的，因为你可以跟他们说：「请你来改进。把你所有的知识都拿出来，让 agent 的产出更好。」harness 也是一样。所以如果你手上有那种比较抗拒的人，可能老抱怨原生 coding agent 产出的质量差，那就几乎是借用他们那股火气、那股怀疑劲儿，去把东西做得更好。如果现在让我给一家公司的开发者提建议，最大的一个心态转变是：别再去修 agent 写出来的代码了，去改进系统。

[5:36] Patrick

I'm I have I'm not the only one saying this in this event, but kind of that is the difference. Like you kind of improve the system. And I think it was Swyx uh a couple of years who said it, like stop building the thing, but build the thing that builds the thing, right? So, we going on that abstraction where that is with context, with harness, with loops. And that is kind of the change that a lot of people who are still very tightly in the loop, auto completion, prompting, that they kind of need to think about elevating this to the system thinking. So, what we're really trying to do is minimize the human touches, but still with good engineering practices.

这场活动上不止我一个人在说这句话，但区别就在这里：你要改进的是系统。我记得是 Swyx 几年前说的：别造那个东西了，去造「造那个东西的东西」，对吧？所以我们就是在往那个抽象层走——靠 context、靠 harness、靠 loop。对于那些还紧紧扒在循环里的人——自动补全、写 prompt——他们需要想想怎么把自己提升到系统思维这一层，这就是那个转变。所以我们真正想做的，是把人工介入降到最少，但仍然保持好的工程实践。

[6:19] Patrick

And some of the narrative that comes up more often in the beginning, we're like, "Oh, great. I write code in a prompt, and then it gives a result, and we can keep going." Where we now see, well, we're kind of instructing it through prompts, but we're also instructing this like, "Please do it with tests. Please update the documentation. Please do this." All the things that we're saying to good engineers, we're now asking the agents to do. So, if you still have people who kind of yoloing their way into this, I think you should tell them, "No, stop doing this." Like, engineering practices still matter for you to maintain the system, and also for the agent to keep getting better at this.

刚开始的时候经常出现一种叙事：「太棒了，我在 prompt 里写代码，它给我结果，然后就能一直往下走。」而我们现在看到的是，我们确实在通过 prompt 指挥它，但同时也在这样要求它：「请配上测试。请更新文档。请做这个。」我们对优秀工程师说的所有那些话，现在都在要求 agent 去做。所以如果你那儿还有人在 yolo 式地瞎搞，我觉得你该告诉他们：「不行，别这么干了。」工程实践依然重要，既是为了你能维护好系统，也是为了让 agent 在这上面越来越好。

[7:03] Patrick

What I started seeing in some of the more advanced kind of teams is that their rituals of "Hey, we're doing a planning, and we're doing a retro in a team." That they weren't about like, "Hey, we had issues with the code." But we're saying, "We had issues with the system." So, on the retro part is like, "Hey, the agent went over and over hit this problem. Can we fix the system?" That's something you'll learn in the retro. And on the planning side, what I started seeing is that things who were that were sufficiently scoped enough were easy to pick up by agents because they were well-defined and what still was left for the humans were the things that weren't scoped out well.

我在一些比较先进的团队里开始看到这样的现象：他们那些「嘿，我们做 planning、我们团队做 retro」的仪式，聊的不再是「我们的代码出了问题」，而是「我们的系统出了问题」。retro 环节变成了：「嘿，agent 一遍又一遍撞上这个问题，我们能不能把系统修一下？」这是你在 retro 里会学到的东西。而在 planning 这边，我开始看到：那些范围界定得足够清楚的事，agent 很容易接手，因为它们定义得很明确；而留给人的，恰恰是那些范围还没划清楚的东西。

[7:51] Patrick

So, we were like a split in the planning where we said, "These things can straight go into agents, well-defined, and the harness is getting better, and this is conversational things that we need to decide as a team." And what I find important is you there's a certain kind of cycle that developers go through. Yes, they learn first about prompting, they get better, specs, context, harness loop. Also, the industry is learning like that. But, there is the lead of the team can say, "Well, stop prompting. Make the context reusable." Now, we got that. Now, we jump to the next. So, part of the team lead is putting that pace and almost that constraint and that directive in the team where it is doesn't work where you just say, "Go figure it out and do something on your own."

所以 planning 就出现了一种分流：「这些事可以直接丢给 agent，定义清楚了，harness 也在变好；而这些是需要我们团队讨论着定下来的事。」我觉得重要的一点是，开发者会经历某种周期：没错，他们先学会写 prompt，然后越来越好，再到 spec、context、harness、loop。整个行业也在这么学。但团队负责人可以说：「好了，别再写 prompt 了，把 context 做成可复用的。」这个搞定了，再跳到下一步。所以团队负责人的一部分工作，就是在团队里定节奏，几乎是施加一种约束、一种指令。如果你只说「你们自己去琢磨、自己搞点什么」，是行不通的。

[8:45] Patrick

And one of the impacts of that is that if you start producing as a team more, the people downstream, GTM, people like that, they have a hard time keeping up. Even users have a hard time keeping up. So, you need to help them also with automation. So, your harness doesn't stop at your coding. It also is extended to those people as well. And the same thing with kind of requiring uh like gathering requirements, the input might not come fast enough for your team. So, that's another kind of piece that you need to tap into that workflow as well. There's a lot of metrics that people are saying like, "Hey, is your like tokens spend and all that stuff?" I started to believe in these two metrics kind of see on how to be more productive.

这带来的一个影响是：如果你们团队的产出变多了，下游的人——GTM 那些人——就跟不上了。连用户都跟不上。所以你也得用自动化来帮他们。你的 harness 不能止步于写代码，还得延伸到这些人身上。需求收集也是一样，输入可能跟不上你们团队的速度。所以这是另一块你需要接进那条工作流的地方。现在很多人在谈各种指标，比如「你的 token 花了多少」之类的。我开始相信这两个指标，来看怎样才能更高产。

[9:37] Patrick

One is you start measuring how many human touches you still do to have the agent do the right thing. That's supposed to go down the better your harness is, the better your context is, the better your guidelines are. And on the other hand, if you're going from solo to shared system, that becomes a multiplier. You fix something once, everybody gets the benefit. This is not the multiplier from the one person becoming the 10x person, but the one change that optimized the agents has an impact on all the people. So, that is kind of the part that we're all You can start that in a team working together within your repo, sharing the context, working on a harness. But what you basically want to do is you want to scale this out.

第一个：你开始衡量，为了让 agent 把事做对，你还需要人工介入多少次。你的 harness 越好、context 越好、指南越好，这个数字就应该往下降。另一方面，如果你从单打独斗走向共享系统，它就变成了一个乘数。你修一次，所有人都受益。这不是「一个人变成 10 倍工程师」那种乘数，而是一次针对 agent 的优化，会影响到所有人。所以这就是我们大家……你可以先在团队里做起来，在你们的 repo 里一起干，共享 context，一起做 harness。但你真正想做的，是把它规模化推出去。

[10:28] Patrick

So, you come into the realm of the platform people, right? Because they're the typical shared organization working on this. Now, the platform people, they might not be paying close attention because they're like infrastructure and cloud and working on like MCP gateway and stuff like that. But there's new things like bubbling up there. They need to think about like maybe skill registries or eval systems for your context and guardrails specifically for coding agents and identities and stuff. So, they need maybe a little bit of a hand kind of growing to that role. And that kind of central role, it's hard.

于是你就进入了平台团队的领地，对吧？因为他们就是典型的做共享基础设施的组织。不过平台团队可能没太关注这块，因为他们忙着搞基础设施、搞云、搞 MCP gateway 之类的东西。但那里正冒出一些新东西。他们得考虑的可能是 skill 注册中心、针对 context 的 eval 系统、专门给 coding agent 用的 guardrail、身份管理这些。所以他们可能需要别人搭把手，才能成长到那个角色。而这种中心化的角色，很难做。

[11:10] Patrick

You need an owner to drive that program, but is it the platform team? Is it developer experience team? They don't typically own any of those pieces of the infrastructure and the other people don't really do the development. So, there's somewhere a blend, but you need to kind of make sure that there's an owner driving this centralized piece and not just within your team. Because you won't have paved roads. And that's how I see it. Reusable context across teams. Why are we all inventing how we do the authentication system? Right? This is a shared component. Let's put it in the registry. Why are you building all your harnesses?

你需要一个 owner 来推动这个项目，但该是平台团队吗？还是开发者体验团队？前者通常不负责这些基础设施件，后者又不真正做开发。所以是某种混合，但你得确保有一个 owner 在推动这个中心化的部分，而不只是在你自己团队里搞。因为不然你就没有「铺好的路」（paved road）。我是这么看的：跨团队可复用的 context。为什么我们每个人都在重新发明怎么做认证系统？对吧？这是个共享组件，放进注册中心。你们为什么各自都在造 harness？

[11:50] Patrick

Well, if we're all using the same linters and the same security tools, that's a reusable component. So, I think that will centralize similar to the paved path for cloud into that platform registry of reuse. But, if everybody can put stuff like on the internet in a repo, it becomes a sprawl. And it becomes a thing like, well, he has a skill, he's maintaining it. That person is also has a similar skill and forked it. Now, what I do? Like, which one do I pick? So, there is a kind of thing that you say, there's an owner for this area. And they also care about making it testable. They make sure that it's modular, that other people can extend kind of the context, for example, or the harness, that it's security scanned. So, you build kind of a more centralized and the fact that it's secured and kind of maintained as something instead of just something I share around in my organization.

如果我们用的都是同一套 linter、同一套安全工具，那就是可复用组件。所以我觉得这会走向中心化，就像云的 paved path 一样，沉淀进平台的复用注册中心。但如果谁都可以往 repo 里随便扔东西，就像往互联网上扔一样，那就会失控蔓延。变成这种情况：这个人有个 skill，他在维护；那个人也有个类似的 skill，fork 了一份。那我怎么办？该选哪个？所以你得定一条：这个领域有一个 owner。他们还要关心可测试性，保证模块化，让别人能扩展 context 或 harness，保证做过安全扫描。这样你建起来的是一个更中心化的东西，它是受保护、有人维护的，而不只是「我在组织里随手分享的一个东西」。

[12:52] Patrick

Now, that consensus is hard. I'm not saying this is tabs versus spaces, but at times it feels like that. If you have two developer teams having to have consensus on the how the way they work, that requires a lot of communication and brokerage. So, you probably don't end up with one thing, but a catalog of three, four paved roads where they can pick off. And they can still do their own, but that's on their own budget. Right? The centralized pieces will be maintained, and that is supposed to be the easy way of adoption to go there. Now, if they do this blindly, we also want to make sure that they know what it costs.

不过，达成共识很难。我不是说这跟 tab 还是空格之争一样，但有时候感觉确实差不多。要让两个开发团队就工作方式达成共识，需要大量的沟通和斡旋。所以你最后大概不会只剩一套方案，而是一个目录，里面有三四条 paved road 可选。他们仍然可以自己另搞一套，但那得花自己的预算。对吧？中心化的那些件会有人维护，那才是最省事的采用路径。而如果他们盲目地用，我们也得让他们知道这要花多少钱。

[13:33] Patrick

Because if we visualize the cost, they might be eager to do some optimization in there. Right? And that kind of is part of the platform team is making that visible. How much is he spending? How much is that kind of like helping? If I can reduce the number of iterations the agent has to run through, that is an optimization that I can run. But if I don't visualize that and I just see the end result, then we don't know, right? So, that is part of the platform team helping people. And so, what I'm arguing is that we should somewhere move from the solo developer to the team shared kind of context and pieces to a multiplayer system in the organization. And I think that's where the multiplication effect will happen.

因为一旦把成本可视化，他们可能就有动力去做些优化了，对吧？让成本可见，就是平台团队工作的一部分。他花了多少？这些又带来了多少帮助？如果我能减少 agent 要跑的迭代次数，这就是我能做的一项优化。但如果我不把它可视化，只看最终结果，那我们就不知道，对吧？所以这是平台团队帮大家的一部分。我想论证的是：我们应该从单人开发者，走向团队共享的 context 和组件，再走向组织里的多人协作系统。我认为倍增效应会在那里发生。

[14:17] Patrick

Right? Because you're have this flywheel of improvements that go into multiple directions. Now, one layer higher, the VP of Engineering says, "How do I enable the organization?" Right? And that is that I you know, I can predict the story in your organization. Hackathon, a lunch and learn, let's share the successes, have a shared Slack channel, have a champions program. That's all generic transformation. It could have been Agile that transformed like that. It could have been DevOps. It doesn't matter. And on the other side, we know that the strategy of just, you know, give life to something and educate people, do something, let a thousand flowers bloom, it doesn't work. So, what I'm advocating is that the kind of on the organizational is that you give the team leads and the platform that mandate to start doing that work. And it's not the solo developer piece.

对吧？因为你会有一个改进的飞轮，往多个方向同时转。再往上一层，工程 VP 会问：「我怎么让整个组织用起来？」对吧？这个故事我都能替你们公司预测出来：办 hackathon、搞 lunch and learn、分享成功案例、建一个共享 Slack 频道、搞一个 champions 计划。这些全是通用的转型套路，换成 Agile 转型也是这么干，换成 DevOps 也一样，没区别。而另一方面我们也知道，那种「把东西扔出去、给大家做做培训、随便搞点什么、让一千朵花自己开」的策略，根本行不通。所以我在组织层面主张的是：你得把这个授权给到团队负责人和平台团队，让他们去做这件事。这不是单个开发者的活。

[15:15] Patrick

Now, finding people that help you externally is is mess. Yes, we have all the titles, the new job titles, AI product engineer, forward deployed engineer, you know, there was a whole talk on this, agentic engineer, AI engineer. It doesn't mean anything. You cannot judge whether what the kind of the maturity of this because nobody's really that mature. But it's a signal when you put a job posting out there that people might with the new intention will be looking there. But it's not a validation of the skills as such, right? So that is challenging for people um kind of hiring people. Now, they come to the interview and I heard stories about uh people using AI to reflect uh in their ears be response to the interview person and stuff like that.

再说从外部找人帮你，这件事一团糟。是的，我们有各种头衔、各种新职位名：AI 产品工程师、forward deployed engineer（前线部署工程师）——之前还有整场演讲专门讲这个——agentic engineer、AI engineer。这些名字其实不说明任何东西。你没法靠它判断一个人的成熟度，因为说实话没人真的有多成熟。不过它确实是个信号：你把这样的招聘启事发出去，那些带着新意图的人会往这边看。但它本身并不是对技能的验证，对吧？所以对招人的人来说这挺有挑战。然后到了面试环节，我还听说有人用 AI 在耳机里实时给自己提词，回答面试官的问题，诸如此类的事。

[16:10] Patrick

I think what what I hear from most companies is they say first step is we give them an exercise and we want them to really go nuts on the AI to solve this. You know, if they have help from AI, that's all good. That shows you kind of like how much they can kind of leverage the AI to do this. Now, after they pass this, you do a walk-through and you actually say, "Please explain me what happened. Why is this a good idea?" That's where you are testing the taste and the engineering skills on why they're doing this. First part AI, then engineering. And this third thing is how do you collaborate? Are you willing to share?

我从大多数公司听到的做法是这样：第一步，给候选人一道题，希望他们放开手脚、拼命用 AI 去解决它。有 AI 帮忙完全没问题，这能看出他们到底能把 AI 用到什么程度。等这一关过了，再做一次 walk-through，直接说：「请给我解释一下刚才发生了什么，为什么这是个好主意？」这一步考的是品味和工程功底——他们为什么这么做。先考 AI，再考工程。第三件事是：你怎么协作？你愿不愿意分享？

[16:52] Patrick

Are you open or are you a solo player? That's another signal that you tap into. Right? But that fits into that whole thing of like making it shareable, making it reusable, making it engineering grade within our organization. Those are the people that you look for, not people who studied ML or AI, not people who are like experts per se at the coding. There's a blend on this. Now, you might not find a person who has all three, which is okay, but at least you know, like, hey, they're very savvy on this piece, but then for the other piece, they need mentoring and they need tutoring. But, like, don't put all the three pieces into one kind of saying like they're junior or they're senior. They have like different skills on there.

你是开放的，还是个独行侠？这是另一个可以去探的信号。对吧？而这恰好对应我们前面说的那一整套：在组织内部把东西做成可分享、可复用、工程级的。你要找的是这样的人，不是学过 ML 或 AI 的人，也不是所谓的编码专家。这是一个混合的要求。当然，你可能找不到三项全能的人，这没关系，但至少你知道：嘿，这个人在这一块很强，另一块需要带一带、教一教。别把三项能力揉成一个笼统的「他是初级还是高级」的标签，他们在不同方面的技能是不一样的。

[17:36] Patrick

Now, the VP of Engineering has to defend this and they would uh have to make the case, right? Well, we have X amount of licenses that we sold. We have faster delivery, maybe they they can promise, but hard to prove. We have quality that improved, again, hard to say. But, similar to what I said with the metrics of how effective are your agents, you can show that how much turns and how much improvement that you're making on that journey. And same thing, how much there is reuse. So, it's an easier way to kind of show metrics than comparing productivity with and without agent decoding that help you in kind of those discussions as well.

接下来，工程 VP 得为这事辩护，得拿出理由来，对吧？「我们买了 X 个 license。」「交付更快了」——这个他们也许能承诺，但很难证明。「质量提升了」——同样，很难说清。但是，就像我前面讲 agent 有效性指标时说的，你可以展示在这条路上你减少了多少轮次、做了多少改进。同样地，还可以展示复用了多少。这样给指标，比拿「有 agent 编码和没有 agent 编码的生产力对比」来说事要容易得多，也能在这类讨论里帮上忙。

[18:24] Patrick

And so, when people say, uh the vendors are charging completely nuts, so we're going to limit the spends, you shouldn't say like, let's limit all the spends. Your reflection should be, let's optimize the spend and help them kind of reduce that uh in a good way, where that's as simple as saying, pick the right model, educate them on the model, but also on like giving them better context and harnesses because that will make your cost go down there as well. The debate around smaller and bigger teams, yes, it's nice to have like one person who can do it all. That's the ultimate dream. They can do everything.

所以，当有人说「供应商收费简直疯了，我们得限制开支」，你不该说「那就把所有开支都卡死」。你的反应应该是：我们来优化开支，帮大家用合理的方式把成本降下来。这可以简单到：选对模型、教大家怎么选模型，同时也给他们更好的上下文和 harness，因为那同样会让成本降下来。关于团队该小还是该大的争论——是的，有一个人能包揽一切当然很美，那是终极梦想，什么都能干。

[19:04] Patrick

Typically, they're paired with a complementary skill, maybe PM, design, and so on. Okay, then we need a backup if one of them is on holiday so that amounts back to three. And then maybe somebody has to care about production and tickets coming in. Could be the same people if you're really productive, but yeah, you know, you lose speed of features if you're still doing bugs and that depends a little bit on your quality. And then there's the junior you want to get on the road as well to kind of make sure they're still learning what good looks like in one of those three areas. So, I think we're still limited in the way in an organization that we're not going to each team being a solo or one or two.

通常这种人会搭配一个互补的角色，比如 PM、设计之类。好，然后万一其中一个人休假，得有人顶上，那就又回到三个人了。然后可能还得有人盯生产环境、处理进来的工单。如果你效率真的很高，这些可以是同一批人，但你知道，只要你还在修 bug，功能开发的速度就会掉，这多少取决于你的质量水平。再然后，你还想带个初级工程师上路，确保他在这三个领域里至少有一块还在持续学习「好是什么样子」。所以我觉得，在一个组织里我们仍然受这些限制，不可能做到每个团队只有一两个人。

[19:46] Patrick

Yes, a lot of experience, but I think that is the thing. Now, we keep investing in actually education for that piece as well. So, one of the final things is the dark factory, which is probably a dim factory. You have to see what risk you're willing to take for what features. So, not all features will become autonomous, but you can invest more in auditing like problems, like who changed the code, verifiers that kind of check whether that code was useful and when it fails, you invest in situational awareness as well. So, there's a whole spectrum from being a micro manager to being on a autonomous approval that everything kind of is correct, but you make the decision on what your risk level is.

是的，经验很重要，但我觉得关键就在这。所以我们也持续在教育这一块上投入。最后几点之一是「黑灯工厂」（dark factory）——恐怕更准确地说是「昏灯工厂」。你得看清楚，你愿意为哪些功能承担多大的风险。并不是所有功能都会变成全自主的，但你可以在审计方面加大投入，比如：谁改了代码；用验证器（verifier）检查这段代码是不是有用的；当它失败时，你也要投入建设态势感知。所以这是一个完整的光谱：从事无巨细的微观管理，到「自动审批、默认一切正确」的全自主模式，而你要自己决定自己的风险水平在哪。

[20:29] Patrick

And I think your mode is capturing the knowledge. Right? The knowledge you're putting now into skills, you're in your context, and maybe in your harness, the way you kind of restrain this, your business context. And for me, that kind of brings continuous delivery actually to continuous learning. And if you ask the question of how fast can we swap in swap out something new, that's your reactive mode. And if you can improve that ultimately, it's not about making the whole system more reliable, but can I keep it reliable while changing more of the system. I'm working on a website that kind of where I try to list some of the agent enablement patterns that I described. I couldn't list them all within this time.

我认为你的工作模式就是把知识沉淀下来。对吧？你现在把知识放进 skills、放进上下文，也可能放进 harness——也就是你约束它的方式、你的业务上下文。对我来说，这就把持续交付（continuous delivery）真正推进到了持续学习（continuous learning）。如果你问「我们能多快把一个新东西换进来、换出去」，那就是你的响应模式。而如果你能在这上面持续改进，最终要的不是让整个系统更可靠，而是：我能不能在改动系统越来越多的同时，还保持它的可靠？我正在做一个网站，试着把我刚才讲的那些 agent 赋能模式列出来。这点时间里没法全部讲完。

[21:16] Patrick

Tell me what you're missing. I'm trying to source social kind of stories. So, if you have a story of how things are going in your organization, please tell me and I am happy to put on a link in there as well. And if you're interested in kind of the slides, happy to share those. And I think if there's one takeaway, it's not the solo player that will win the game. It's kind of like at the different levels how we improve our organizations. Thank you very very much for listening and I hope it was useful.

告诉我你们还缺什么。我也在征集大家的真实故事。如果你有自己组织里事情进展如何的故事，请告诉我，我很乐意在网站上放上链接。如果你们对幻灯片感兴趣，我也很乐意分享。如果只留一个要点，那就是：赢下这局的不会是独行侠，而是我们在各个层级上如何改进自己的组织。非常非常感谢大家的聆听，希望对你们有用。

[21:48]

[applause]

（掌声）