Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.

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

[0:12]

Thank you so much for coming later in the week here. Uh I'm Matt. I'm the CEO and founder of Ref. The problem we work on at Ref is one you might be familiar with where individual engineers are going really fast with AI, but the team as a whole is not. And we're working to help close that gap. What I'm going to be talking about today is that is what happens when your whole team gets 10 times faster. All the things that don't go well. And my goal is to give you a blueprint for how to get get through those issues. Uh and have the whole team move faster together. The way I want to accomplish that is first talk about those issues, define some terms. Then we'll talk about how did we get here? Where are we at now? Um and we'll use that to triangulate on some solutions. We'll start high level and we'll work down to get more and more practical until we leave with a couple of things you can leave here and do immediately. Um how's that sound? I need thumbs up. All right, awesome. Great, that was great. Uh All right, so let's get into it. These are some of the problems you might be experiencing right now. Uh these are these are problems that affect individuals and are actually magnified at the team level once the entire team starts experiencing them.

非常感谢大家在大会快收尾的时候还愿意过来。我是 Matt，Ref. 的 CEO 兼创始人。我们在 Ref. 解决的问题，你们大概都不陌生：有了 AI，工程师个人跑得飞快，但团队整体并没有变快。我们要做的就是把这中间的落差补上。今天我要讲的，就是当你整个团队都快了 10 倍之后会发生什么——那些不顺的事儿。我的目标是给你一套蓝图，帮你穿过这些坑，让整个团队一起提速。具体怎么讲：先把这些问题摆出来，定义几个词；然后聊聊我们是怎么走到今天的、现在又站在哪儿；再拿这些来三角定位出一些解法。我们从高处起步，一层层往下落，越来越具体，最后你能带走几条马上就能用的做法。这个安排还行吧？来，给我个大拇指。好嘞，太棒了。刚才那波很给力。好，那我们开始。下面这些，是你现在可能正在经历的问题。它们本来是个人层面的毛病，但一旦整个团队都染上，就会被成倍放大。

[1:34]

The first one, too many PRs to merge. This is the like classic first problem you hit when you start adopting AI as an engineer. You're like, "Great, I'm shipping stuff." And you push up those PRs and you're like, "There's no way I can merge all these." Uh and this is obviously magnified when the whole team does this. Merge conflicts, merge queue breaks down, things get bad. The second problem is that you're moving in many directions at once. This is also both individual and a team problem. Individually, this is where you have a bunch of agents doing different things. You're trying to remember who's doing what and your brain gets fried. At the organizational level, this is your engineers picking up things and running in a certain direction. Another engineer is running over here. Maybe some are bumping into each other and you're you're not moving cohesively with focus because you're just sprinting in all sorts of directions. The third problem you might be experiencing is declaring agent bankruptcy. This is a a common pattern I see engineers get into where you know, you're cranking. You have like your 12 terminals open. You're like at the end of the day you're like, "Yeah, I did a lot of work." You step away from your laptop.

第一个，PR 多到根本合不完。这是工程师开始用 AI 之后撞上的最经典的第一个坑。你会觉得「太好了，我在疯狂出活」，然后把这一堆 PR 全推上去，接着发现：这些我根本合不完。整个团队都这么干的时候，问题当然会被放大——merge conflict 一堆，merge queue 直接崩掉，局面很难看。第二个问题是，你同时在往一大堆方向跑。这同样既是个人问题也是团队问题。个人层面，就是你手上一堆 agent 各干各的，你努力记住谁在干什么，脑子直接烧掉。组织层面，就是这个工程师捡起一件事往这个方向冲，另一个工程师在那边冲，说不定还撞到一起，团队没有聚焦地拧成一股劲，而是朝四面八方各自狂奔。第三个你可能正在经历的问题，叫「宣布 agent 破产」。这是我在工程师身上看到的一个很常见的模式：你正干得起劲，同时开着 12 个终端，一天结束的时候心想「嗯，今天干了不少活」，然后合上电脑走人。

[2:40]

Uh spend time with your friends and family. Next morning you come back and it's like walking into just a room of strangers. Like, who are these people? What are they doing here? But like no problem. They're agents so you just like get rid of them and start over again. The problem though is you know, it feels like you're doing a lot of work but you're doing the same work and you're spending tokens twice. You're doing the same problems over over again. And if you think about that organizationally, that's your team not being efficient with both their time and their their token resources. Problem four though is actually the most important one. It's critical decisions being made by agents. Once you have agents doing a lot of your work, if if you as an engineer are letting an agent make a critical decision, you are seeding control of your code. You are no longer the owner of that code. The agent is. And if you imagine that at scale at your company, if the engineers across your team are you know, giving up ownership of the code, you no longer own the product. These are a bunch of problems you might be experiencing at different degrees at different days. Uh The way I like bundle it up is into this term velocity sickness.

去陪陪朋友和家人。第二天早上回来，那感觉就像走进一屋子陌生人：这些人是谁？他们在这儿干嘛？不过没关系嘛，反正是 agent，你就把它们全清掉，从头再来一遍。但问题在于，你感觉自己干了很多活，可干的是同样的活，token 花了两遍，同样的问题反复做。放到组织层面看，就是你的团队在时间和 token 资源上都很不划算。不过第四个问题才是最要命的：关键决策是 agent 做的。当 agent 替你干了大量的活，作为工程师，如果你让 agent 去做一个关键决策，你就是在交出代码的控制权。这段代码的主人不再是你，而是那个 agent。放大到整个公司想一想：如果团队里的工程师都在放弃对代码的所有权，那这个产品就不再是你的了。上面这些问题，你可能在不同的日子、以不同的程度经历过。我习惯把它们打包成一个词——速度病（velocity sickness）。

[3:56]

This is uh the stress caused by sudden output increases thanks to AI. Um it affects individuals or teams. Um and the result is output without impact. So, this is that feeling of like we're moving really fast. This should feel great. This should feel awesome, but for some reason it doesn't feel awesome. We're not having the like the things you expect to be happening are not happening. Um despite this feeling of being so productive. So, that's to define that term, but I want to tell uh a little story. Uh my talk is happening now. Uh I want to tell a little story about somebody like to make this very real. Um This is a story about somebody uh who's actually not an engineer, but I think it parallels our engineering workflows a lot. I Part of my job is I get to go, find, and talk to people who are really pushing the forefront and try and learn from them. And I love that part of it. And so, this is somebody and I'm I'm talking through their identical workflows. Um and this is somebody who writes a newsletter, and their workflow is around how do I I have my ideas and then they're doing research and exploration and then uh like cohesion between those ideas and editorial to make sure it's in their voice. And they're they're walking me through their system for how they they manage this whole pipeline um and really scale out their their efficacy. And this is like very very much not slop. This is somebody who has is using agents to amplify their own voice uh in a way that's like very impressive. I'm like, "Wow, that's that is so cool. I'm I'm like I'm soaking it in." Uh And then they're like, "Yeah, I'm basically writing a book every week."

速度病指的是：AI 让产出突然暴增所带来的那种压力。它既会发生在个人身上，也会发生在团队身上。结果就是——有产出，没影响力。就是那种感觉：我们跑得飞快，这本该爽的，本该很棒，可不知道为什么就是不爽。你以为会随之发生的那些事，并没有发生，哪怕你自我感觉高产得不行。这就是这个词的定义。不过我想讲个小故事，把它讲得更实在一点。故事的主角其实不是工程师，但我觉得他的工作流跟我们做工程的高度相似。我工作的一部分，就是去找那些真正走在最前沿的人聊，向他们学习，我特别喜欢这部分。所以我当时正在跟这个人过他的整套工作流。他是写 newsletter 的，流程大概是：先有想法，然后做调研和探索，再把这些想法揉到一起、做编辑加工，确保成品是他自己的腔调。他一步步给我讲他怎么管理这整条 pipeline、怎么把自己的产能放大。这完全不是那种粗制滥造的 AI 垃圾，而是一个人用 agent 去放大自己的声音，做得非常漂亮。我当时就想，哇，这也太酷了，我听得津津有味。然后他来了一句：「所以我基本上每周写一本书。」

[5:39]

And I'm like, "Oh, okay. Is like is your audience reading a book every week?" And they're like, "No, they're probably not." Right? They're not. They're they're This is a person who's writing a lot, but those pages that they're writing are going unread. Um I think that's part of this experience of velocity sickness is we're we're building things that are not mattering for the people we want them to matter for, the people we're trying to reach. Uh So, what we Instead of unread pages, um what we want is we want to write words that matter. We want to write words that connect with people. Um and the parallel to us as like software builders and product builders is is that we want to write we want to build products that connect with people. We want We want to build products that change the way people live and work and make their lives better. And we have more ability to do that than ever with AI. But we have this like feeling of velocity sickness where we're It feels like we should be doing that, but it's not quite landing. So, let's talk about how we got here. Um This is what the software engineering process used to look like before AI. We'd do some planning up front. We'd sit down and build. We'd implement.

我说：「哦，是吗。那你的读者每周读一本书吗？」他说：「大概不会吧。」对，不会。这是一个写了非常多东西的人，但他写出来的那些页，没人读。我觉得这正是速度病体验的一部分：我们造出来的东西，对我们想影响的那群人来说，其实无关紧要、根本没触达。所以，比起一堆没人读的页，我们真正想要的是写出有分量的字，写出能跟人产生连接的字。对应到我们这些做软件、做产品的人身上，就是我们想做出能跟人产生连接的产品，想做出能改变人们生活方式和工作方式、让他们的日子变好的产品。有了 AI，我们比以往任何时候都更有能力做到这件事。可我们偏偏染上了这种速度病——感觉本该做到了，却总差那么一口气没落地。那我们就来看看，是怎么走到这一步的。这是 AI 之前的软件工程流程长的样子：先做一些前期规划，然后坐下来开干、把东西实现出来。

[6:47]

It'd be It'd be iterative. We'd be exploring. But largely we're sitting down building in isolation, implementing something. And at the end we sort of polish it up and ship it out the door. And this was great. We all knew how to do this. We had a lot of systems for this. Uh And it was good. And then AI came along. Um But at this time our our tools were built for this. Like all all our history of coding tools were built for this style of work. Um our IDE, our workhorse, um it was built for implementation and polish to be done by an individual, to be heads down building as a software engineer writing code. Um That's what That's a tool built for how we used to work. Um so, let's look at how how we work now. Our work looks a lot more like this. Where you do some planning up front. You start thinking about what am I trying to do here? You take this idea in your head and start to flesh it out. Um At some point an agent takes that idea and like implements it. This is like arguably should not even be on this slide cuz it's not our human work anymore. It's done by the agent. Um and then in the end we do some polishing where we take back that thing the agent has made for us and we like hold it in our hands and we say, is this is this what I wanted? Um This is a very different shape of work.

这个过程是迭代的，我们会一边做一边探索。但基本上就是坐下来、一个人闷头写，把东西实现出来。最后再打磨一下，发布出去。这套挺好的，我们都会这么干，也围绕它建了一大堆体系。挺不错。然后 AI 来了。可问题是，我们当时的工具都是为前面那套流程造的。我们整部编码工具的历史，都是为那种工作方式造的。IDE，我们的主力工具，是为「实现」和「打磨」造的，是为一个人埋头写代码造的。那是为我们过去的工作方式造的工具。那再看看我们现在是怎么工作的。现在的工作更像这样：先做一些前期规划，你开始想我到底要干什么，把脑子里的想法一点点铺开。到某个点上，agent 接过这个想法，把它实现出来。严格说这一步都不该出现在这张幻灯片上，因为它已经不是人的活了，是 agent 干的。然后到最后我们做一些打磨——把 agent 做出来的东西接回手里，掂量一下：这是我想要的吗？这是一个形状完全不同的工作。

[8:02]

Right? We're no longer doing this like heads down building. These are the two uh creative and collaborative parts of our work as engineers. This is where we like express our craft as an engineer. And the one that's most different is the the planning stage. So, I want to zoom in on that just a little bit. Uh that's the like exploratory, creative, collaborative part where we're we're thinking about like I have this vague idea. I have this complex system. I need to understand the contours of this system, apply this idea, and like really understand it. And I need to pull out what's relevant and express my taste as an engineer. As to like, where do I want this system to go? Um This is the kind of work that uh that's creative and and needs to be done together. I think the the shape of engineering teams and product teams is changing with AI. But we're always going to have this thing where we have a group of people responsible for managing a complex system and it's sort of deciding the future of that system. And that's this planning work. And so, we're we're starting to see some of the hints of like, okay, we had tools built for a certain type of work. Our work looks different now. Um Let's start to see think about that a little bit more.

对吧？我们不再是那种埋头猛干的模式了。剩下的这两块，是我们作为工程师最有创造性、最需要协作的部分，是我们施展工程手艺的地方。而变化最大的，是规划那一段。所以我想把这块稍微放大看看。这是最偏探索、最有创造性、最需要协作的部分：我脑子里有一个模糊的想法，面前是一个复杂系统，我得摸清这个系统的轮廓，把想法套上去，真正把它吃透。我得从里面挑出真正相关的东西，然后作为工程师亮出自己的品味——我想让这个系统往哪儿走。这类工作天生是创造性的，也天生需要一群人一起做。我认为在 AI 之下，工程团队和产品团队的形态正在改变，但有一件事永远不会变：总会有一群人负责管理一个复杂系统，并决定这个系统的未来。那就是规划这块活。所以我们已经隐约看出苗头了：我们的工具是为某一类工作造的，而现在的工作已经变了样。我们再往深里想一想。

[9:14]

So, uh we used to have the IDE as our main tool. It was used for implementation. But now we're doing this different kind of work. So, at the very high level, we can start to think about solutions like, okay, we have a tool built for this type of work. We have a new type of work. Let's think about you know, what this new layer of our work is. This This is the decision layer. This is where we're thinking through what are the key decisions, doing that like craft of engineering, um and expressing our taste as engineers, ultimately a different thing than implementation. And it it's a different gear as an engineer. The skill now is what gear am I in? Am I using the appropriate tools for the gear that I'm what I'm trying to accomplish right now. So let's think about what a tool built for the decision layer would look like. It'd be a tool built for docs and not chat. And there's that's like a short sentence. There's a lot to unpack here though. So I'm going to spend a lot of time on this slide. The problem with chats is that they are the relic of building for implementation. So they're they're default isolated and ephemeral and and brain off. They're they're made to build things and get stuff done. And that's not really the same type of work we're doing at the decision layer. We're doing this creative exploratory work. So being in this isolated environment where I'm working with an agent, maybe I start with my vague idea and I'm exploring it and asking questions, but decisions are being made in that like that chat that are are not shared with my team that are going to disappear as as long I'm going to result in some code being output where those important decisions are not being made clear and shared with the team. And you're also in this mode where the agent saying Okay, this is what I want to do. Is is that okay? Let's go. Or or sometimes it'll say it'll ask you a question and it'll be like you know, this is the recommended option

过去我们的主力工具是 IDE，它是用来做实现的。但现在我们干的是另一种活。所以站在很高的层面上，我们可以开始想解法了：工具是为那类工作造的，而我们有了新类型的工作，那就来想想这层新的工作到底是什么。这就是决策层（decision layer）。在这一层，我们思考哪些是关键决策，施展工程的手艺，亮出作为工程师的品味——它跟「实现」完全是两回事，是工程师身上的另一个挡位。今天真正的能力是：我现在挂在哪个挡上？我用的工具，跟我此刻想完成的这个挡位匹配吗？那我们来想想，一个为决策层造的工具会长什么样。它会是围绕文档、而不是围绕聊天造的工具。这句话很短，但里面有很多东西要拆，所以这张片我要多讲一会儿。聊天的问题在于，它是「为实现而造」那个时代的遗留物。聊天默认是孤立的、用完即弃的，而且是不用动脑的——它是拿来把事情做出来、做完的。这跟我们在决策层干的活根本不是一回事。我们在这一层做的是创造性的、探索性的工作。可你现在待在一个孤立的环境里，跟一个 agent 一起干，可能带着一个模糊的想法开始探索、开始提问，但那些决策就在那个聊天里被做掉了——没有跟团队共享，回头就消失了，最后只落下一堆代码，而那些重要的决策从来没被讲清楚、也没被同步给团队。而且你还会陷进这么一种模式：agent 说「我打算这么干，行吗？走起。」，或者有时候它会问你一个问题，然后加一句「这是推荐选项」，

[11:06]

and then you're like, great. I don't even think about this. I'll just hit that one and we keep going. Docs start to solve this problem. So when you're if you center your work around working in docs they're meant to be bring forward the key decisions. This is this is what our work is now. Our work now is figure out what decisions matter and then make those decisions and then get out of the way while the agents fill in the rest. Working in Docs is the the classic way we would create alignment. If you were If you think back to being a manager or a lead on a team before AI, if your team was having struggling with alignment, you would not tell them like, "Let's go all work in Slack DMs. Let's like go direct message each other." You'd say, "Let's like bring forward key decisions, align on them, spend time on these, like find a way that we can really spend time getting our decisions right." So, there are two things you might be thinking looking at this that are not what I'm talking about here. The first one is plan mode. That's a great tool. The other one is like full-on factory spectrum and development. That's a great tool, too. I'm talking about something in the middle. Plan mode is great, but it's largely a a rich chat message where the agent is saying, "Hey, here's a like better visualization of what I'm trying to express to you." Yeah, that's great.

然后你就想，好极了，那我干脆不动脑了，直接点那个，继续往下走。文档能开始解决这个问题。如果你把工作重心放在文档上，文档天生就是用来把关键决策摆到台面上的。而这正是我们现在的活：搞清楚哪些决策真正重要，把这些决策做掉，然后让开路，剩下的交给 agent 去填。用文档来工作，本来就是我们创造对齐的经典方式。回想一下 AI 之前，如果你是团队的 manager 或者 lead，团队对不齐的时候，你不会跟他们说「来，咱们全都去 Slack 私信里干活吧，互相发私信」。你会说「把关键决策摆出来，对齐它们，把时间花在这些上面，想办法真正把决策做对」。看到这儿，你脑子里可能会冒出两样东西，但都不是我要讲的。第一个是 plan mode，那是个好工具。第二个是那种全自动、工厂流水线式的 spec 驱动开发，那也是个好工具。我讲的是夹在中间的那个东西。plan mode 很好，但它本质上还是一条更丰富的聊天消息——agent 在说「嘿，我把想表达给你的东西做了个更好的可视化」。挺好的。

[12:32]

But it's still in this isolated ephemeral environment. And what I'm suggesting is something more more durable, more shared, more long-lived that you and your team are spending time on. Similarly, the spectrum and development where we just define the behaviors, we operate at the like product level, is a little far away from the engineering reality. The engineering reality is that I need to understand my system and have a tool that like helps me understand that system and lay out those key decisions in a in a technical sense. The way I like to conceptualize this is as the portal to the software system, where you are like Tony Stark and you're like, "Show me what matters." And you're like, "I'm working on this. Pull out the bits that are relevant." And AI is amazing at finding things that are related to other things, helping you find what's what's relevant and lay them out on the table in front of you. Organize the pieces in the way you want to represent how you want the system to grow. But the big conceptual flip here is actually that we're pulling out the state. So, when you're living and working in a a long-lived session with an agent, there's this implicit context being built up like over that work, and that's great. Um But there's you're also doing actions and it's it's not shared. What you want is to separate the the agent as the action and the doc as the state. And so, you can spawn new agents that have the same context or starting from the same place that are able to collaborate and work on the same same piece of context and state. You're ultimately doing context engineering in this doc, so that every agent is largely stateless and starts from this place um the same place. And what that gives you is your team and yourself can look into this and understand what actually is in here. What are the decisions that are being made um and have a a clear understanding of what the key decisions are.

但它依然跑在一个隔离的、用完即弃的环境里。而我想说的，是一种更持久、更共享、生命周期更长的东西——值得你和团队真正投入时间去经营的东西。同样地，光谱的另一端，我们只定义行为、只在产品层面上操作，这又离工程现实太远了。工程现实是：我得理解我的系统，我需要一个工具来帮我理解这个系统，并且用技术的语言把那些关键决策摆出来。我喜欢把它想象成「通往软件系统的传送门」——你就像 Tony Stark 一样说：「把重要的东西调出来给我看。」「我在做这一块，把相关的部分抽出来。」而 AI 最擅长的恰恰就是找出事物之间的关联，帮你锁定哪些是相关的，然后把它们摊在你面前的桌上。接着你按自己的想法把这些零件组织起来，表达你希望这个系统怎么生长。但这里最大的观念翻转其实是：我们把「状态」抽离了出来。当你在一个长时间的 session 里跟 agent 一起工作时，会有一层隐性的上下文随着工作慢慢积累起来，这本身是好事。但你同时也在执行各种动作，而这些动作是不共享的。你真正想要的，是把 agent 当作「动作」、把文档当作「状态」，两者分开。这样你就能派生出新的 agent，它们带着同样的上下文、从同一个起点出发，能够协作，能够在同一份上下文和状态上干活。你在这份文档里做的其实就是 context engineering，让每个 agent 基本上都是无状态的，都从同一个地方起步。这带来的好处是：你和你的团队可以打开这份文档，看清里面到底有什么、正在做哪些决策，对关键决策有一个清晰的把握。

[14:23]

So, this is a a different way of working where your your core atom of your work is a doc rather than a chat. Um What happens when you actually start to implement this? Well, the first thing we see happen actually is that people start to plan and then not implement their plan. Uh and this is actually like a really good sign. Because what that means is they're thinking through ideas. They're saying, "I have this idea. Let me explore it. Let me start to flesh it out. Like I have this vague thought. Don't just give me some code. Don't go off and like build it for me, but let me help help me understand the idea that I'm talking about. Um And then they have a bunch of these and then some of them are getting built and some of them aren't. So, that means they're prioritizing the ideas that after they've explored them are the ones that are worth building and and going in this to the next step with. Um One way I like to frame this is that you're you're shifting from code velocity to idea velocity. So, going back to our our problem statement like how are we dealing with velocity sickness? The velocity sickness is we're shipping too much code that's not going anywhere. The solution is to shift that velocity to ideas so that rather than you know, getting stuck in prototype gravity where we we build something and we're so excited to just ship that thing and we're going down like one path of the idea maze, we can now like more more effectively explore that whole maze and find that gold that's around the corner.

所以这是一种不同的工作方式：你工作的基本单元是一份文档，而不是一段对话。那真正落地之后会发生什么？我们看到的第一件事是，人们开始做计划，然后并不去实现这个计划。这其实是个非常好的信号。因为这意味着他们在把想法想透：「我有个想法，让我先探索一下，把它铺开。我脑子里只有个模糊的念头，别急着给我代码，别自己跑去把它建出来，先帮我把我说的这个想法搞明白。」然后他们攒了一堆这样的想法，其中一些被建出来了，另一些没有。这说明他们在做优先级取舍——探索完之后，挑出真正值得建、值得往下一步推进的那些。我喜欢这么形容：你从 code velocity 转向了 idea velocity，从「代码的速度」转向「想法的速度」。回到我们最开始的问题：怎么应对速度病？速度病就是我们发了一大堆最后哪儿也没去成的代码。解法是把这份 velocity 转移到想法上——不再困在「原型引力」里：建了个东西，兴奋得只想赶紧把它发出去，一头扎进想法迷宫的某一条岔路；现在我们可以更高效地把整座迷宫探完，找到拐角后面的那块金子。

[15:48]

Um and and really impact the people we're trying to help. Um So, let's go back. Here are those problems, those velocity sickness problems I talked about the beginning. Let's see how this starts to address those. First, too many PRs. We've moved the the review point earlier into the process. So, we're aligning on the key decisions up front. That means the code review is easier because the hardest part of any code review is, you know, what actually matters here. That's the first step is like, "Hmm, what do I care about here?" If you move that earlier, we've aligned on that, the code review becomes much simpler. Number two, moving in too many directions. Again, we're aligning early as a team and individually, I'm like understanding what I'm working on across many agents. If I'm working on a large thing, I've I've understood it initially. So, as a team, we're sharing these plans and we're aligning. This is what we're trying to build and it's easy before someone has spent even a day in AI going deep on some idea building a prototype, we can talk about it early and make sure we're aligned on where we actually taking the system. Um declaring agent bankruptcy is just not a thing because you've made your agent stateless. So, the result of their work is in the stock. If you need to rebuild your human context, you just read the doc. Now, you understand the state of this project and you can pick up from there.

……并且真正影响到我们想帮助的那群人。我们回头看看，这就是我开头讲的那几个速度病的症状，来看这套做法怎么开始解决它们。第一，PR 太多。我们把 review 这个节点往流程更早的地方挪，在关键决策上先对齐。这意味着代码 review 变简单了——因为任何一次代码 review 里最难的部分，就是搞清楚「这里到底什么才是重要的」。第一步永远是：嗯，我该关心什么？把这一步提前、先对齐好，代码 review 就轻松多了。第二，方向发散。同样是提前对齐，团队层面如此，个人层面也是——我能在很多个 agent 之间搞清楚自己到底在做什么。如果我在做一件大事，我一开始就把它理解透了。在团队层面，我们共享这些计划、达成一致：这就是我们要建的东西。而且这很容易做到——在有人花上一整天让 AI 深挖某个想法、做出一个原型之前，我们就能早早聊一聊，确认我们对系统要走向哪里是有共识的。至于「宣布 agent 破产」，这事儿压根就不会发生了，因为你已经把 agent 变成无状态的了，它工作的成果都在文档里。如果你需要重建你自己（人类）那份上下文，读一遍文档就行——你马上就明白这个项目现在是什么状态，从那里接着往下走。

[17:10]

And the most important one, humans own the decisions. Like, that's what we're solving for. Humans need to own the decisions. That's how we retain ownership of our software and our products and make it like a true expression of what we're trying to create in the world. There are also some other benefits. So, when you have this state extracted and you're working from a shared context, you get more parallel agents. It's easier to work with parallel agents. Uh you get this durable decision log. So, something uh that's really powerful. I think a lot of people are thinking about how do we capture all the decisions going into these sessions? A really great solution to that is let's pull out all the decisions up front and agree to them and put them in a place that's durable so that we don't have to have like some LLM summarizing it and maybe picking the wrong things later on. We want to bring that forward so we can save it and refer to it later. Um and then my favorite one um is actually more collaboration. Like this process, we want we're doing more work that is creative, which means we should be collaborating more as engineers. I think the future of engineering is multiplayer. It's going to be multi multiplayer by default sooner than we think.

而最重要的一条是：决策权归人类。这才是我们真正要解决的事。人必须掌握决策权，这样我们才能保住对自己软件和产品的所有权，让它真正成为我们想在这个世界上创造的东西的表达。除此之外还有一些别的好处。当你把状态抽离出来、基于共享的上下文工作时，你能跑更多并行的 agent——跟并行 agent 协作变容易了。你还会得到一份持久的决策日志，这一点非常有价值。我觉得很多人都在琢磨：怎么才能把这些 session 里产生的决策全都记录下来？一个很棒的解法是，干脆把所有决策在一开始就抽出来、达成一致、放进一个持久的地方，这样就不用等着某个 LLM 事后帮你总结、还可能挑错重点。我们要把这件事前置，这样才能存下来、以后随时回看。而我最喜欢的一条，其实是「协作变多了」。在这个流程里，我们做的工作更偏创造性，这就意味着作为工程师我们应该更多地协作。我认为工程的未来是多人模式的，而且它默认变成多人模式的那一天，会比我们以为的来得更早。

[18:25]

Um and it's more important than ever because we're in this moment with AI where everything's moving faster than ever. There's a pressure like everyone's company feels existential, small or big. You need to deliver. And the way we get through that as humans is by working together. And we need tools that help us do that. So, here are three concrete things you can leave this room and do right now. The first one is to think of your work in terms of planning and polish. So, recognizing that there are two gears I'm working in. There's no longer this one focus of implementation. There's uh plan and then polish. Um and notice when you're in a single session and you're doing both of these in one session. Notice when you drift from the planning phase into the polish phase and is your tool serving you for what you're trying to do at that moment? Uh number two is to start to treat your plan as a portal to the software system. So, really treating it as this powerful, malleable tool to say like, what matters to to me for what I'm working on right now? Um and asking it to show that to you so that you can make the best decisions possible. And number three is share a plan. Like, don't just you know, write the plan, give it to your agent, and have them implement it.

这件事比以往任何时候都更重要，因为我们正处在 AI 的这个时刻，一切都跑得前所未有地快。压力无处不在——不管公司大小，每家都觉得这是生死攸关的时刻，你必须交付。而我们作为人类熬过去的方式，就是一起协作。我们需要能帮我们做到这一点的工具。所以，这里有三件具体的事，你今天走出这个房间就能马上开始做。第一，把你的工作分成「规划」和「打磨」两档来看。也就是意识到自己是在两个挡位上工作，不再只有「实现」这一个焦点，而是先规划、再打磨。留意一下：你是不是在同一个 session 里把这两件事一起干了？留意你什么时候从规划阶段滑进了打磨阶段，以及此刻你手上的工具，到底服不服务于你当下想做的那件事。第二，开始把你的计划当成「通往软件系统的传送门」。真正把它当作一个强大、可塑的工具来用：对我眼下做的这件事来说，什么才是重要的？让它把这些东西呈现出来给你看，好让你做出尽可能好的决策。第三，把计划分享出去。别只是写完计划、丢给你的 agent、让它去实现就完了。

[19:40]

Give it to someone on your team. This is like, I feel like very unnatural for a lot of people. We always we we think we know what's going on. But, it's always valuable. You have smart teammates. They have great context in their heads. You should tap into that. They will give you good feedback. Uh it's a really valuable thing to do. That's my talk. I'm Matt. Um I'm the CEO of Ref. If you want to talk about any of this stuff, this has all my like connection information. Ref is a tool built for the decision layer. Uh we work with all of your existing implementation tools. Um if you want to see a demo, come you can come by our booth or just see me out there. Uh and I'd love to talk about this stuff, so come say hi. Thanks.

把它交给团队里的某个人看看。我知道这对很多人来说非常别扭——我们总觉得自己心里有数。但这么做永远是值得的。你有很聪明的队友，他们脑子里有很好的上下文，你应该把这些用起来。他们会给你很好的反馈，这件事真的很有价值。我的分享就到这儿。我是 Matt，Ref 的 CEO。如果你想聊聊这些话题，这上面有我所有的联系方式。Ref 是一个为「决策层」打造的工具，跟你现有的所有实现类工具都能配合。想看 demo 的话，可以来我们展台，或者在外面直接找我。我很乐意聊这些，欢迎来打个招呼。谢谢大家。