AWS 老兵：新的软件开发生命周期

主持人 And this cost me almost 200 million tokens to refactor. And I'm like, "Oh, I need to stop using Opus. This doesn't work." 这次重构几乎花了我 2 亿个 token。我当时想：“哦，我得停止使用 Opus，这样不行。”

嘉宾 This is Haider Lesa, a true AWS veteran who's trained over 8,000 architects, and he shares his blueprint for software engineering with agents. Today, 这位是 Heitor Lessa，一位真正的 AWS 老兵，培训过 8,000 多名架构师；他将分享一套与 agents 协作进行软件工程的蓝图。今天，

主持人 when leadership start questioning, can do I need an engineer plus 5,000 a month just for them to do their work, that math does not add up. Even if they forge an evidence, they forge that they run the test, they try to copy and paste the results from the internet,which they do. How do I make sure that this doesn't happen? 当管理层开始质疑：[音乐] 我是否需要一名工程师，还要每月再花 5,000 美元，才能让他完成工作？这笔账算不通。即使他们伪造证据，谎称自己运行过测试，还试图从网上复制粘贴测试结果，他们确实会这么做。我要怎样确保这种事不会发生？

嘉宾 Agents and how engineering teams work with them. We're doing something we've never done before this episode and by the end of it, you'll want to rebuild your own software engineering workflow. So enjoy. 这一集谈 agents，以及工程团队如何与它们协作。我们将做一件节目过去从未做过的事；听完之后，你会想重建自己的软件工程工作流。请享受这一集。[音乐]

主持人 The size and specifically Dublin and the tech scene has grown quite significantly. 这座城市，尤其是 Dublin 的科技圈，已经显著壮大。

嘉宾 Oh yeah. 是啊。

主持人 Yeah. 对。

嘉宾 Oh yeah. 确实。

主持人 But it must be fun as well kind of the connections you've built up and the relationships there. 不过这一定也很有意思，你在那里建立了很多人脉和关系。

嘉宾 Oh yeah. I think uh you typically have a company where your formative years are typically uh there but then Amazon was especially that the idea of a hyperrowth or the idea of all you need to do is a college or or this Harvard book that you read or something that you you'll figure it out. None of these things worked for Amazon because the growth was just like staggering. 是的。我觉得，人通常会在某一家公司度过职业生涯的成长期；但 Amazon 很特别，它是超高速增长的环境。那种“你只要上过大学”，或者“读过某本 Harvard 商学院的书，就能想明白该怎么做”的观念，在 Amazon 完全行不通，因为增长速度实在太惊人了。

Yeah. I remember um going from like maybe a few hundred people to like 2,000 and 4,000 people like every year and it was like what's going on? How where are we going to end with this? And he was like yeah the growth was minimum 25% year-over-year and I was like 是的，我记得，嗯，公司人数可能从几百人变成 2,000 人、4,000 人，几乎每年都这样。大家会想：到底发生了什么？最后会增长到哪里？他说，年增长率至少是 25%。我当时就觉得… …

主持人 and then the head counsel was like yeah let's double let's triple let's quadruple and I was like 后来总法律顾问说：那就翻一倍、翻三倍、翻四倍。我想，

嘉宾 wow so nothing of this would work. 哇，那以前那些办法都行不通了。

主持人 That's incredible. In the end you stayed there 11 years. What are some of your biggest learnings or in in which role were they? I have too many. Um I think one of the interesting things about Amazon was even though the size AWS specifically was humongous in terms of size, terms of people and processes and so forth, it always felt like a startup in a way. So you could move between roles and between teams and that's some part of the reason I suppose I was there for so long. 太不可思议了。你最终在那里待了 11 年。你最大的收获有哪些？它们分别来自哪些岗位？收获太多了。[笑] 我认为 Amazon 一个很有意思的地方是：尽管 AWS 的规模极其庞大，无论人数、流程还是其他方面都是如此，但它在某种程度上始终像一家 startup。你可以在不同岗位和团队之间流动，我想这也是我在那里待了那么久的部分原因。

Before I joined AWS, I went to a meetup of AWS, but I said I would never join a company like Amazon, never these enterprises. It's like I'm I'm allergic to these things. I just want to get something done, you know? 加入 AWS 之前，我参加过一次 AWS meetup，但我说自己绝不会加入 Amazon 这种公司，绝不会去这种大企业。我好像对这些东西过敏，只想把事情做成，你懂吧？

嘉宾 Here we are. 结果你还是来了。[笑]

主持人 And I remember I was complaining about uh the presenter, but I I didn't knew no one uh in in in the audience. And then it was literally two guys working for AWS like, "Hey, why don't you um apply?" 我记得当时还在抱怨那位演讲者，但听众里我一个人也不认识。结果正好有两个 AWS 员工对我说：“嘿，你为什么不申请一下？”

I was like, "Yeah, I'll never do this." like no it's a bit different and so forth. Ever since I applied and I joined and so forth I went to maybe uh I think eight different roles if I'm not mistaken. So from support to field uh customer fields like technical account management solution architecture specialist solution architecture then helping build uh the what we call serverless in the world the serverless business. So I was uh the first specialist outside US. 我说：“我绝不会去。”他们说，那里有点不一样，诸如此类。从申请、加入 AWS 以后，如果没记错，我大概做过八种不同的岗位：从 support 到面向客户的 field 岗位，包括 Technical Account Management、Solutions Architecture、Specialist Solutions Architecture，之后又参与打造我们如今所说的 serverless 业务。我是第一位美国以外的 specialist。

嘉宾 Mhm. So then even trying to hire like developer advocates and everything else I had to learn how to do the role until we managed to hire. So all the things it doesn't feel like Amazon from the outside but inside it was like let's just move let's just build these things. So in terms of learnings the two roles the three different roles that were that marked I think the way I think was something called technical account manager. You typically are called when things go wrong. 嗯。所以哪怕要招聘 developer advocates 等人员，我也得先学会怎么做这个岗位，直到终于招到人。外界可能觉得这不像 Amazon，但在内部，大家的状态就是：动起来，把这些东西造出来。谈到收获，有两个——或者说三个——岗位塑造了我的思考方式。其中一个叫 Technical Account Manager。一般只有出了问题时，人们才会找你。

主持人 So think like we're having an outage now. or having a big incident or you started using AWS, you lift and shifted and now your spend just went through the roof and you're trying to how do I optimize this spend? So all the all the things that people don't really want to they don't come nice to you and like oh hello let me the problem I have and it was just like I need help now I need to solve now. 比如，我们现在宕机了，或者发生了重大事故；又或者你开始使用 AWS，完成了 lift-and-shift，结果支出直线上升，于是想知道怎样优化成本。总之，客户都是因为那些不愿面对的问题来找你。他们不会客客气气地说：哦你好，让我介绍一下… …而是直接说：我遇到问题了，现在就需要帮助，现在就得解决。

So that one was when I met companies that people didn't want to work with eventually. Those were kind of gaming companies in the early days or startups that were seeing unpreent growth. So you would see things like microservices in 2015 of these companies or doing DevOps at scale or a API first teams. So this was 2015. So this already made me think okay everything should be microservices now or DevOps or something like this. 那个岗位让我接触到了一些最终很少有人愿意合作的公司。早期主要是游戏公司，或者经历空前增长的 startup。你会看到这些公司早在 2015 年就在使用 microservices、规模化 DevOps，或者 API-first 团队。所以当时我就开始觉得：好吧，现在一切都应该是 microservices，或者 DevOps 之类的东西。

And then the normal was something like oh 70 terabytes Dynamo DB table for NoSQL and that was 2015. And then after that when I started seeing other companies a few hundred so I was like oh they're still in the first 10 GB or something. So like oh there's lots of learnings that I can share things. 对他们而言，日常规模可能是一张 70 TB 的 DynamoDB 表，用作 NoSQL 数据库，而那是在 2015 年。后来我开始看到其他公司的情况，它们规模只有几百…

Exactly. So I went from like the trenches where everyone kind of dislikes AWS or complain about AWS and was there to help and fix and and try to recover that trust in some ways all the way to the first time customers looking at AWS and they first time they heard about elastic compute and it was like for them it was like wow oh my god what is this and then the specialist role was the serverless where you went from let's build this idea of API teams So teams based around APIs and the DevOps and the DevOps together and so forth to actually your teams could be a lot smaller because you don't have to think about server operations or most of the operations pieces. …我会想：哦，他们还处于最初 10 GB 的阶段之类的。所以我积累了很多可以分享的经验。 [笑] 没错。我的经历从一线开始——在那里，大家不是不喜欢 AWS，就是在抱怨 AWS，而我的任务是帮助他们修复问题，并以某种方式重新赢得信任——一直延伸到第一次接触 AWS 的客户。他们第一次听说 Elastic Compute，会惊叹：哇，天哪，这是什么？之后 specialist 岗位聚焦 serverless：我们先提出围绕 API 组建团队的理念，把 DevOps 等实践结合起来；后来进一步发现，你的团队。

And that's when I saw the second biggest shift in learnings cuz initially I thought it's all about tech. You just need to think differently your dependencies how you start your code. You have to take performance into account. 其实可以小得多，因为不必再考虑服务器运维，或者大部分。运维工作。这让我获得了第二个重要认知转变。最初我以为一切都关乎技术：只需要换一种思路，考虑依赖关系、代码如何启动，也必须把性能纳入考虑。

But now performance has a return of investment figured off to this which is developers usually have a hard time explaining on turning promotion cycle that if I work on this refactor if I improve performance of this this would have improvement to the business. It's very hard for developers to do this with serless was easier. I was like well if I do this I could cut 90% of our bills. 但现在，性能的投入回报可以被量化。过去，developer 通常很难在晋升周期里解释：如果我做这次重构、改善这项性能，会怎样改善业务。 developer 很难把这种价值讲清楚；serverless 则容易一些。我可以说：如果这样做，账单能降低 90%。

嘉宾 Okay. 好的。

主持人 And then people like really so now you can have a line to explain something that a CFO will be able to understand. 然后大家会问：真的？现在你就有了一条 CFO 也能理解的解释路径。

嘉宾 Yeah. But what I thought it was mostly technical was like, yeah, you don't need to use Java for everything. It doesn't work quite well for serless back in the days. You need to use languages like Go or Python or Node.js. What was interesting was for a small team, it was all tech. But when you're figuring things like how does this work for 10,000 developers, how does this work for 5,000, a thousand, or a few hundred developers, most of it was a organizational transformation. 对。但我原以为这主要是技术问题，比如你不必凡事都使用 Java；至少在当年的 serverless 场景里，它并不十分合适。你需要使用 Go、Python 或 Node.js 等语言。有意思的是，对小团队而言，这一切确实都是技术问题。但当你思考如何让它适用于 10,000 名 developer、5,000 名、1,000 名，甚至几百名 developer 时，大部分工作其实是组织转型。

So suddenly I had to witness not the not so fun parts of organizations where you're like what do I do now if it's 100 people room where all they do is watching a web server and restarting things serless handles you don't have to do any of this anymore all of this is gone 于是我不得不目睹组织里不那么愉快的部分：比如一个房间里有 100 个人，他们的全部工作就是盯着 web server，出问题时重启服务；而 serverless 会接管这些工作，你不再需要做这些，一切都消失了。

主持人 so how do you move from this do you repurpose you retrain how do you do it and then turns out that role for me to a longest for the longest period was like close to four years was How do we help an organization to look at their own people, look at their own teams and start thinking about communities, building core engineering, building teams differently, building smaller teams and this whole idea of road map or PRDs back in the days was already fading because of this model because it was so fast. 那么怎么从这种状态转变？重新安排岗位，还是重新培训？该怎么做？结果这个岗位成了我任职时间最长的岗位，接近四年。工作内容是：我们怎样帮助一个组织重新审视自己的人员和团队，开始思考如何建设 communities、建设 core engineering、以不同方式组建团队、建立更小的团队。当时，roadmap 或 PRD 的整套观念已经因为这种模式开始淡化，因为行动速度太快了。

I could go to companies and do principal engineer as a service if you will and in 6 months you could say well there we go got MVP we got in production we got post-production we got some learnings and now codifying for the rest organization this was unthinkable in an enterprise phase because it typically takes years most of the work is not coding is lo largely coordination and then convincing people on how things could be and how but even how things could be is an expensive move you have to have stakeholders that would believe in your word that way. 我可以去一家公司提供“Principal Engineer as a Service”；六个月后就能说：好了，MVP 有了，上生产了，经历了生产后的运行，也获得了一些经验，现在可以把这些经验编纂出来，供组织其他部分使用。这在企业环境里过去是不可想象的，因为通常需要好几年。多数工作并不是写代码，而是大量协调，然后说服人们接受事情可以变成什么样。甚至仅仅说明“事情可以变成什么样”就很昂贵：你必须找到愿意相信你说法的 stakeholders。

But when you say actually just give me three people, I'll show you 但如果你说：实际上只要给我三个人，我做给你看。

嘉宾 which is fun because it's a correlation next to the AI topic which we'll talk about it the last one. So I'll pause a bit so I don't dominate the talking is seeing these companies. It was like at some point it was like roughly 70 companies a year but I've seen a few 300 400 companies in a wheel more or less from the inside out trying to help them out becomes management consulting becomes writing becomes code becomes everything in between. 这很有意思，因为它与。我们稍后要谈的 AI 话题相呼应。先停一下，免得我主导整场谈话。 [笑]通过观察这些公司——有段时间一年大约接触 70 家；总计从内部看过、帮助过大概 300 到 400 家公司——这项工作既像 management consulting，也包括写作、编程，以及二者之间的所有事情。

What I learned about services was even though AWS would do with all the infrastructure for them and not have to think about anything, there was a massive gap on I'm used to developers take as a religion. My programming language is Java. My programming language is Python and nothing else matters. 我从 serverless 中学到的是：即使 AWS 替客户处理了全部基础设施，让他们不必再操心，仍然存在一道巨大鸿沟。 developer 往往把编程语言当作信仰：“我的语言是 Java”，或者“我的语言是 Python”，其他都不重要。

主持人 Identity. 这是身份认同。

嘉宾 Exactly. It turns into an identity thing. And one of the hardest things for them was but I'm used to Spring. I'm used to jungle. I'm used to these frameworks. And now I'm using serverless. and I feel like I'm stripped naked. 没错，它会变成身份问题。对他们而言最难的事情之一是：可是我习惯 Spring，我习惯 Django，我习惯这些framework。现在改用 serverless，我感觉像被剥光了一样。

主持人 If I use this, I will have a cold start of seconds, which is not good for customers. 如果用它，就会有数秒的 cold start，这对客户不好。

So, the ping I built then was something called power tools or lambda power tools. um which was the idea of how can I let them use a similar developer experience but also embed all this normal distributed system best practices I deponty how do you deal with poison peeling cues how do you deal with adaptive vitroid instead of static vitri circle breakers you name it and that blew up I initially thought I'll do this for certain customers because I knew anyways what the patterns were SDLC and how they organize 于是我后来做了一个叫 Powertools，或者 Lambda Powertools 的东西。它的理念是：怎样让他们保留相似的 developer experience，同时把常见的 distributed systems 最佳实践嵌入其中——idempotency、怎样处理 poison-pill queues、怎样使用 adaptive retry 而不是 static retry、circuit breakers，诸如此类。这个项目后来迅速壮大。最初我以为只会为特定客户做这件事，因为我已经了解那些模式、SDLC，以及他们组织工作的方式。

嘉宾 but this went from like um let me just do this prototype put in open source and see what happens. I had no experience in open source. I contributed hash corp every now and then but nothing at the size of power tools. Then eventually power tools in less than 5 years no less than four years actually we went from a few hundred downloads to something like 230 billion API calls a week to US government, British government and a bunch of other places. 但它从“我先做个 prototype，放到 open source 看看会怎样”开始。我没有 open source 经验，偶尔给 HashiCorp 做过贡献，但完全没做过 Powertools 这种规模的项目。最终不到五年——其实不到四年——Powertools 从几百次下载增长到每周支撑约 2300 亿次 API 调用，使用者包括美国政府、英国政府和许多其他机构。

And I'm like, "Oh, I I cannot make a release like like I used to. I need to exactly uh so that's where I learned the other aspects for the things I've been learning over the years with serless and the feud and dealing with pressure all the time and organizational changes. Now I had to do something fun which was working in public. M 我心想：哦，我不能再像以前那样发布版本了。我需要… … [笑] 没错。于是，经过多年 serverless 实践、处理纷争、持续承压和推动组织变革之后，我又学到了另一个方面。现在我得做一件有趣的事：公开工作。嗯。

主持人 you have both sides of the coin where everyone wants to contribute and excite is a new tech you know like rust comes out everyone wants to rebuild the whole libraries like everyone else has right and power tools wasn't so different everyone want to contribute to build a community from scratch but now you have to learn how do you write in public how do you create documentation as your your secret source because you don't have marketing budgets whatsoever how do you then do product management in in the open when everyone is criticizing and scrutinizing how you write and how you're thinking. 你会同时看到一枚硬币的两面：每个人都想贡献，也为新技术兴奋。比如 Rust 出现时，大家都想把其他人已有的全部 library 重写一遍，对吧？ Powertools 也没有太大不同。每个人都想参与，从零开始建立 community；但现在你必须学会怎样公开写作，怎样把 documentation 变成你的秘密武器，因为你根本没有 marketing budget；还要学会如何在开放环境中做 product management，因为所有人都会批评、审视你的文字和思路。

How do you then on board people that you never met and sometimes different time zones or how do you handle the situations where people say I contributed this but you're not merging my poll request and the time that I expect because I spend my time into this. I'm like okay let's have a conversation or sometimes you have trolls on the internet that would do a lot. I had stalking, I had a bunch of things as well on the on the on the downside of doing open source. 你怎样 onboard 从未见过的人，而他们有时还处于不同 time zone？你又怎样处理这样的情况：有人说：“我贡献了这些内容，但你没有在我预期的时间内合并 pull request，我可是投入了自己的时间。 ”我只能说：好吧，[笑] 我们谈一谈。有时网上也会出现 trolls，做出很多过分的事。我经历过跟踪骚扰和其他问题，这些都是做 open source 的负面部分。

So those three roles for me were where I learned how do I deal with production incidents and production spend and phops this was 2015 this idea of phops is like yeah we were doing it but again I don't know everything but it was cool to see it emerging as a a name something you put name to things 所以对我而言，那三个岗位让我学会如何处理生产事故和生产成本，以及 FinOps。这是在 2015 年；如今叫 FinOps 的理念，我们当时已经在做了。 [笑] 当然，我不是说自己什么都懂，但看着它逐渐形成、拥有一个可以指称的名字，很有意思。

嘉宾 then the other one was the customer field and the serverless and how to build a business from scratch with the most brilliant people I can ever think about that would work again all the way to How do I build a principal engineer as a service? Or how do I transform companies, help them see this STLC differently? And the worst which is how do you tackle identity of developers who are being grown attached to their languages to their frameworks but yet show them a path forward. 第二类经历是面向客户的 field 岗位和 serverless：与我能想到的最优秀的人一起，学习怎样从零建立业务，并一路发展到。怎样建立 Principal Engineer as a Service？怎样改造公司，帮助他们用不同方式理解 SDLC？其中最难的是：developer 已经对自己的语言和 framework 形成强烈身份依附，你怎样应对这种身份问题，同时向他们展示一条前进的路。

And then the last how do you then work in public use all these skills and hats from product marketing, engineering, customers and everything in between. 最后一类经历是：怎样公开工作，综合使用 product marketing、engineering、customers 等领域的全部技能，扮演多种角色。

主持人 Wow. 哇。

嘉宾 Yeah. So that's a long but that was like 11 years. 对。讲得很长，但那可是 11 年。

主持人 No, I love that. Yeah. To start off, I started my career in operations and when I hear you say kind of that experience really resonates seeing that side when hits the fan when things are crucial also at a level of scale. I wish a lot of people have more experiences like that cuz it really gives you perspective on 不，我很喜欢这段。对。[笑] 我职业生涯是从 operations 开始的。听你讲这些经历，我很有共鸣：看见事情彻底失控时的一面，看见关键时刻，而且还是在如此大的规模上。我希望更多人拥有类似经历，因为它确实能让你理解，

嘉宾 kind of yeah what happens when things go wrong and it drives you or you have it somewhere anchored in your in your brain 出问题时究竟会发生什么；它会驱动你，或者在你脑中某处扎根，。

主持人 to always keep with you 让你始终记着。

嘉宾 100%. the whole building in it public and your open source project blowing up. How how did that happen in the first place? Like you you went from let's just start this, it solves a problem for at least what I've seen within businesses to something that is huge and people rely on and building in public is scary. 百分之百。再说公开构建，以及你的 open source 项目突然爆发。这一切最初是怎么发生的？你从“先开始吧，它至少解决了我在企业里观察到的一个问题”，发展到一个规模庞大、许多人依赖的项目；而公开构建很可怕。

主持人 Yeah, I was I think privilege is the word. I was privileged to work on a team briefly something called you might have heard of something called AWS well architected. M 对，[笑] 我觉得该用“幸运”这个词。我很幸运，曾短暂加入一个团队，做一个你可能听过的东西：AWS Well-Architected。嗯。

嘉宾 so I help build what they call AWS well architected lens which is a way for you to bring your own best practices for a company for something like that and I wrote the first one called serless lens which also blew up by very quickly. 我参与构建了所谓的 AWS Well-Architected Lens，它让你可以针对某家公司或某类场景带入自己的最佳实践。我写了第一个 lens，叫 Serverless Lens，它也很快就火了。

Um so we had something like uh I think it was close to 10,000 unique reviews on different what we call workloads more than applications per se in 6 months and that gave me a window into oh I can see not only the SDLC but I can also without seeing the name aim of the customer of course for security reasons and legal I could see the patterns where people were struggling and were having issues with observability was the first one. [笑] 嗯，六个月内，我们针对不同的所谓 workloads——比单纯的 applications 更宽泛——完成了接近 10,000 次独立 review。这给我打开了一扇窗口：我不仅能看到 SDLC；出于安全和法律原因，当然看不到客户名称，但我能看到人们卡住、出问题的模式。第一个问题就是 observability。

Everyone had traces but there was nothing in the traces related to the business like so you're not really it's not really helping you. So when the power tools was launched was I need to make this process easier because this was one of those like I was telling I was not showing I did have examples of here's if you don't have observability this way this is how you do it this is how you do structure login this is how you do everything this was 2016 by the way 每个人都有 traces，但 trace 里没有任何与业务相关的信息，所以它实际上帮不了你。于是，推出 Powertools 的动机就是：我必须让这个过程变得更容易。因为之前我只是在告诉别人，而不是让他们亲眼看到。我确实有示例：如果你没有用这种方式做 observability，这里展示该怎么做；这里展示 structured logging；这里展示所有细节。顺便说一下，那是 2016 年。

主持人 but there was nothing that could show a wow moment where then in a few seconds I could have observability I can have a bunch of things without feeling like I I'm having to give away testing. I have to give away the way I do design applications and so forth. 但仍然缺少一个让人“哇”出来的瞬间——让人几秒钟内就能获得 observability，也能拥有。一整套能力，同时不觉得自己被迫放弃 testing、application design 的方式等等。

So when I launched power tools, it was at reinvent um and it was supposed to be like a um a presentation about the serverless lens in the console of AWS which the launch was delayed a little bit but I shared a few things and then I said all of this architecture best practices about serverless security reliability and so forth this is something I'm working on it. So, I was intentionally using the stage. 我在 re:Invent 发布 Powertools。原计划是在一个演讲中介绍 AWS Console 里的 Serverless Lens，但这个功能发布稍微延期了；我还是分享了几项内容，然后说：关于 serverless security、reliability 等方面的全部 architecture best practices，我正在做这样一个东西。

I think it was roughly 3,000 people on stage back then to show this is something that will help address, but they it was it was received with half criticism and half like super positive feedback. the criticism came which it's only Python like who uses Python and I was determined to say let's make Python the best programming language for for serless which is power tools became popular when I launched uh what we call tracer metrics and um tracer metrics and logger the structure logging and it was so easy for people to create demos it blew up as soon as people start sharing in newsletters into we call as heroes as community builders that people started writing articles about it how much easier it was. 所以，我是有意利用那个舞台——当时台下大约有 3,000 人——展示一个将有助于解决这些问题的项目。它收到的反馈一半是批评，一半非常积极。批评主要是：它只有 Python 版本，谁会用 Python？而我下定决心：让 Python 成为 serverless 的最佳编程语言。 Powertools 真正开始流行，是在我推出 Tracer、Metrics 和 Logger，也就是 structured logging 这些功能之后。人们可以非常容易地制作 demos；一旦 AWS Heroes、Community Builders 等人在 newsletter 里分享，项目就迅速传播开来。人们开始写文章，讲它让工作变得多么简单。

Then this just created a life on its own. Uh then the next big wave were partners not only like Zabia but there were a few others from AWS that started using it into consultancies 然后它拥有了自己的生命。下一波重大增长来自 partners；不只是 Zabia，还有其他 AWS 人员开始在 consultancies 里使用它。

嘉宾 to the point that people created custom programs and consultancies implementing power tools and it was like okay now I lost control. 最终，甚至有人开设专门的项目，由咨询公司实施 Powertools。我想：好吧，现在我已经失去控制了。

主持人 Exactly. Now it just snowballs. 没错。[笑] 它开始滚雪球。

嘉宾 Exactly. Yeah. Something like that. 正是。对，大概就是这样。

主持人 Insane. Yeah. Before we go into kind of how the software development life cycle is evolving based on your career experience, I'm amazed right and I haven't even been in this field for 11 years and you've done 11 years in eight different roles, hundreds of companies specifically at AWS, a company that I still look up to. I don't know about kind of the listener listening right now, but at least I still look up to when it comes to their engineering culture. 太疯狂了。好，在我们深入谈software development life cycle 如何演变之前，结合你的职业经历，我真的很惊讶。我在这个领域还不到 11 年，而你已经在 11 年间做过八种岗位，服务过几百家公司，并且是在 AWS。我现在依然敬仰这家公司。我不知道此刻的听众怎么想，但至少在 engineering culture 方面，我依然很佩服 AWS，也采访过一些在那里长期任职的人。

Uh, and some of the people I've spoken to that have had their tenure there.

What would your advice be for a listener listening to this and also thinking I want similar experiences. I want to make similar impact. I want my career to also reflect that in 10 years time. 如果有听众也在想：我想获得类似经历，产生类似影响，希望十年后自己的职业生涯也能呈现出这样的轨迹，你会给他什么建议？

嘉宾 Mhm. I think the best advice I I saw what came from my favorite newsletter which is nothing related to tech but it's something everyone needs especially if you are a staff plus engineer. It's a person called West Cow. Uh I'll I'll send you the link and can share later. 嗯。我看到过的最好建议来自我最喜欢的一份 newsletter。它和技术完全无关，但每个人都需要，Staff+ engineer 尤其需要。作者叫 Wes Kao。我之后把链接发给你，你可以分享。

It was something like when you get to like senior plus eventually you hit a ceiling of what else can I learn. 大意是：当你最终做到 Senior+，会撞上一道天花板，不知道还能学什么。

We are we tend to be conditioned to learn only the hard skills and all the technical pieces and be really good and be the best smart person in the room which is like BS in a way but often times when you try to go from senior to staff or staff to principal the hard skills don't they matter because you have to have otherwise you'll never get there to begin with but they matter less because most of the time is trying to influence people trying to work with people trying to communicate to people and the advice that came from that newsletter was That's exactly what I've been doing without naming put a name to this which was eventually going to hit the ceiling and the best way to grow your career is not to try to learn more on how to be more effective in your own job but trying to learn adjacent roles. 我们往往受训练只去学习 hard skills 和全部技术细节，努力做到非常出色，成为房间里最聪明的人——这在某种意义上是胡扯。但当你试图从 Senior 晋升 Staff，或从 Staff 晋升 Principal 时，hard skills 并不是不重要；它们当然重要，因为没有这些能力，你一开始就到不了这里。但它们的重要性会降低，因为多数时间都用于影响他人、与他人协作、和他人沟通。那份 newsletter 的建议，恰好就是我一直在做、但从未命名的事情：你终究会碰到天花板，职业成长最好的方式并不是继续学习如何把自己的本职工作做得更高效，而是学习相邻岗位。我向 developer marketing 学习，。

So I learned from developer marketing. I learned from public speaking. I've learned from how do I do business writing? How do I write? How do I become a tech writer? You don't have to actually do the role to move to the role. I was privileged. It was a great amazing moment Amazon had and still has. But you can join open source and start helping out on how do I improve the documentation. 学习 public speaking；我也学习怎样做 business writing、怎样写作、怎样成为 technical writer。你不必真的转去那个岗位才能学习它。我很幸运，Amazon 曾经有、现在仍有非常好的环境。但你也可以加入 open source，从帮助改善 documentation 开始。

So there's a lot that you can learn about cognitive load, how people perceive things, how do you break very complex topics into simple things. Every engineer that I know, especially at the senior level going to staff, they always struggle with the same topic. They go from complex to simple, never simple to complex. 这里面有很多东西可学：cognitive load、人们怎样感知信息、怎样把非常复杂的话题拆解成简单内容。我认识的每一位 engineer，尤其是从 Senior 走向 Staff 的人，都会在同一问题上挣扎：他们总是从复杂走向简单，却不会从简单走向复杂。

So those type of things you can learn and and you can control your own destiny that way without having to rely on opportunities that your employer would probably give you. Sometimes you can after you exercise and open source to some other places, but you can own that piece yourself. 这些能力是可以学习的。通过这种方式，你能掌握自己的命运，不必依赖雇主可能提供的机会。有时你可以先在 open source 或其他地方练习；无论如何，这部分可以由自己掌控。

主持人 I like that a lot. 我非常喜欢这个说法。

嘉宾 Yeah. So, it's like there's always so many things around you. It's never a single engineer that runs a business. You can learn a little bit about sales, how to influence people. At the end of the day, we're always selling something to someone, an idea or a thought or trying to convince someone to the contrarian, if you will. 是的，你周围永远有很多事情。一家公司从来不是由一名 engineer 独自经营的。你可以学习一点 sales，学习如何影响人。归根结底，我们始终在向某个人“销售”某样东西：一个 idea、一种想法，或者试图说服某人接受相反观点。

主持人 So, those things are useful for life and it can be useful for your career. 所以这些能力对生活有用，对职业也有用。

嘉宾 Yeah. Any career, right? 对，任何职业都是如此，对吧？

主持人 Precisely. Yeah. 没错。

嘉宾 Yeah. 是的。

主持人 I did that and it was purely on interest and instinct and curiosity. I was like, I would love to kind of see what this person is experiencing or 我就是这么做的，完全出于兴趣、直觉和好奇心。我会想：我很想看看这个人正在经历什么，

嘉宾 what's going on over there. Like I have no clue. There's a blind spot there. Let me try and figure that out or let me learn more about this thing. And it's not like I feel like people are idiots sometimes. I just want to really understand where certain decisions come from. Gregor actually gave me this advice. 那边究竟发生了什么。我完全不了解，那里是一个 blind spot；让我设法弄明白，或者多学一点。这并不是因为我觉得别人有时很蠢，而是我真的想理解某些决策从何而来。

Gregor hope he was like when decisions don't make sense to you like there's very smart people there are hardly idiots in leadership teams right super smart people they got there for a reason so when decisions don't make sense it's probably some piece of information you're missing Gregor Hohpe 曾给过我一个建议：当某项决策让你无法理解时，做决定的其实都是非常聪明的人。领导团队里几乎没有笨蛋，对吧？他们非常聪明，能走到那里有自己的原因。所以，当一个决定看起来不合理时，很可能是你缺少某条信息，

主持人 not them 而不是他们的问题。

嘉宾 100% 百分之百。

主持人 and that I love because that kind of reframed my thinking in that when something doesn't make sense there's something I'm missing right and I need the bigger picture to be effective at whatever I'm trying to achieve not just at my job but at this team or at this company specifically Yeah, I I worked at Greg uh Gregory before Amazon as well. I was lucky to work with so many people. Um I used to train people to become principal as AWS and so forth. 我很喜欢这个观点，因为它重构了我的思路：如果某件事不合逻辑，那就是我遗漏了什么，对吧？我要在自己试图实现的事情上发挥作用，就需要看到更大的图景；不仅是完成自己的工作，还包括服务这个团队，尤其是这家公司。对，我在加入 Amazon 之前也和 Gregor 共事过。我很幸运，和许多人一起工作过。

And I think the advice I should give them especially people who are heavily frustrated by leadership which sometimes comes as a spiritual being as someone that has every knowledge but doesn't act on anything which is a lie. is when you don't understand something that something feels irrational to you. [笑] 嗯，我以前培训过一些人成为 AWS 的 Principal 等等。尤其对那些因领导层而高度沮丧的人——领导有时会被想象成一种无所不知却什么都不行动的神秘存在，但这并不真实——我想给的建议是：当你不理解某件事，觉得它不理性时，

Like why are they making this decision? Like where's the all the trail? Cuz you're not going to find any is there's got to be an incentive somewhere. Follow the incentives and sometimes follow the money. So once you do this, then you things start to make a bit more sense. 比如问：为什么他们要做这个决定？完整的线索在哪里？你多半找不到所谓完整线索；但某个地方一定存在 incentive。顺着 incentive 去找，有时也要顺着钱去找。这样做之后，事情就会开始变得合理一些。

嘉宾 Yeah. Yeah. Gotcha. Nowadays, I feel like we're moving really fast with large language models, agents, agentic engineering, loop engineering. Nowadays, there are three people in the industry where some something they say people resonate and then they try and figure out, okay, where does this apply or is this It's like it's really funny times right now. And I see that very effectively for the single engineer, right? I don't have any other responsibilities. 对，对，明白了。如今，我感觉 large language models、agents、agentic engineering、loop engineering 发展得非常快。现在行业里有三类人，其中某个人说了些什么，引起大家共鸣；然后所有人就试图弄清：好，这适用于哪里，或者它到底成立吗？眼下这个阶段真的很有意思。

I build, I can put my head down, me and my swarm of agents and we just are effective together. When it then comes to enterprise and how this influences the software development life cycle, for me it's very interesting to see how things are evolving because I feel like everyone is experimenting and experiencing something different and I know you have an opinion especially with your background and I want to dive into that. 我能清楚看到它对单个 engineer 非常有效，对吧？我没有其他责任，只管构建；我可以埋头工作，和自己的一群 agents 一起高效推进。但当它进入 enterprise，影响 software development life cycle 时，我觉得观察事情如何演变非常有意思，因为似乎每个人都在实验，而且经历各不相同。

Now we're going to do something that we've never done before which is also show you kind of a visualization on screen of what it is going to talk about. So if you're listening, you might want to check out what we have on screen right now. I think everything is set up for us to do this. Can you walk me through kind of I think starting from product, how is product evolving with agents in the loop nowadays? 我知道，结合你的背景，你对此有明确看法，我想深入聊聊。接下来我们要做一件以前从未做过的事：在屏幕上展示你将要讨论的内容的可视化。如果你正在收听音频，或许可以看看我们此刻屏幕上的内容。我想一切都准备好了。能不能请你带我们梳理一下？我想从 product 开始：product 正在如何随着agents 进入 loop 而演变？

主持人 Sure. Of course. I mean this is what I'm going to show is my opinionated version of what I know it's working. 当然。我要展示的是一套带有个人立场的版本，它来自我所知道的有效实践。

嘉宾 Yeah. 对。

主持人 But it doesn't mean is the sole truth. 但这不意味着它是唯一真理。

Like you said, right now we're got into a different phase of engineering. not only engineering but running businesses where we we are now being able to finally hyperpersonalize anything but is also part of the danger because then a everyone can accidentally wrongly assume that engineer is just a single developer and that's all you need or that all you need is you no longer need PRDs or something like it and then you're fine because an agent can do everything for you and when there's something called a trust and decline recovery which I can cover more on this topic as we go through uh the slides but let me show you um the product first. 正如你说的，我们现在进入了 engineering 的新阶段；不仅是 engineering，也包括经营业务。我们终于能够把任何事物高度个性化，但这也带来危险：每个人都可能错误地假设 engineer 就只是一名单独的 developer，这就是你需要的一切；或者认为不再需要 PRD 之类的东西，只靠 agent 就万事大吉，因为 agent 能替你做一切。还有一个概念叫 trust decline and recovery，随着我们讲 slides，我可以更深入说明。先给你看 product。

This is one of the loops that we we do in in the team among at agent called the resilience task force. And the goal here is to try to embed the concept of a product requirement document. the famous or sometimes infamous PRD. 这是我们团队 Resilience Task Force 使用的一种 loop，其中包含 agent。这里的目标是把 Product Requirements Document，也就是著名、有时也臭名昭著的 PRD，其核心概念嵌入流程。

So it doesn't become something like like as an artifact that you you know have it and you just point people to it and more how do we get the essence of something like PRD into the whole stage of product thinking into the engineering pieces so it doesn't become an artifact anymore and is now a mental model for people 不要让 PRD 变成一件静态 artifact：你保存它，然后让别人自己去看；而是要把 PRD 的精髓带进 product thinking 的完整阶段，贯穿 engineering 环节。这样它不再只是一件 artifact，而成为人们的 mental model。

嘉宾 because agents will do the execution but if you lead them wrong and astray it's a chaos right so the whole point of this product loop is that if you start from discovery all the way to the slash new work which I'll explain This doesn't change the idea of the discovery. If you ever were in an open source role or ever were in my favorite role of all times called product engineering, then you got to have to talk to people. You got to have to talk to customers. 因为 agents 会负责执行，但如果你把它们带上错误方向，结果就是混乱，对吧？所以 product loop 的要点是：从 discovery 一直到 `/new-work`——稍后会解释——discovery 的理念并没有改变。如果你做过 open source，或者做过我一直最喜欢的 product engineering 岗位，就必须和人交谈，必须去和customers 交流。

Sometimes as engineers, we always complain that requirements are correct. I have to be do these things again. And it's like but you can also talk to customers. You can also get out of the way. And this discoveries is our way to let's talk to people first to figure out what is it that's needed. We need like a always does as well customer centricity is a key. But you also don't want to take the advice from only a single customer. engineer 有时总会抱怨 requirements 不正确，害我又得重做。但你也可以直接和 customers 交谈，也可以主动走出去。我们的 discovery 方法就是：先和人沟通，弄清真正需要什么。像 AWS 一贯强调的那样，customer centricity 是关键。

You need to have some data and you need to start ranking and then figure out what is this one solution that I could do that could tackle multiple problems at once. So that's the discovery piece. We're trying to figure things out, talk to people. Then the next one becomes a whiteboard almost like an engineering kind of a design session where you're trying to figure out this is what the customers are telling you. 但你也不能只听一个 customer 的建议；你需要数据，需要开始排序，然后找出一个能够同时解决多个问题的 solution。这就是 discovery：设法弄清状况，与人交流。下一步是 whiteboard，几乎像一次 engineering design session。你要弄清 customers 告诉了你什么，有哪些 customer segments，什么样的 feature 能匹配这些 segments 或某类 customers。

These are the the segments of segmentations of customers and what kind of feature would match this segments or this type of customers and which feature could make more sense to tackle 80% of them like 80 to 8020 rule the people that are getting started versus the power users edge customers and so forth. M 还要判断哪项 feature 最合理，能够覆盖其中 80%，类似 80/20 rule；要区分刚入门的人、power users、edge customers 等。嗯。

主持人 so the whiteboarding is for us to start figuring out what is it that a road map could look like because now with agents the whole idea of let's do this quarter quarterly plan or yearly plan is mostly collapsed but again not everywhere. So how do you do this in a whiteboard first so it fits in your brain and then eventually we have to codify this into an actual road map into something. 对我们来说，whiteboarding 是开始描绘 roadmap 可能长什么样。因为有了 agents，按季度或年度制订计划的整套思路大多已经崩解——但并非在所有地方都如此。那么，怎样先在 whiteboard 上完成这一步，让它能装进你的脑子，然后最终把它编纂成真正的 roadmap 或其他形式。对。但我们也不想把流程变成 waterfall。

Yeah. But we also don't want to turn this into a waterfall like because it's also very common these days especially with specdriven development that's not a problem but how we approach specdriven. So we take everything that's in the whiteboard and we call a assistant it's called /romap 如今这种风险很常见，尤其是 spec-driven development；问题并不在 spec-driven 本身，而在于我们怎样实施。我们拿走 whiteboard 上的全部内容，调用一个 assistant，叫 `/roadmap`。

嘉宾 before we go there. So discovery and whiteboard are those still the same people doing that because from my perspective it will be product people or people responsible for their product specifically. 在继续之前，discovery 和 whiteboard 还是由同一批人负责吗？因为在我看来，这会由 product 人员，或者具体负责该 product 的人完成。

主持人 That's the beauty of product engineering. um if you have a product manager with you and with the team amazing have a superpower 这正是 product engineering 的妙处。如果团队里有 product manager，那太棒了，相当于拥有一项 superpower。

嘉宾 but it's not always the case especially if you're in a startup or if you're in certain places. So in the team that we have the resilience task force which sometimes we refer as RTF to make things easier. 但情况不总是如此，尤其在 startup 或某些环境里。我们的团队叫 Resilience Task Force，有时简称 RTF。

主持人 Um we don't have the product manager. We're actually getting someone now which is super cool. 嗯，我们目前没有 product manager，不过现在正在招一个，这很棒。

嘉宾 Okay. 好。

主持人 Um but engineers are all staff plus engineers. So they're expected to have some of that skills. Uh so I most of the time act as one when I need it. So I would guide some of those discussions with customers and bring another friend with me uh staff engineer as well to figure out what is it that they're saying and do use some of the normal techniques about ranking UX journey and some of the things as well. 团队里的 engineer 全都是 Staff+ engineer，因此预期他们具备部分相关技能。我多数时候会在有需要时扮演 product manager：引导与 customers 的讨论，再带一位同为 Staff Engineer 的伙伴，一起弄清客户表达的意思，也使用一些常规方法，比如 ranking、UX journey 等。

嘉宾 Yeah. When you mentioned kind of looking into responsibilities adjacent to your role if you're a software engineer. This is a perfect example of that, right? 对。刚才你提到，software engineer 应该学习与自己岗位相邻的职责。这就是一个完美例子，对吧？

主持人 Absolutely. Even the idea of like a tech lead, I think some of the industry back in the days used to codify this into oh a tech lead would know but a product engineer would equally be able to do it. 完全正确。过去，行业有时会把 Tech Lead 这个角色明确规定成“他应该懂这些”；但 Product Engineer 同样可以做到。

嘉宾 This is why it's my favorite role because you can merge both customerf facing aspects of engineering dealing with customers thinking about product road map what is the outcome I want not implementation etc. Most of the time coding you don't want to do it because you're going to have to maintain. So if you don't if you sell something without code amazing even better. 所以这是我最喜欢的岗位：你可以把 engineering 面向 customer 的部分、直接处理 customers、思考 product roadmap，以及“我想实现什么 outcome，而不是怎样实现”等结合起来。很多时候，你最好不要写代码，因为写了就必须维护。如果不写 code 也能卖出一个方案，那太棒了，甚至更好。[清嗓]

主持人 Exactly. Even better. And but then you also need to be the the voice of uh I wouldn't say truth but the voice of reason sometimes of this this outcome is amazing in the business but to be able to implement this is going to be very costly. So you have to have that technical background. So product engineer end up doing both. So if you manage to get those skills this agencies like becomes like I can do even faster. 没错，更好。但你也必须充当一种声音——我不愿说“truth 的声音”，而是 voice of reason：这个 outcome 对 business 很棒，但实现成本会非常高。因此你必须具备 technical background。Product Engineer 最终会同时承担两边。如果你掌握这些技能，这种 agent 化的工作方式就会让我做得更快。

嘉宾 Gotcha. Yeah. Then we have the SL road mapap where for the first time this is where you have the plus agent next to a human. 明白。接下来是 `/roadmap`；这第一次出现 human 旁边加 agent。

Yeah, pretty much the reason the reason for this is that I think I was trying to find a word that's more kind to describe what I read on the internet sometimes is that when we are using models for so long using the words like please using the words like could you think about this it's like waste of tokens but eventually that makes your brain should think that this is how you communicate now but it's not really the way so force Since you have no agents whatsoever first and think about what the customer problem is, it forces you to use more of an analytical brain and use more of a different kind of skew set that otherwise you wouldn't. So I wanted to have this so your human aspects the empathy pieces that drives you for even better solutions don't atrophy in a way. 对。这样设计的原因是——我一直想找一个更委婉的词，[笑] 来描述网上有时看到的现象——我们长时间使用 models 时，总写 “please”、“could you think about this” 之类的词，觉得这是浪费 token；但时间久了，大脑会开始认为这就是沟通方式，其实并不是。因此，前面先不使用任何 agent，只思考 customer problem，会迫使你更多使用分析性思维，调用一套平常可能不会使用的不同 skill set。我想保留这个阶段，让人身上的那些部分——。比如推动你寻找更好 solution 的 empathy——不会以某种方式萎缩。

So this road map is now still part of big part which I explain now but the having agents first I initially started with this and then realizing that my communication became more tur and more direct and I was like why am I doing this I I'm not rude I'm not that kind of person and it just happens to all of us no matter the background of experience you have yeah so the critical thinking especially on the early side understanding customer problems and also using your language as such that stays with the human Yeah, pretty much. 因此 roadmap 阶段依然有很大一部分保持这种设计，我现在来解释。我最初是从“先用 agents”开始，后来发现自己的沟通变得更简短、更直接。我会想：我为什么这样说话？我并不粗鲁，也不是那种人。但无论经验背景如何，这都会发生在我们每个人身上。对，所以 critical thinking，尤其在。最早期理解 customer problem，以及以合适方式使用语言，这些仍应由 human 保留。

Pretty much. Yeah, if you're looking as a staff or as a principal, 对，基本如此。如果你处在 Staff 或 Principal 层级，

主持人 the biggest identity crisis that principles engineers have, especially staff, is like they move from let me just code this to oh, English is now my new programming language and it's hard for people to accept. It can get different impact. It's complicated. Principal Engineer——尤其是 Staff Engineer——最大的 identity crisis 是：他们从“让我直接把代码写出来”，变成“哦，English 现在是我的新 programming language”。人们很难接受这一点。它能带来不同层面的影响，也很复杂。

嘉宾 Gotcha. 明白。

主持人 But another day we can talk more about this. Now, for the slash road map, it's like a stupidly simple. The idea of a slash road mapap is a command that would try to take whatever input you have on a whiteboard or notes or something to try to update or create a road map like a markdown road map. 这个话题可以改天再聊。 [笑] 至于 `/roadmap`，它简单得近乎笨拙。 `/roadmap` 是一条 command，尝试接收 whiteboard、notes 或任何现有输入，然后更新或创建一份 roadmap，比如 Markdown roadmap，并不复杂。

Nothing really complicated and that would have these are some of the phases or ideas that I have or milestones if you will and once you have this then you can say let's go ahead and sync this to whatever system we use GitLab, Jira, you name it. in our case is GitLab and this creates epics, creates issues but one of the major wins for having a SL road map is that sometimes especially engineers again we forget that we're going to have some level of acceptance criteria or what is the outcome that we want. 它会列出一些 phase、idea，或者你也可以称为 milestone。有了它，你就可以说：把内容同步到我们使用的系统，无论是 GitLab、Jira 还是别的。我们使用 GitLab；同步会创建 epics 和 issues。采用 `/roadmap` 的一个主要收益是：我们——尤其是 engineer——有时会忘记必须定义某种 acceptance criteria，或者明确想要的 outcome。

嘉宾 Yeah. 对。

主持人 So road map enforces this because then I can use this into the developing loop. I have another loop just to verify have we actually achieved the outcome we wanted otherwise none of the code and the test matter. Roadmap 会强制写清这些，因为之后我。可以把它用于 development loop。我还有另一个 loop，专门验证我们是否真的实现了想要的 outcome；否则，所有 code 和 tests 都没有意义。

嘉宾 Gotcha. And the slash means it's a skill or it's something that's preconfigured that helps you with that. 明白。斜杠表示它是一项 skill，或者预配置的东西，帮助你完成这件事吗？

主持人 So this is a command. So we use a a company called factory. It's a factory droid. It's like cloud code. There's many companies like this like the amazing open code and so forth as well. 这是 command。我们使用一家叫 Factory 的公司，工具叫 Factory Droid，类似 Claude Code。还有很多同类产品，例如很棒的 OpenCode 等。

嘉宾 But the idea is that we have the definition of a command which is something that's user invoked 但核心是，我们有。 command 的定义，它由 user 主动调用；。

主持人 and you have the skill which is a more of a model invoked. I keep having mixed results with skills because at Rajin we are true believer of using multiple choices experimenting a bunch of things 还有 skill，更多由 model 主动调用。我使用 skills 得到的结果好坏参半，因为在 RTF，我们真心相信 multiple choices，会实验许多东西。

嘉宾 and we not we don't use only like a claw for instance opus or something like it we use I think it was in my account it was roughly 32 different models 我们不只使用 Claude Opus 之类的单一 model；我的账号里大约用了 32 种不同 models。

主持人 oh cool 哦，很酷。

嘉宾 which is a lot of different models so their their experience and the quality varies a lot it's great for um token efficiency and budget which we'll talk about it But when it comes to having his skills everywhere, what I notice is that eventually you have many things that models simply skip or they say they're doing it, but they're doing completely different. So a command forces to to actually use it. Yeah. And this works, I think, more in an augmented way, right? 确实是很多种 model，所以它们的体验和质量差异很大。这对 token efficiency 和 budget 很有帮助，我们稍后会谈。但如果到处都使用 skills，我观察到：最终有很多事情 models 会直接跳过，或者嘴上说自己做了，实际上却完全不是那么回事。 command 则会迫使它们真正执行。对。我觉得这更像 augmented 的方式，对吧？

Where the human is still in the driver's seat, they say, "Okay, right now we do this because we use a command instead of a skill." And then when you go more towards autonomous AI, that's where the model makes the decision on okay based on the context we now apply X Y and Z in skills. human依然坐在驾驶座上，明确说：“好，现在我们执行这个；因为这里使用 command，而不是 skill。 ”之后，当系统更接近 autonomous AI 时，model 才根据 context 决定现在应用 X、Y、Z 哪些 skills。

主持人 Yeah, pretty much. I'm a big fan of because of everything explained to organizations and so forth is that humans are nondeterministic by nature. 对，基本如此。结合前面谈到的组织问题，我很认同一点：human 本质上是 nondeterministic 的。

嘉宾 Mhm. 嗯。

主持人 But now we're adding more agent which is even more nondeterministic. So I need some level of determinism. So this is latch commands make sure that I know these instructions will be followed to a certain degree. 现在我们又加入更 nondeterministic 的 agent，因此我需要。某种程度的 determinism。斜杠 commands 能确保我知道这些 instructions 至少会在一定程度上得到遵循。

嘉宾 Gotcha. Yeah.

What's next? The next one is uh I briefly talked which is now that you have a road map you typically going to it's going to create this roadmap.mmd docs whatever folder structure and then you have a sync of this road map you typically ask you but if it doesn't you have a /ro woman--sync and that will create all this epics all these issues and update the road map so in case you run it again you know we don't determinism you know I want you to keep creating more epics or something the issue with this commands for product management what I noticed was now create go ahead and create epics and issues and then the next time you run it oh actually going to create the ones very similar very because I think the context is right there and then it keeps on tripping itself so the idea of having a separate one or a separate subcomand is to make sure that these are more deterministic 明白。下一步是什么？接下来是我刚才略微提过的：现在你已经有一份 roadmap，通常会生成 `roadmap.md`，放在 docs 或某种 folder structure 里；之后需要同步 roadmap。系统通常会询问你，但如果没有，就可以使用 `/roadmap-sync`。它会创建全部 epics、issues，并更新 roadmap。这样下次再运行时——考虑到系统并不 deterministic——就不会不断新建更多 epics。 Product Management commands 有一个问题：我注意到，当你让它创建 epics 和 issues 后，下次再运行，它会说：哦，我要创建一些非常相似的东西。因为 context 就在那里，它会不断把自己绊倒。所以，把它拆成独立 command 或 subcommand，是为了让这些操作更加deterministic。

主持人 gotcha and are these epics sub items the breakdown of the problem we're trying to solve which is going to result in a feature or feature set is the product person or the and even the product engineer defining what that looks like or is the agent helping with how to break down this bigger piece of problem. 明白。这些 epics 下的子项，是把我们试图解决的问题拆解开来，最终形成一个 feature 或 feature set。那么，是 product 人员或 Product Engineer 定义它的结构，还是 agent 帮助拆解这块更大的问题？

嘉宾 It's both. That's why I put the human and agent. 两者都有，所以我画了 human 和 agent。

主持人 Yeah, 对。

嘉宾 that's when you mentioned augmenting I think is my almost new favorite word in a way. Um 你提到 augmenting 时，我觉得这几乎成了我最喜欢的新词。某种程度上是这样。嗯。

主持人 even as humans there's so many things that we can think about it. Um one of the things we do a lot at a especially with this project is doing adversarial reviewers. So whenever you have a road map or have a plan, a spec or something, you always run a multiple angles of contrarians uh review if you will to see if you miss anything, if there's something you're maybe overengineering or if you're trying to boil the ocean to a degree. 即使作为 human，也有太多事情需要考虑。尤其在这个项目中，我们经常采用 adversarial reviewers。只要有 roadmap、plan、spec 或类似内容，就从多个角度让持反对意见的人 review，看看是否遗漏了什么、是否 overengineering，或者是否试图一次解决过大的问题。

So we have that element, but it's not so um enforced or so hard as a requirement. 流程中包含这一元素，但它不是被强制执行的硬性 requirement。

It's it has a it has a instruction to say after the road map has been finished do a pass like a mini loop to see if some of those are similar and they can be merged or if some of those don't have clear outcome or clear acceptance criteria and interview using socratic method until we actually get to the bottom of this is the thread this is how you think this is your rationale and these are invariance and now we know what the product needs but even in doing all this you're never going to Yeah, 100%. This is some of the things that we do to make it easier to make also people. instruction 会说：roadmap 完成后，再走一遍类似 mini loop 的检查，看看某些事项是否相似、能否合并，或者是否缺少清晰的 outcome、acceptance criteria；然后用 Socratic method 进行访谈，直到真正弄清：这是主线，这是你的思考方式，这是 rationale，这些是 invariants。现在我们知道 product 需要什么。但即使完成所有这些，你也永远不可能…

I think I would love to have this. I'm right now responsible for product and to have something where and I do do this with my peers, but it's not really like structured as such, right? It's kind of free flowy right now. And it feels like you have more of a process to make sure that the outcomes and also the people determining the outcomes are better at that. Yeah, I think again privilege. I think this came from this cooling of Amazon to a degree. …对，百分之百。这些做法是为了让事情更容易，也让人做得更好。我很想拥有这一套。我现在负责 product，确实会和 peers 做类似的事，但并没有这样结构化，对吧？目前更像自由流动。而你似乎有一套更明确的 process，确保 outcomes，以及确定 outcomes 的人，都能做得更好。

Uh because Amazon was very heavy on writing. So you wouldn't be able to get an idea out until you had something on paper. So you had to convince people through a document, not through a presentation. In many ways, this was amazing because it wasn't whoever spoke the loudest would actually win, but whoever had a the most clarity of thought, if you will. But it was also hard because not everyone would be able to read or write to to a degree. 对，我想还是因为幸运。 [笑] 这在某种程度上源于 Amazon 的训练。 Amazon 非常重视 writing；一项 idea 如果没有写到纸上，就无法推进。你必须通过 document 而不是 presentation 说服别人。很多时候这很棒，因为最终胜出的不是声音最大的人，而是思考最清晰的人。但这也很难，因为不是每个人都具备相同程度的阅读或写作能力。

主持人 I spent like four maybe six years training on just on writing which was like a lot of time. Not everyone has that time 我花了四年，也可能六年，只练 writing；这是很长的时间，不是每个人都有。

嘉宾 and uh and for this when I try how do I bring this to a a gentic word and how do I bring this without turning into Amazon or some of the toxic pieces that sometimes happens in writing. So the quickest trick even if you don't have much of a process is to always tell the agents use the socratic method to get to the bottom or find holes in my thinking my clarity and so forth and that alone forces it to be more structured. 因此我在思考，怎样把这种方法带进 agentic world，同时又不把它变成 Amazon 那一套，。也避开 writing 有时会产生的 toxic 部分。即使你没有多少 process，最快的技巧也是始终告诉 agents：使用 Socratic method 追根究底，找出我思考和表达清晰度中的漏洞。

What do you mean with the socratic method or how can you explain that for the listener? 仅这一点就会迫使过程更加结构化。

Yeah. So the Socratic method is come from philosophy where you're trying to get to an understanding of a topic truly simply by asking questions and you one question leads you to another question another question and you're trying to see if there are discrepancies is in their thoughts as you're trying to ask a question. eventually you it's not that you run out of questions but you run out of threads that you find these discrepancies and where they say things that actually it kind of goes against what you said in a previous statement and so forth. 你说的 Socratic method 是什么意思？怎样向听众解释？好，Socratic method 来自 philosophy。你试图仅仅通过提问，真正理解一个话题：一个问题引出另一个问题，再引出下一个问题；提问过程中，你不断检查对方的思路是否有不一致之处。最后并不是问题耗尽了，而是你能追查的那些分歧线索耗尽了。比如，他们现在说的话与之前某项表述相矛盾。

So the Socratic method is a way for you to almost like an investigation mode but through a curiosity lens. You're trying to understand something to the fullest but without make it seem like you are interrogating someone and they committed a crime and they have to tell you something now. Socratic method 几乎是一种 investigation mode，但采用 curiosity 的视角。你试图最充分地理解某件事，同时不让对方觉得自己正在被审问，好像犯了罪、现在非得交代什么。

主持人 Yeah. So when you have the kind of peer review, this is the method they use only questions. They're not people that say they have a question and then also give their opinion. And you can do this with an agent as well, I'm assuming. Yeah, pretty much. I at Amazon I had a role which was super cool was a almost engineer as a service. And I had something called discovery which is where some of the name come from. 对。那么进行 peer review 时，reviewer 只使用问题，不会以提问为名顺便表达自己的意见。假设 agent 也能这样做。对，基本如此。我在 Amazon 做过一个非常有意思的岗位，几乎是 Engineer as a Service。我把其中一个环节叫 discovery，[笑] 这个名字也部分来自那里。

And I had to figure it out within one week a company would tell me that um they they were unable to ship fast enough which is like vague like there's so many things never a technical reason or that they are engineers are not actually doing something as they thought it was the quality is not there maybe they need to think about hiring externally so they wanted a second opinion and in that one week I had to interview people I had to talk to people like almost like a consultant in a way and one of techniques was basically saying we're going to go for 90 minutes and I'm going to ask you a few questions for 70 minutes or so, but here's the game of the here's the rule of the game and you you tell me if I'm being dishonest. 我必须在一周内诊断一家公司提出的问题。比如，他们说自己无法足够快地 ship——这太模糊了，可能性很多，几乎从来不是纯技术原因；或者说 engineer 没有按预期做事、quality 不够，也许需要考虑外部招聘。因此他们想听 second opinion。那一周里，我必须采访和接触许多人，某种程度上几乎像 consultant。其中一种技巧是先说明：我们会谈 90 分钟，其中约 70 分钟由我向你提问；但游戏规则是这样，你如果觉得我不诚实，就直接指出。我不会展示自己的 opinion，也不会带入任何 bias。

I would not show my opinion. I will bring no bias whatsoever. Even though it's almost impossible human in judgment, but my role here is to try to understand your point of view and try to get to the bottom of how you think. 尽管 human 几乎不可能完全没有 judgment，但我在这里的职责是理解你的 point of view，追查你的思考方式。

What's your mental model? what is your view of the word and then I use photocratic method to simply keep asking questions and then playing back and try to show them in the last 20 minutes of the meeting. This is what I understood. Did I take it wrong? Did I take it something else? 你的 mental model 是什么？你如何看待世界？然后我用 Socratic method 持续提问并复述，在会议最后 20 分钟向他们展示：这是我理解的内容，我理解错了吗？

And then I would repeat until I get a view of okay this is where basically patterns what agents do pretty well and these are the things that it sounded true from a position of power or a position of management or you name it. But when you start digging it, there's a lot of misconceptions, misinformation, or lack of transparency, which open source kind of solves it. 是不是误读成了别的意思？我会反复进行，直到形成一幅图景：好，这些基本上是 patterns——agents 很擅长找这些；另外这些说法听起来正确，只因为它来自权力位置，或者management 位置等等。但开始深挖后，会发现其中有许多 misconceptions、misinformation 或缺少 transparency；open source 在某种程度上能解决这些问题。

嘉宾 Gotcha. It seems like a very interesting skill that I can also just put into practice and experiment with, right? I don't have to say I'm going to now use Socratic method, but I can just keep asking questions and hopefully it's not in an annoying way where people kind of drill down their thoughts and we get clarity on what they actually want to do in that way. Yeah. And that's basically what I'm doing with agents. I'm actually forcing agents to do this with me. 明白。这似乎是一项很有意思的 skill，我也可以直接实践和实验，对吧？我不必宣布“现在我要使用 Socratic method”，[笑] 只要持续提问，希望不会烦人；这样别人能深入自己的想法，我们也能澄清他们真正想做什么。对。我对 agents 做的基本就是这件事：强制 agents 和我一起使用这种方法。

And sometimes it becomes annoying because they're like, "You're doing this to me. Don't do what you're doing." Um, but I think what it's what's amazing about this is that we the more experience you have, the easier it becomes for you to jump into conclusions, the quicker it becomes. Oh, I've seen this before. And you think the word re revolves around this 有时它会很烦人，我会对它说：“你在用这招对付我。 [笑] 别再这么做了。 ”但它的惊人之处在于：你的经验越多，就越容易跳到结论，而且越来越快。你会说：哦，这个我以前见过。然后以为世界都围绕这套经验运转。

主持人 using the idea of socratic methods or let's say let's do an investigation for 70 minutes just questions like if I'm being too hard or too aggressive let me know and then I'll lower some of the intensity if you will but setting the expectations up front and having nothing but paper notes and asking questions it helps a lot. Yeah you also do this with paper notes interesting. Yeah, I one of the roles I had. Sorry, there's just too much. No, that's okay. 使用 Socratic method，或者先约定“我们进行 70 分钟 investigation，只提问题；如果我太严厉或太强势，请告诉我，我会降低一点强度”。预先设定 expectations，然后只带纸和笔记去提问，帮助非常大。对。你还用纸做笔记，很有意思。是的，我曾做过一个岗位。抱歉，内容实在太多。

Yeah. One of the one of the when I moved from Oh my god, you're here. Let's solve everything. Production is down. No,lifesaver. Yeah. Or sometimes it was also like a a scapegoat. Exactly. It's you. It's you. Exactly. 不，[笑] 没关系。我以前的岗位是这种状态：“天哪，你终于来了，快解决所有问题，生产环境挂了。 ”救命恩人。对。有时也会变成… … scapegoat。 [笑]没错。

Um when I moved to the other the completely contrasting version of this which was something called solution architect which we nowadays we call like forward deploy engineer in a way I had to go to those customers and it was the first time ever they saw me and they were like oh my god it's amazing so forth but there was so much that they wanted to share or worse sometimes we because it was this was commercial world so I needed to I always had a account manager with me which I learned heaps on influence in sales and I and I saw Oh, sales is not this thing that you just want to sell something like you're building relationships like oh okay and the the secrets was the paper what I learned through the role was I was always have a premeating just before that very important meeting let's call high stake meeting so I would use my paper to prep two or three questions ahead of time prep a part where I would always say these are the main takeaways or main actions we're going to do it and then go around it and what I've noticed after the few years of doing only pay I only do paper by the way only do paper notes nowadays 就是你，是你的错。对。后来我转到完全相反的岗位，叫 Solutions Architect，用今天的话说有点像 Forward Deployed Engineer。我需要拜访那些 customers，他们第一次见我，会说：天哪，太好了，等等。但他们想分享的内容实在太多。更糟的是，因为这是商业环境，我总有一名 Account Manager 同行；我从他们身上学到了大量 influence 和 sales 的知识。我意识到：哦，sales 并不是那种一味想把东西卖出去的工作，而是在建立 relationships。原来如此。它的秘密就在纸上。我从那个岗位学到：在重要会议——比如 high-stakes meeting——之前，一定开 pre-meeting。我会用纸预先写好两三个问题，也预留一个区域，始终记录：这些是我们要带走的主要 takeaways 或主要 actions。然后围绕它展开。我注意到，坚持只用纸几年后——顺便说，我现在仍然只用纸做 notes——。

嘉宾 still yeah it's I started to look differently when I go to meetings I see people with laptop I'm like oh I know they're not going to pay their fullest attention to this 还在用，是的。现在我去开会时，看见有人带 laptop，会想：哦，我知道他们无法投入全部注意力。

主持人 because there's always a wall between you and this thing even though it doesn't people don't really intend to to come this way but it comes this way it's natural 因为你和对方之间总隔着一堵墙。即使人们并不是故意表现出这种态度，它也会自然发生。

嘉宾 and with paper you're basically there you're open so in a more in I wouldn't say empathetic way but It gives you an advantage because you can see body language. You can see typically what 70% plus of the communications body language is not as non-verbal but not body language per se. 而使用纸时，你基本上完全在场。你是开放的。我不会说一定更 empathetic，但它会给你优势：你可以观察 body language。通常，沟通中超过 70% 是非语言信息——并不完全等于 body language，但确实是 non-verbal。

主持人 So using paper gives me two advantages that I will never get on laptop. On laptop I would always type faster than my thoughts are able to process and digest information which is a disadvantage. On paper is the opposite. I'm always writing slower because I'm processing I'm already digesting that information. 所以纸给我两个 laptop 永远无法提供的优势。使用 laptop 时，我打字速度总是快于思维处理和消化信息的速度，这是一个劣势。纸上则相反：我总写得更慢，因为写的同时正在处理、消化信息。

On laptop I usually take notes and then I have to spend another time thinking about what is it that I typed what is it that I understood and took from paper I do this simultaneously there's something called dual theory can talk about these things but it gives me something the laptop would never give me which is I can ask you a question like a leading question or mirroring something you did to me and as you answer the question I might already have two or three other questions lined up or I can write down a question should not interrupt you. 用 laptop 时，我通常先记 notes，之后还得花时间想：我刚才打了什么？理解和记下了什么？用纸时，这些过程同时发生。有一种叫 dual-coding theory 的理论，我们可以另谈；纸还带来 laptop 永远无法提供的东西：我可以问你一个leading question，或者 mirror 你刚才对我做的事。在你回答时，我可能已经排好两三个后续问题；也可以把想问的问题先写下来，不打断你。

So your flow keeps naturally and maybe you already answered the question I was going to ask. So I just cross and that conversation becomes more natural and it feels like on the other other side you've been heard you build a connection and with paper they can do this very quickly. So I can guide the conversation whichever place we want it to be 这样你的表达自然延续，也许已经顺带回答了我准备问的问题，我就把它划掉。 conversation 会更自然，对方会感到自己被听见了，双方建立起 connection。使用纸，这些动作可以很快完成。所以，我能把 conversation 引导到我们想去的任何方向，

嘉宾 without feeling like I'm coercing you or doing something like in a bad way. 而不会让你觉得我在胁迫你，或者带有不良意图。

I have realized this blockade that a laptop can form and sometimes when guests share something I'm like I I I want to try this out and I have this inkling of I want to try this out but I also don't really like writing in the whole paper note like what I try and do this is my approach genuinely and it really depends on the context cuz sometimes I do need to take notes on the fly I try and remember as much as I can 我确实意识到 laptop 会形成这种障碍。有时嘉宾分享一个方法，我会想：我很想试试，内心也有这种冲动；但我确实不太喜欢在纸上做整套笔记。我真正采用的方式是这样，当然很取决于 context，因为有时我确实需要现场记笔记。我会尽量记住尽可能多的内容。

主持人 and this probably this setting of podcasting and kind of being in the seat of hosting and asking questions and driving really helps with me memorizing, internalizing, and like picking a thread up after it's been dropped later. podcast 这种场景，以及坐在 host 的位置负责提问和推进，可能确实帮助我记忆、内化内容，也能在一条线索暂时中断后，稍后重新把它拾起来。

嘉宾 Um, but that's my approach. And then as soon as that meeting ends, if it was an important one, I go and I take my notes cuz I also want to kind of be able to revisit them. And right now, I do typing less and less. So, as soon as I'm done, I go click speech to text, let's go, random thoughts here and there. 嗯，这就是我的做法。重要会议一结束，我就会立刻去整理 notes，[笑] 因为我也希望以后能够回顾它们。现在我打字越来越少。结束后，我会点开 speech-to-text：来吧，把四处散落的想法都说出来。

And as I'm speaking that I feel like might be comparable to what you mentioned when writing I also gain clarity because I can type quite quickly and it can be quite rough notes just here and there and here and there but when I'm speaking I'm trying to articulate well. So then all of a sudden I need to have my thoughts in order which means I need to slow down the way I speak and actually have clarity in my thinking. 在说话的过程中，我觉得它可能和你说的手写类似，我也会获得清晰度。因为我打字很快，notes 可能非常粗糙，东一块西一块；但说话时，我会努力把意思表达清楚。于是突然之间，我必须让自己的思绪按顺序组织起来，也就意味着我要放慢语速，真正把思考理清。

That's that's precisely why we use paper notes because a way is a forcing function if you to slow down. We always had this problem before agents and now we have agents even more. We have more information than we can know what to do with it. Yeah. And being able to reason about something and then getting a step ahead. This is what paper will give you. 这正是我们使用纸质笔记的原因：它是一种 forcing function，迫使你慢下来。 agents 出现之前我们就有这个问题，现在有了 agents，问题更严重。信息多到我们不知道该拿它怎么办。

So a simple trick next time you just take a normal page of paper, count five lines from uh from the bottom of the page, just draw a horizontal line and there all you're going to do is write in your questions. But don't write an entire question cuz it's impossible. They're not going to be fast enough. Otherwise they're going to be we're speaking it makes it feel worse. 对。能够对某件事进行 reasoning，然后向前走一步，这就是纸能给你的东西。所以下次有个简单技巧：拿一张普通纸，从底部向上数五行，画一条水平线；这块区域只用来写问题。但不要写完整问题，因为你根本写不及。

So what what you would do is you will write a keyword or something that reminds you what the question you want to ask and then you ask and then it goes and then you already have a second question as they are speaking that makes it more natural. Gotcha. There not the raw paper notes is not for you to type everything as is. 否则别人还在说话，[笑] 你埋头狂写，感觉会更糟。你只要写一个 keyword 或提示词，提醒自己想问的问题；然后提问。对方说话时，你已经能记下第二个问题，这会让互动更自然。

Yeah. But just for the thought of you thinking this is the question I want to ask more or less the frame. this is the next items that we should be crossing after the meeting ends or something. It's more than enough. You don't need to take lots of what is it that they said cuz the whole goal is for you to be there, be present, have a good positive image in a way 明白。原始纸质笔记并不是让你逐字记录一切。对。它只需记录思考框架：这是我大概要问的问题；这些是会后要勾掉的下一步事项。这样完全足够。你不需要大量抄录对方说了什么，因为目标是让你人在现场、保持专注，以一种积极的方式呈现，

主持人 and then I basically achieve something or agree to something. The only reason we have meetings which some of the developers hate is that we always think differently. We always have different points of view. 然后真正实现某件事，或者达成某项 agreement。我们需要开会的唯一原因——尽管一些 developers 讨厌会议——是大家的思路和 point of view 总不一样。

So a meeting a good successful meeting always have something I love which is why are we meeting to begin with what is the success criteria so when you go to a meeting everyone knows this is why we're here if we don't cross this then this meeting especially if it's recurring should be canceled failed 因此，一场好的、成功的会议始终需要我很重视的一项内容：我们为什么要开这场会？ success criteria 是什么？这样所有人进入会议时都知道为何而来。如果目标没有划掉，尤其是 recurring meeting，就应该取消，这场会议失败了。

嘉宾 exactly it hasn't served his purpose but if it has then fantastic now you have your notes what the next action should be and perfect so this idea of taking notes is to give you the advantage of you can now read the table. There's other techniques you can also use in sales which is super cool. Uh but you can use the reading of the table and you forcing to slow down. So now you can understand how people say certain things. 没错，它没有实现目的。但如果完成了，那很好；你现在拥有 notes，知道下一项 action，十分完美。记笔记的意义，是让你获得“读懂整张桌子”的优势。 sales 里还有其他很酷的技巧；但你至少可以观察桌上所有人，并强迫自己慢下来。于是，你能理解人们说某些话时的状态。

If you type that person says certain things, but how did they feel? Were they pissed? Were they actually more positive? Were they like, "Yeah, that's how we do." It says a lot more than what you're going to capture as a note if you were to um almost like in a police station have a scriber just typing it. We're not scribbers, 如果只是打字，你只知道某人说了什么；但他的感受呢？他很生气吗？实际上更积极吗？他说“对，我们就是这么做的”时是什么语气？这些信息远比文字 notes 丰富。如果像在警察局里安排一名书记员不停打字，你就捕捉不到它。我们不是书记员，

主持人 right? We're supposed to have that understanding and know where to go next. 对吧？我们的职责是形成理解，并知道下一步往哪里走。

嘉宾 Yeah, that explains a lot to me cuz I was thinking of writing out my full question on paper and being like, I'm way too slow of a writer. I need to get f faster at writing if I even want to try this. But keywords is what I do when I do do it on a laptop as well. So then it would make sense to try this. I am going to try this. I think it's gonna be fun. 对，这解释了我的疑惑。我原本以为要把完整问题写在纸上，然后发现自己写得太慢：如果想试这套方法，我必须提高书写速度。但我在 laptop 上记笔记时也会使用 keywords，所以纸上也说得通。我会试试，应该很有意思。

主持人 Please do. After your podcast, I'll show you some of my favorite notes. 一定要试。你的 podcast 结束后，我给你看几页我最喜欢的 notes。

嘉宾 I I was even thinking, should I then do this in a podcast setting? Should I just be like, there you go. 我刚才甚至在想：那我是不是也该在 podcast 里这样做？就直接开始。

主持人 I actually did when I used to do streaming and such, I used to do it as well. Yeah, it's very quick. Uh it's like a reporter like it's you. 我以前做 streaming 时也这么做。对，非常快，就像 reporter 一样。

It's those are the things that you like, oh man, I never thought about this way. It's just like, have you ever seen a reporter bringing a laptop for an interview? They will never do this. They would always have something like quick paper notes or something. Yeah, 这种事会让你想：天哪，我从来没这样考虑过。你见过 reporter 带 laptop 去采访吗？他们绝不会，总会带能快速记录的纸质 notes 之类。

嘉宾 that's why. 原来如此。

主持人 Gotcha. Yeah, we talked about breaking down from discovery a problem that you have and breaking them down into epics or issues some form that is more digestible. What comes after that? 明白。我们刚才谈到，从 discovery 开始，把一个 problem 拆成 epics、issues 或更易处理的形式。接下来是什么？

嘉宾 So now that we have the road map, one of the main things that happen is this sense of judgment of have I actually captured everything cuz humans want to have I wouldn't not every human has a sense of perfectionist. I do 现在有了 roadmap，接下来主要发生的一件事就是。进行判断：我真的捕捉到了一切吗？human 总想……不是每个人都有 perfectionism，但我有，

主持人 which is a problem. uh and I built mechanisms to prevent me from be perfectionist in a way otherwise I get nothing done. um you got a road map but the normal sense it would be especially for the engineer like what if I start implementing this halfway through I figure oh I missed something or I didn't have the clarity of thought that I thought I had because sometimes when you get actual code you find more things even if you spoke to customers hundreds of hours it's normal then we have something called slash new work which is also another command so what that does is to bridge that gap when you're implementing something or especially the biggest problem now with agents is like, "Oh, just just one more thing. 这其实是个问题。 [笑] 我建立了一些机制，防止自己陷入 perfectionism，否则什么都做不完。现在你有 roadmap；对 engineer 来说，常见担忧会是：如果实现到一半，发现遗漏了什么，或者思路并没有自己以为的那么清楚，怎么办？因为真正写 code 时，你总会发现更多事情，即使已经和 customers 谈了几百个小时也很正常。于是我们有另一个 command，叫 `/new-work`。它用来弥合实现过程中的缺口。尤其是 agents 时代最大的一个问题：“哦，只要再加一件事，我顺手就能做，反正现在这么便宜。

I can just do it. It's so cheap now.

嘉宾 Do you want me to do it? It even asks you." 要我帮你做吗？它甚至会主动问你。”

主持人 Exactly. It's like, "No, don't don't feed my my toxic personality in that in that sense." 没错。我会说：“不，别助长我这种有害的性格。[笑]”

嘉宾 One more thing. 就再加一件事。

主持人 Exactly. No, don't do this. It's not a Steve Jobs type stuff type of stuff. And um sometimes you want to capture that thought so you you do it later or sometimes it's literally a hole into the plan but it's not a hole that you could have prevented from the to begin with. It's something you only realize when you are in the process of implementing or doing something. 对，不要这样。这不是 Steve Jobs 那种 “one more thing”。有时你想先捕捉这个想法，以后再做；有时它确实是 plan 里的洞，但不是最初能够预防的洞，而是只有实际实现或执行时才能意识到的问题。

So slash newwork takes of your context and then you can say you know what I just found this but sounds like we need an issue for this and then he creates a new GitLab issue or J whatever and he associates with an epic so work always remains traceable. `/new-work` 会取得当前 context；你可以说：我刚发现这个问题，看来需要建立一个 issue。它会创建新的 GitLab issue 或 Jira item，并关联到某个 epic，让工作始终保持 traceable。

嘉宾 Gotcha. 明白。

主持人 So you can do this throughout implementation or you know it's a new session let me just do this because we don't have it. So you can use both ways. 你可以在整个 implementation 期间使用它；或者开启新 session 时发现此前没记录，也可以用。两种方式都行。

嘉宾 Interesting. I am a person that for some things I'm a little bit more perfectionist but for some things and especially when it comes to the way we software engineer I feel like we need a certain level of pragmatism because as you go and as you start you learn new things and sometimes 90% of the way is actually perfect and you keep it that 100% because the last 10% will never be prioritized. 有意思。有些事情上，我比较追求完美，但另一些事情上，尤其 software engineering 的方式，我觉得需要一定程度的 pragmatism。因为边做边学时会发现新信息；有时做到 90% 已经很完美，就应保持在 90%，因为最后 10% 永远不会得到优先级。

主持人 Mhm. That's my approach so far to a point where sometimes I'm even like too much on that way of thinking and that black and white. 嗯。至少到目前为止，这是我的做法。有时我甚至过度坚持这种思路，变得非黑即白。

嘉宾 Um so I also need people to counterbalance that and be like well this is still actually very important for x y and z reason. So yeah, this would I think be quite interesting. 所以我也需要有人。来制衡，告诉我：不，这件事仍然非常重要，原因是 X、Y、Z。所以，我觉得这套方法会很有意思。

主持人 But this is the beauty of u this is where um I don't I don't like when people say, "Oh, I'm using agents and I'm now 20 100 times productive like in a single setting or in a team setting because we don't work alone. Uh even if you say you work alone and you're working on a single open source that you do everything on your own, eventually people are going to consume and ask you questions. So you're still going to have some level of collaboration. 这也正是它的美妙之处。嗯，我不喜欢人们说：“我用了 agents，现在单次任务或者团队效率提高了 20 倍、100 倍。 ”因为我们并不是独自工作。即使你说自己独立维护一个 open source 项目，所有事情都亲自做，最终仍会有人来使用并提出问题，所以仍然会发生某种 collaboration。

So for me when building teams back in the days it was always trying to pull uh pull people by their strength and see what adds up as opposed to oh this people could only do this. What is it that actually add to the team? 以前组建团队时，我总是试图发挥每个人的 strengths，看它们怎样相加，而不是说某个人只能做什么。真正的问题是：他给团队增加了什么？

嘉宾 Mhm. 嗯。

主持人 Because I if I were to build a team I would definitely want someone like you to start going through hang on a second we're trying to boil the ocean. Let's be a little bit more pragmatic in here to get the task and get the job done. But I would also want to have someone who would be like have we really thought about every single corner case? 如果让我组建团队，我肯定希望有你这样的人站出来说：等一下，我们想一次解决的问题太多了。这里实际一点，先完成 task，把 job 做完。但我也希望另一个人追问：我们真的考虑了每个 corner case 吗？

Have we done a formal verification which is one of the hardest things to do in engineering uh to cover the last 10% or last 5% if you will cuz sometimes there are critical mission critical applications where these things are not a nice to have. These are table stakes. 是否进行了 formal verification——这是 engineering 里最难做的事情之一——来覆盖最后 10% 或 5%？因为有些 mission-critical applications 里，这些不是 nice-to-have，而是 table stakes。

嘉宾 Yeah. Yeah. Yeah. I like that a lot. It's really dependent on the use case which mindset you need and having a combination equipped kind of within a team allows you to be very versatile on the problems you solve. 对，对。我很喜欢这个观点。需要哪种 mindset，确实取决于 use case。团队里兼有这些不同能力，就能非常灵活地解决问题。

主持人 Yeah. And I and I had this conversation this week with a with a very senior engineer trying to understand a reorg in something that happened without going into the internals because there's no point in sharing. But engineers would typically see a reorg as oh another reorg. Oh my god. like we're going to change it again. We don't have focus. 对。本周我还和一位非常资深的 engineer 谈过，试图理解某次 reorg 中发生的事情。内部细节没必要分享。 engineer 通常会把 reorg 看成：哦，又来一次重组。天哪，我们又要改变，完全没有 focus。

But sometimes this organization is a living organism as well like software and so forth that the moment you change something you might you you might not have the full picture like the pieces we're discussing. They don't understand leadership don't understand what they're doing so forth but it's only preparing the organization before it makes another change significant pieces like we're doing software. 但有时organization 也像 software 一样，是活的 organism。你改变某件事时，可能并没有完整图景，就像我们前面讨论的情况。人们会说：他们不理解 leadership，leadership 也不知道自己在做什么。但有时，那只是为 organization 下一次重大变化做准备。

You're not going to simply say agent go ahead and refactor everything to rust because I love rust. 软件工作也一样：你不会只说“agent，把一切重构成 Rust，因为我喜欢 Rust”。

It might work. It might run out of credits. It might have it might be chaotic. Yeah. But you're trying to do to make this more deterministic is you're trying to prep the code base so the agents understand these are this the patterns that work. These are the things they should not do. These are the things that should actually be caught by a link and not by adversarial reviewer. Otherwise, you're spending too much time on nondeterminism. 它也许成功，也许耗尽 credits，也许造成混乱。对。为了让过程更 deterministic，你会先整理 codebase，让 agents 理解：这些 patterns 是有效的；这些事不该做；这些错误应该由 lint 捕获，而不是交给 adversarial reviewer。否则你在 nondeterminism 上花的时间太多。

And then once you have this and now you make one change, does it work? And then you make the other one. 准备好这些后，先做一项 change，看看是否有效，再做下一项。

嘉宾 Gotcha. Yeah. When engineers then actually pick up an item, something that needs to be done, what does that look like? 明白。那么 engineer 真正领取一个需要完成的 item 时，流程是什么样？

主持人 It's very similar to let's call it the traditional way. You pick up an issue and then you say agent go do the task 它和传统方式很像。你领取一个 issue，然后对 agent 说：执行这个 task。

嘉宾 and the agent will because the issue has already a template you already know that I'm structured. An issue would already have a template and already have to say these are the outcomes. agent 会开始工作。因为 issue 已经使用 template，结构也已经确定；issue 中会写清 outcomes，以及基本的 acceptance criteria，problem 是什么；如果已有 potential solution，也会写进去。

These are the basically what the acceptance criteria is, what the problem is. uh way potential solution if there's one and they will simply use the agent to drive everything and they would have a conversation of uh how do I how do I get this to work in implementation is this a solid use case is this a does it have tradeoff or something like this maybe this is a good hooking point to go to the next slide to show you what a development look uh cycle looks like engineer 基本上用 agent 驱动全部工作，并与它讨论：怎样让实现真正工作？这是稳健的 use case 吗？有没有 tradeoff？也许这里正好可以切到下一张 slide，展示 development life cycle 是什么样。

主持人 let's do that 好，我们来看。

嘉宾 it's more complicated than it looks I try to make it as simple as possible but we use a project called openspec which is uh one of my favorites when it comes to specdriven development. The idea of opensp spec like anything related to specdriven development is you are having a discussion a brainstorming phase first where trying to figure out what the solution could look like. Do we need a database? Do we need a persistence layer? Do we need testing? How do we test this thing? 它看起来比实际更复杂，我已经尽量简化。我们使用一个叫 OpenSpec 的项目；在 spec-driven development 领域，它是我的最爱之一。 OpenSpec 和所有 spec-driven development 的理念一样：先进行 discussion 和 brainstorming，弄清 potential solution 长什么样。需要 database 吗？需要 persistence layer 吗？需要 testing 吗？

Do we use ports and adapters? Do we use hexagonal architecture? How do we make this evolvable? There's so many questions that you're using and this openspec explore uses socratic method to try to keep asking you until they get to the bottom of what your design looks like. It's never going to be 100% but it gets you to a good enough 怎样测试？使用 ports and adapters 吗？使用 hexagonal architecture 吗？怎样让它可以演进？这里有很多问题。 `openspec explore` 会使用 Socratic method 持续提问，直到弄清 design 的底部。永远不可能达到 100%，但会得到足够好的答案：

主持人 how do I test this? How do I structure the code base or this feature? So the when I read the files 如何测试？怎样组织 codebase 或这项 feature？这样当我读 files 时，

嘉宾 I know what the role is and I can see some level of architecture. So the explorer is brainstorming of the task. But sometimes that's the pragmatism that comes in. You don't need all this heavyweight machinery just to do uh change the color of something or you know what just add a drop down. It makes no sense to have an entire open spec uh pieces into it. So then you can simply prompt your way out 就知道各自的 role，也能看出。一定程度的 architecture。因此 explore 阶段就是针对 task 的 brainstorming。但有时要讲 pragmatism：只是改个颜色，或者加一个 dropdown，根本不需要这套重量级 machinery。为了这种小改动走完整个 OpenSpec 流程没有意义，直接用 prompt 完成就行。

主持人 and then we have verification layers later to say 后面我们还有 verification layers，用来检查：。

嘉宾 have we actually achieved the outcome as we wanted as described in the issue as described in the road map. So you remove the pressure off the the individual the engineer and also the agent to get everything perfect. 是否真的实现了 issue 和 roadmap 描述的 outcome？这样就把“一切必须完美”的压力从 individual engineer 和 agent 身上移开。

主持人 Gotcha. Openspec I I've experimented with and if you're listening we have a new image on the screen that shows the developer loop I would say. 明白。我实验过 OpenSpec。正在收听的听众注意，屏幕上现在有一张新图，展示的应该是 developer loop。

嘉宾 Yeah. 对。

主持人 So it starts with exploring. 从 exploring 开始。

嘉宾 Yeah. That would be an agent and a human. It says also sot which is state-of-the-art model. 对，由 agent 和 human 一起完成。图上还写着 SOTA，也就是 state-of-the-art model。

主持人 Exactly. 没错。

嘉宾 So you would do this with the higher capable models in exploring what issue needs to be built. Yes. Exactly. One of the differences uh at a which I love by the way is that we're not the type of company that will just use something for the sake of using an hype. We're mostly trying to think about what is it that would solve the merchants's problem. 所以这里会使用更强的。 capable model，来探索这个 issue 需要构建什么。对，没错。我很喜欢我们公司的一点：我们不是那种为了追逐 hype 就使用某项技术的公司。我们主要思考的是：什么能解决 merchants 的问题？

How do we make the merchant uh use this technologies or something for to get better margin loyalty you name it there's all the kinds of problems we want to get and when it comes to AI we could technically use sot only the oppos and only like GPT 5.5 or something like it but that eventually comes with a cost and you're not similar to the the jargon that developers use the best tool for the job you don't want to use this all the time so in our process we usually use three different tiers of models. 怎样让 merchant 使用这些 technologies，提高 margin、loyalty 等等。我们想解决各种各样的问题。谈到 AI，理论上可以只用 SOTA，比如只用 Opus、GPT-5.5 之类；但最终会产生费用。借用 developer 常说的行话：要为工作选择最佳工具，而不是始终使用同一种工具。因此，我们的 process 通常使用三个不同 tiers 的 models。

We use a let's call the best model sa for help me understand help me explore don't do anything don't create any files like you're prohibited to create anything you have to ask for permission before you create anything there's hooks there's something we can prevent it and this is where I find those very large models super efficient especially if you use something like fable which is amazing at planning things so once you have a plan out and you go to let's say implementation then you can use more of a mid tier depending on what you planned and then can use smaller models, especially open weights, super effective to do rounds and rounds and rounds of reviews. 在“帮我理解、帮我探索”阶段，使用最好的 SOTA model，但告诉它不要做任何事、不要创建 files；禁止创建任何内容，必须先请求 permission。我们有 hooks 等机制阻止它行动。我发现大型 models 在这里效率非常高，特别是使用在 planning 方面很出色的 Fable。形成 plan 后，进入 implementation 阶段，就可以更多使用mid-tier model，具体取决于 plan；之后可以使用更小的 models，尤其是 open-weights models，进行一轮又一轮 review，非常有效。

So your your your finance appreciates and then you can also make more efficient use of budgets which is something that we're now still getting good grips of it in the age of the AI now. 这样 finance 部门会满意，budget 也能得到更高效的利用。在 AI 时代，我们仍在逐渐掌握这件事。

Right now we're getting into like yes use everything token maxing which is not my the thing I I'm a fan of but eventually that that cost will come and then when leadership start questioning hang on a second do I need an engineer plus 5,000 a month 3,000 a month just for them to do their work that that math doesn't doesn't add up for a one engineer few engineers sure I mean companies like it's a pocket money 目前行业正进入“所有东西都用上、token 拉满”的阶段，我并不喜欢这种做法，[笑] 但成本终究会显现。管理层会开始质疑：等一下，我需要支付一名 engineer 的工资，再加上每月 5,000 或 3,000 美元，才能让他完成工作吗？这笔账算不通。对一名或少数几名 engineer，当然没问题；对公司而言只是零花钱，

主持人 especially in an enterprise but when you're looking at the scale of a for instance like 1.4 4,000 engineers that we have that math starts to show very quickly and ask questions. But it's not that we would be like we would never do this, but we have to be more sensible. Something we're still figuring out. Nobody has the final answer to all this otherwise they would have sold it for a few years. 尤其 enterprise 更是如此。但一旦扩大到例如我们拥有的约 1,400 名 engineer，数字会很快显现并引发质疑。这并不意味着我们绝不会这样做，而是必须更加理性。我们还在摸索；没有人掌握最终答案，否则几年前早就把方案卖出来了。

嘉宾 Yeah. We would have we would have been using it already. Yeah. 对，我们早就会用了。[笑]

主持人 Yeah. Exactly.

In this idea then specifically do you envision this is going to be a a guidance a guideline education on how we work as software engineers within software development life cycle specifically in your environment in your org or are you going to enforce this to a certain degree because 1400 people having the ownership lie on them on this is how we work and then them also having the ability to not do that and to only use state-of-the-art models kind of I'm wondering what your thought pattern is there. 正是。那么在这套理念里，你设想它主要是一种 guidance、guideline 和 education，用来说明在你们 environment 和 organization 里，software engineer 应怎样在 SDLC 中工作，还是会在一定程度上强制执行？因为如果 1,400 个人都自行决定“我们怎样工作”，同时又可以选择不遵循，只使用 state-of-the-art models，我很好奇你是怎样思考这个问题的。好，我来自 cloud 领域。

Yeah,I came from cloud. So the first not cloud but audience would understand it. In cloud computing the first shock that most organizations had was I knew exactly what I would pay in my server even with like thousands of money. [笑] 先不直接谈 cloud，但听众应该能理解。 cloud computing 最初给多数 organization 的震撼是：过去我很清楚一台 server 要付多少钱，即使要几千美元。

嘉宾 Yeah. 对。

主持人 And then you would depreciate over x amount of years, right? X number of years. 然后在若干年内做 depreciation，对吧？

嘉宾 Simple math calculation. You got it. 简单的数学计算，没错。

主持人 Yeah. Exactly. Which it sounds simple like Yeah. It's capex versus opex type of thing. And then cloud is like what do you mean? I don't know what my bill exactly is going to be next month. This doesn't sound correct. 对。这听起来很简单，就是 CapEx 和 OpEx 的区别。但 cloud 会让人问：什么意思？我居然不知道下个月账单到底是多少？这听起来不对。

嘉宾 There you go. Let's go. 好了，开始吧。[笑]

主持人 Exactly. So when you see the productivity and and what you get from cloud electricity and self-service and so forth, you're like, "Oh, I get it." But I also don't want to make this for everyone because it may not make sense. It it comes to a point where you have to trust human judgment otherwise why did you hire the person to begin with? 没错。当你看到 cloud 带来的 productivity，以及像 electricity 一样的 self-service 能力时，会说：哦，我明白了。但我也不想把它强加给所有人，因为有些场景并不合理。到某个程度，你必须信任 human judgment，否则当初为什么要雇这个人？

But then you also have to have some level of guard rails on top of advices uh patterns software to kind of help you when it comes to AI especially at a we have a platform engineering organization that we have an amazing team just focus on this right now. So one of the main points from them is to figure out how does the SDLC the software development life cycle looks like in a gentic area. What is it that we have to create as paved roads? Something that we know. 不过在 advice、patterns、software 之上也需要一定程度的 guardrails，帮助你使用 AI。尤其我们公司设有 Platform Engineering organization，其中一个很棒的团队正专注于此。他们的核心问题之一是：在 agentic era，SDLC 应该是什么样？

But it's never going to be a single paved road. It's going to be paved roads depending on our profile, depending on the application. Is this a web hook? Is this in the critical flow? You're taking fraud. You're not going to reduce tokens for something that's going to be a fraud. It's like a huge thing. Uh but also how do what tools do we use? Uh one of the main issues with AI now right now is like oh I can use open code. Sometimes I use cloud code. 我们需要建立哪些 paved roads，也就是已知可行的标准路径？但它永远不会只有一条 paved road，而会根据 profile 和 application 有多条。这是 webhook 吗？位于 critical flow 吗？如果处理 fraud，你不会为了省 token 而降低能力，因为这是大事。还要决定使用哪些 tools。

Sometimes I use something else. kilo kilo from Amazon. It's all over the place. Like cloud was the same. It was no different. But in this case, you're trying to what we're doing at Aggin specifically is trying to find those the normal uh the settlers and um the idea of organizations where you find who are the people that are exploring things that we want to keep a close eye to learn what's working, what's hype, what doesn't. That's part of my team's doing as well. AI 现在的一大问题是：哦，我可以用 OpenCode，有时用 Claude Code，有时又用别的，比如 Amazon 的 Kiro。到处都不一致。 cloud 当初也一样，并没有区别。但在我们公司，当前具体做法是识别常见的 settlers 与 explorers：找出哪些人正在探索值得密切关注的东西，从中学习什么有效、什么只是 hype、什么无效。这也是我团队工作的一部分。

And now that we got this, how do we experiment with two, three more teams off of these experiences? Do we use opensp spec? Do we use something else? Like opensp spec works for part of a majority of agent does not work at all because we have a gigantic monor repo 有了这些经验后，怎样再和两三个团队一起实验？使用 OpenSpec 还是其他东西？OpenSpec 对大部分 agent 场景有效，但对我们一个部分完全不适用，因为那里有巨大的 monorepo。

嘉宾 which is not a bad thing. They have all the context there, but the agents don't quite like at times monorepo 本身不是坏事，它包含全部 context；但 agents 有时不喜欢，。

主持人 because it's too much and openspec doesn't quite have the idea of working in a monor repo. It thinks that everything's going to be in a top level folder. But when you're having hundreds and thousands of developers touching these things, get conflict happens and everything else happens. So how do we make it work now for a m a population of developers and then how do we transition? How do we step onto this larger monor repo? 因为内容太多。而 OpenSpec 并没有真正考虑在 monorepo 中工作，它假设一切都位于 top-level folder。当几百、几千名 developer 都在修改这些内容时，会发生 Git conflicts 以及各种问题。那么，怎样先让它适用于一部分 developer，再怎样迁移、进入更大的 monorepo？

So it works for the majority the core business of a for instance. So we have this team thinking about the things thinking from a limits point of view. 这样它才能服务大多数人，比如公司的 core business。这个团队就在从 limits 的视角思考这些问题。

One of the things that cloud does really well and is shaved shaped the industry is if you let a service like AWS Lambda just simply say you know what you can do 100,000 containers from now at any point in time just send a request and we we'll come up with infrastructure for you. When you do times a few million customers you're going to have to do a lot of capacity planning and it could also be the wrong way. cloud 做得非常好、也塑造了行业的一件事是：如果 AWS Lambda 这样的 service 直接说，从现在起任何时候你都可以启动 100,000 个 containers，只要发 request，我们会提供 infrastructure。把它乘以几百万 customers，就需要做大量 capacity planning，而且这个需求本身也可能方向错了：你的第一个 application 为什么就需要 100,000 个。

Why do you need even need 100,000 containers from the first application you have? It doesn't make sense. So the limits help you to put that soft guard rail to figure out, oh, okay, you hit the limit. We can increase it. There's no problem. This is fake money anyway. containers？这不合理。所以 limits 提供了一道柔性的 guardrail。达到 limit 后，我们当然可以提高，没有问题，反正这些是内部的“虚拟钱”。

嘉宾 But let me learn how are you actually using it. Are you using the SOT model only? So it becomes more educational and it comes from a different curiosity point of view as opposed to my way is our way. This is our gate. This is like the way we should be doing it. So this is becomes more of an IT service as opposed to platform engineering. 但我先借机了解你到底怎样使用它：是不是只用 SOTA model？这样谈话更具教育意义，出发点是 curiosity，而不是“我的方式就是我们的方式，这是 gate，所有人必须这么做”。否则，它更像传统 IT service，而不是 Platform Engineering。

主持人 Gotcha. So it's really you are giving a lot of autonomy and ownership to engineers but you have a conversation point kind of built in because there's always a budget when it comes to what you can use right if you want to use Intelligj there's a license cost. So internally there's a budget and with models state-of-the-art we now have pay as you go. So there's probably a cap on there somewhere. 明白。所以你确实给 engineer 很大的 autonomy 和 ownership，但系统内置了 conversation point。因为可使用的任何东西都有 budget，对吧？使用 IntelliJ 也有 license cost。内部会有预算，而 state-of-the-art models 现在按量付费，某处自然会设 cap。

And when you hit the cap there, you have your conversation starter to talk about, okay, are you only using state-of-the-art models or can we do this smarter in a way? So that's where you hit education 达到cap 时，它就成为 conversation starter：你是不是只在用 state-of-the-art models？能否用更聪明的方式完成？于是进入 education。

嘉宾 pretty much. We also do we as in as a company, but it's all platform engineering all their credit nothing to do with 基本如此。公司也在做另一件事——全是 Platform Engineering 团队的功劳，和我无关。[笑]

主持人 is they are thinking they have their own internal website with patterns. This is what people are actually doing with AI. This is are some of the if you use opensp spec this is what makes successful. These are some of the people in the company that you should talk to. This is how this is a guide for when to use the very large model. This is a guy when to use mid-tier models, smaller models, openweight models, that sort of stuff. So it's written there. 他们有一个内部网站，整理 patterns：公司里的人实际怎样使用 AI；如果使用。 OpenSpec，哪些做法能让它成功；公司里应该找哪些人交流；何时使用 very large model，何时使用 mid-tier、small 或 open-weight models，等等。这些都写在那里。

嘉宾 But in this day and age very few people read. 但这个时代很少有人阅读。

主持人 So then it becomes this convers this self-fulfilling not so self-fulfilling. It becomes a loop in itself where now you hit a limit. Let me get close to you. trying to work it out. 所以它会形成一个循环：。你触及 limit，我们就过来和你一起弄清情况。

Maybe you didn't even know that that guidance was there to begin with like solution engineering like forward deployed engineer that we call these days or maybe the guidance is not enough it's mostly implicit and how do we make this more explicit maybe we need more tools maybe we can do something which I'm experimenting now called autoizer before you do a task before the agent goes ahead and implements like let me do this I'm the hero um maybe think it through does he need a spec or does he f just do ad hoc prompting M 也许你一开始甚至不知道存在那些 guidance；这就像现在所谓的 Solutions Engineering 或 Forward Deployed Engineer。也许 guidance 不够，知识大多是 implicit 的；那怎样把它变得 explicit？也许需要更多 tools。比如我正在实验一个叫“AutoSizer”的东西：在执行 task、agent 开始实现之前，先问： “让我来，我是英雄”——先想清楚：需要 spec，还是直接 ad-hoc prompting？嗯。

嘉宾 again it's never deterministic 100% but at least it's something that you can add 这永远不可能 100% deterministic，但至少可以增加一道判断。

主持人 to not make it look like 同时又不会显得像：。

嘉宾 no you can only do this these are your options 不，你只能这样做，只有这些 options。

主持人 this never stopped anyone from creating shadow 这种限制从来阻止不了 shadow IT，人们照样会去做。

嘉宾 they will still go absolutely yeah very stubborn stubborn folk the engineers 当然。engineer 是很固执的一群人。[笑]

主持人 no I like that as well I'm thinking similarly in my context how do we make these practices scale in the end and I have the same thought as you someone hits kind of a budget cap conversation starter can we Can we educate? Did you know about X Y and Z? For me, in theory that works, but when we're talking about 1400 people, how do you scale these types of conversations? Have you thought about that as well? 不过我也喜欢这种设计。我正在自己的 context 中思考类似问题：最终怎样让这些 practices 规模化。我想法和你相同：有人达到 budget cap，它就成为 conversation starter；能不能提供 education？你知道 X、Y、Z 吗？理论上这有效，但面对 1,400 人时，怎样扩展这类 conversations？你也考虑过吗？

嘉宾 Yeah, I mean, again, privilege for AWS, I managed to I think back in the days I trained like I don't know 8,000 plus architects back in the days. uh because I was lucky enough to be one of the first uh then there's a time for patterns and a read it before anything else or try to use a to summarize it for you if you don't want to read it. Um there are tools that will make your life easier because you want to codify these things as much as possible like I did with power tools. 对。我还得说，感谢在 AWS 的幸运经历。 [笑] 我记得当年培训过 8,000 多名 architects，因为有幸成为最早的一批人之一。嗯，这里既需要 patterns，也需要“先阅读再行动”；如果不想读，也可以用 AI 帮你总结。还要用 tools 降低门槛，因为你应尽可能把这些知识 codify，就像我做 Powertools 一样。

If you codify it to a point where this stop part of the workflow, people won't even get surprised by the time they hit a limit or something for instance and then you have the normal like internal meetups, internal community building if you will and building the ideas of champions everywhere. Uh not only at a we are trying to do this as well but Amazon was very notorious for doing this. 如果 codify 到它成为 workflow 的一部分，人们甚至不会在触及 limit 时感到意外。然后还有常规的内部 meetups、内部 community building，并在各处培养 champions。我们公司也在尝试；Amazon 尤其以此闻名。

Uh one of the things I loved about Amazon was when you go to an interview for instance you would have the concept of a bar raiser. 我喜欢 Amazon 的一件事是，参加 interview 时会遇到 Bar Raiser。

So we have someone who's been very very experienced in interviewing lots of people call hundreds of people and they will not be in your team and let alone in your organization most of the time they'll be completely outside but you will know that you could trust that if they earned that accreditation if you will you know they're going to have a high bar. So this idea of champions like training certifications and tears does pretty well is the same pattern. It's nothing. 这个人拥有非常丰富的面试经验，面试过几百人，通常不属于你未来的 team，甚至不属于同一 organization，可能来自完全不同的地方。但你知道：既然他赢得了这项 accreditation，就可以信任他会坚持很高的 bar。培养 champions、提供 training、certifications 和 tiers，也是同一种有效 pattern，并不新鲜。

What we're dealing is nothing new. Uh it just the speed of how you can hit the road and hit the wall. 我们面对的并不是新问题，只是现在上路和撞墙的速度变了。

主持人 It chang it. But the way you approach it, the way you look at things is the same. 速度改变了，但处理方式和看待事情的方式相同。

嘉宾 Gotcha. I like that. It's not just we only do this. We do this and this and this to make sure we have enough bases covered where we're confident in educating people making sure they are feeling enabled and equipped to work on whatever outcome they are responsible for cuz that's really enablement 明白，我喜欢这一点。不是只规定“我们只能这样做”，而是。同时采用这项、那项、另一项，确保覆盖足够多的基础；这样才能有信心教育大家，确保他们感到自己获得了能力和。工具，可以为自己负责的任何 outcome 工作；这才是真正的 enablement。

主持人 pretty much if you look at the software as you if you will which I really love to do it when I was doing power tools with the team and with the community I never did it alone I my biggest challenge was how much is is opinionated. How much is this just an opinion because we think we're right cuz it can happen. 基本如此。如果像看待 software 一样看这件事——我和团队、community 一起做 Powertools 时就很喜欢这样思考；我从来不是独自完成——最大的挑战是：我们应该带多强的 opinion？有多少只是因为我们自认为正确而形成的 opinion？这种事会发生。

Egon happens everywhere. And how much do we simply leave them to make a decision on their own and just give them the basics. This is like always been the hardest thing. So when you look at software and think if Java gives you all these standard libraries and a bunch of things like Python and Go and so forth, why do people keep using frameworks? most of the time is like you don't want to make decisions. You want to make as very few decisions as possible. ego 到处都有。又该在多大程度上让用户自行决定，只提供 basics？这一直是最难的部分。把 software 当作例子：Java、Python、Go 等已经提供大量 standard libraries 和功能，为什么人们仍不断使用 frameworks？多数时候，是因为你不想做决定，希望要做的决定越少越好。

So once you figure that out in your own context, in your own problem space, what is it that you don't want to make a decision? What is it that people get you decision fatigue? Like this is nothing to do with them. This is not going to change drastically the outcome. Then you codify this and you automate this and remove the the decision. So agents basically is the same. 因此，你要在自己的 context、problem space 里找出：哪些事情不值得让人做决定？什么导致 decision fatigue，却与他们真正的工作无关，也不会显著改变 outcome？然后把它 codify、automate，移除这个决定。

The idea of the road map that we just discussed, the idea of having something that would act like a thinking partner in a in a very aggressive way, in a socratic way, uh all the way to a gate, which we talk it we'll talk through about merge checks, which everyone myself initially hated, but now I'm improving. agents 也一样。比如刚才谈的 roadmap；又比如提供一个像 thinking partner 一样的东西，以很强势、Socratic 的方式与你思考；一直到 gate。稍后会谈 merge checks——最初所有人包括我都讨厌它，现在我开始改观。

嘉宾 Yeah. uh is there to save you from from those things but it's also there to not force you to make that decision because there's only so many decisions we can make in a single day before we already are tired before all the walls of text we are reading from agents are producing it so these things get to you 对。它既是为了避免那些问题，也是为了不迫使你做不必要的决定。因为人在一天里能做的决定有限，很快就会疲惫，更何况还要阅读 agents 生成的一堵堵文字。这些都会累积。

主持人 gotcha yeah what's next in this workflow 明白。这个 workflow 的下一步是什么？

嘉宾 the next piece we have is the the actual plan once you figured something out you know what you need to do then the OpenSpec plan creates the actual artifacts. So this would be the standard. There's a spec to this. There's a design document and there's a task. We don't use the vanilla open spec. 下一块是真正的 plan。弄清问题、知道要做什么之后，`OpenSpec plan` 会生成实际 artifacts。这是一套标准结构：包含 spec、design document 和tasks。我们没有使用 vanilla OpenSpec。

I learned that we can the most the biggest power of OpenSpec is that you can codify the workflow you want, which is amazing because you're always going to have a spec that has to happen. Everything else you can customize. You can add many gates, many artifacts, a PD if you wanted to. And that is the phase where we now introduce things like formal verification which is a way for you to specify how your system should behave. What are the invariance? 我发现 OpenSpec 最大的力量在于可以 codify 你想要的 workflow，这非常棒。 spec 是必须存在的，除此之外都可以 customize。你可以增加很多 gates、artifacts，甚至 PRD。这个阶段还会引入 formal verification，用来精确定义 system 应怎样运行：invariants 是什么？

What are the states that should never happen to begin with? Think an outbox pattern where you add something to the database, a transaction, and then you also add a item that you can use as a queue. For instance, you put an event or something. And that outbox typically would always be something like it has been persisted or is in the process of being persisted or it failed should be retried. 哪些states 从一开始就绝不能出现？例如 outbox pattern：你在 database transaction 中写入某项内容，同时增加一个可作为 queue 使用的 item，比如放入一个 event。 outbox 通常只应处于几种状态：已经 persisted、正在 persisted，或者失败并等待 retry。

主持人 So there's nothing if something happens outside of this it's wrong. So you can codify these things using something we use something called FSBY which I really love but there's many others TLA plus squint. So when you do this is more precise for agents to know what needs to be done at implementation level because English is like for us humans is never precise. 所以，如果发生了。这些状态之外的事情，。就是错的。你可以把这些规则 codify。我们使用一个我很喜欢的工具叫 FizzBee；还有 TLA+、Quint 等许多选择。这样一来，agents 在 implementation 层面会更准确地知道该做什么，因为 English 对 human 而言从来不够精确。

嘉宾 So this plan creates all these things at once. It creates the spec enumerates all the acceptance criteria because it came from the road map. plan 会一次生成所有这些内容：创建 spec，列举全部 acceptance criteria——因为它们来自 roadmap——并列出。

He enumerates what are the what are the outcomes that something we want to do the entire design goals non goals what is the testing strategy what are we using in add testing for do we need do we need fuzzing testing do we need property based testing unit test is a given but what else do we need and are we creating test for the sake of test or do we really need to all the way to is this covering UI changes if it does cover UI changes what are the components we're going to use are we going to run contrast testing for accessibility and some of these things. 我们想实现的 outcomes、完整 design、goals、non-goals、testing strategy。需要什么 additional testing？需要 fuzz testing 吗？需要 property-based testing 吗？ unit test 是基本要求，除此之外还需要什么？是在为了 test 而写 test，还是真的需要？再进一步：是否涉及 UI changes？

So the design is very comprehensive and it's something we customize. So the agents just look at this and got it. And then the task is basically a atomic version of this. So do this first and we're going to do this backend first the API and it also covers things like if this is a breaking change what is our migration strategy as well. How what do you do first? What can you do in parallel? What can you do sequentially? 如果涉及，使用哪些 components？是否运行面向 accessibility 的 contrast testing 等？所以 design 非常全面，而且由我们 customized。 agents 看一眼就能明白。 tasks 则是它的 atomic 版本：先做这一项；先完成 backend 和 API；同时覆盖 breaking change 时的 migration strategy。

Would your advice be to start with openspec and then indeed look at what you think is important within your software development life cycle and codify that as much as possible or are there frameworks out there or open-source sources where people can get inspiration to kind of get a head start. What I would always recommend is start simple and then you you bring your own thing. The mistake is to choose openspec TLC which is really good. 先做什么？哪些可以 parallel？哪些必须sequentially？你的建议是先用 OpenSpec，再查看自己的 SDLC 中哪些内容重要，并尽可能 codify；还是存在 frameworks 或 open-source resources，让人们参考并快速起步？我始终建议从简单开始，然后再加入自己的东西。

It's some of the most advanced right now or using Amazon key or something that's already baked in and use that as the only way because everything works differently inspection AI hyperpersonalization. So the beauty is to start so you understand the cycle of a specdriven development. So you're going to have to have a spec, you're going to have to have a design and you're going to have to have tasks. That's the that's the essence of it. 错误在于选择一个已经很完善、目前也很先进的 OpenSpec workflow，或者 Amazon Kiro 里内置的方案，然后把它当成唯一方式。每件事运作方式都不同，尤其 AI 支持 hyper-personalization。美妙之处是先开始，理解 spec-driven development 的 cycle：你需要 spec，需要 design，还需要 tasks，这就是核心。

But the quality of what your design looks like, the quality of the additional tasks that you can do, this has to come from you. So you can start with anything. Opensp spec I think is the simplest. You just install Openspec and then just open spec explore and you guide you with everything. Don't have to do anything else. 但 design 的质量、additional tasks 的质量必须来自你自己。可以从任何工具开始。我觉得 OpenSpec 最简单：安装后运行 `openspec explore`，它会引导整个过程，其他什么都不用做。

主持人 But don't stop there. If you stop there, that's a mistake because then it means either you probably don't have a process and you probably haven't taught too much about software correctness. So the default will basically be as good as the model that you're using it and that's no good. 但不要停在那里。停在那里是错误的，因为这意味着你可能没有自己的 process，也没有认真思考 software correctness。默认效果只会和所用 model 一样好，这并不好。

嘉宾 Yeah. How fast did you start with vanilla openspec to what you have now? How much time was in between kind of codifying the thoughts that people have the opinions of the organization and the people driving it. 对。从 vanilla OpenSpec 到现在这套系统，你用了多长时间？把大家的 thoughts、organization 及推动者的 opinions codify，花了多久？

主持人 So this the initial version of openspec to a custom workflow took me like a month. 从最初 OpenSpec 到 custom workflow 大约用了一个月。

嘉宾 Okay. 好。

主持人 But to get to a point okay this works in a team that took a good three to four months. mostly because I was like anybody else oppos everywhere and I'll just use it and then the moment I start using every iteration was like oh there was like 50 million tokens 但让它在一个 team 里真正有效，花了整整三到四个月。主要因为我和其他人一样，最初什么都用 Opus；然后每次 iteration 都会消耗大约 5,000 万 token。

嘉宾 and I was like I did one which was a refactor of how I was doing front end I'm doing something I really love now called local first architecture which is like my god I wish I had known this before and this cost me like almost 200 million tokens to refactor and I'm like oh I need to stop using ous doesn't work. It's 我做过一次 frontend 方式的 refactor；现在我在做一个非常喜欢的东西叫 local-first architecture，。天哪，真希望早点知道它。那次 refactor 几乎花了 2 亿 token。我清了清嗓子，想：哦，我得停止使用 Opus，这样不行，

主持人 junky. 太笨重了。

嘉宾 Exactly. And the moment I tried to use uh open weight models, think Kimmy, think uh GLM or something. This was like four months ago. 没错。后来我尝试 open-weight models，例如 Kimi、GLM 等。那是大约四个月前。

主持人 The implementation was like so worse uh quality start lying to me think even lus lies as well. And that's why it took a lot more time. I can codify these things. But the moment I try to save on those tokens and use different models, it's like using different frameworks, it's like using different programming languages. implementation 质量差得多，model 开始对我撒谎——当然 Opus 也会撒谎。这就是为什么过程花了更多时间。我可以 codify 这些规则，但一旦为了节省 token 而更换 models，就像更换 frameworks 或 programming languages，必须非常谨慎地学习如何构建 verification loop——现在这叫 loop engineering。

So I have to be very careful to learn how do I now build a verification loop which is now called loop engineering. [snorts and laughter] Uh so then I can turn this into more of a commodity ideally which is ideally where we should be heading. [吸气、笑] 理想情况下，这能让 model 更像 commodity；行业也应该朝这个方向发展。

嘉宾 Yeah. 对。

主持人 So this took a lot longer. This is where I spend most of my time. How do I bring the SOTA models right here, the state-of-the-art models and then bring a mid tier and then I bring a very cheap model to do reviews. 所以花的时间长得多。我大部分时间都花在这里：怎样把 SOTA/state-of-the-art models 放在这一环节，之后用 mid-tier，再用非常便宜的 model 做 reviews。

嘉宾 Are you capable still? That took a lot of back and forth. The piece I'm working right now, which is in part of the the slides, is I'm building a It's not going to be perfect. It's never going to be perfect, but I'm trying to be perfectionist if I'm honest. 你依然能完成任务吗？这需要大量反复调整。我现在正在做的一块没有放进 slides。它不可能完美，永远不会完美；但坦白说，我还是带着 perfectionism，[笑] 试图构建一套对几乎所有 models 都有效的东西。

I'm trying to build something that works for let's say almost all models where I can trust that even if they forge an evidence, they forge that they run the test, they try to copy and paste a results from the internet, which they do. How do I make sure that this doesn't happen so I don't let in code that I didn't have the time to review. 即使 model 伪造 evidence、谎称运行了 test、试图从网上复制粘贴 results——它们确实会这么做——我怎样确保这些行为不会发生，从而避免放进自己没时间 review 的 code？

主持人 Gotcha. 明白。

嘉宾 How do I make sure that oh it was just one more thing? 怎样确保不会出现“只是再加一项”？

嘉宾 we always do this and how do I make sure that the biggest challenge I had was when you go through this loop you're using open spec and you spec driven that should gets you like 19 95% quality wise software correctness wise but there's always going to be something you want to change and that's when this slippery slope happens because you're now going to ad hoc prompting and now you have to remember to run reviews to run certain things which now you're falling apart you're falling prey to one something I learned at Amazon called good intentions you're relying on people to remember,oh, we need to run these things. 我们总这样做。还要解决我遇到的最大挑战：走完这套 loop，使用 OpenSpec 和 spec-driven 方法，应该能让 software 在 quality 和 correctness 上达到约 90% 到 95%。但总会有想改的东西，这时 slippery slope 开始了：你转向 ad-hoc prompting，又必须记得运行 reviews 和其他检查，整个体系开始散架。你落入了我在 Amazon 学到的一种陷阱：依赖 good intentions，也就是依赖人们记得“哦，我们需要运行这些检查。

You can do CI gates, but it also goes so far, too. So, this is the part that I'm spending most of my time now. I think it's going to cost me, not cost me, it's going to be a one month more investment until I get something that works outside of my team as well. ”可以设置 CI gates，但它们的作用也有限。这是我现在投入最多时间的部分。我估计还需要大约一个月——不是成本，而是时间投入——才能让它在自己团队之外也有效。

主持人 Yeah, it's like people going off the paper road that you've defined and you're trying to have some principles in place to make sure they actually go back on track. 对，就像有人偏离你定义的 paved road，而你试图通过一些 principles 确保他们真正回到正轨。

嘉宾 Exactly like we discussed. Yes. You don't want to say this is the only road because it's nobody knows. 没错，正如我们讨论的。你不能说这是唯一的 road，因为没有人知道唯一答案。

主持人 There will never be only one road. 也永远不会只有一条 road。

嘉宾 The truth is always fragmented, right? There are multiple versions of the truth, you know, except certain facts, right? We don't truth 总是碎片化的，对吧？truth 有多个版本——当然某些 facts 除外。[笑]

主持人 we don't want to turn this political by accident. Um but with agents having every time there's an outage atropic, every time there's a new model, every time something happens, I notice there's a deep in quality. But it's difficult to measure. It's very difficult to do benchmarking. 我们可不想意外把话题变成政治。嗯。但每当 Anthropic outage、推出 new model 或发生其他变化时，我都注意到 quality 会下滑，却很难衡量。

I don't I barely trust his benchmarks nowadays as well and I have to have something that safeguards me from this deviations this quality differences and so forth because we're dealing with nondeterministic pieces, right? benchmarking 非常困难，如今我也几乎不相信那些 benchmarks。因为我们处理的是 nondeterministic 组件，需要某种东西保护自己，防范偏差和质量差异。

嘉宾 Yeah. You briefly mentioned LFA local first architecture and also specifically mentioned I wish I had known this. Could you explain that for the listener? 对。你刚才提到 LFA/local-first architecture，还特别说真希望早点知道。能向听众解释一下吗？

主持人 Oh man, this needs another podcast. 天哪，这得再录一期 podcast。[笑]

Um local first is imagine let me do the other way around. 嗯，local-first……让我反过来解释。

嘉宾 Typically we build architectures where you have a server somewhere cloud on premises you name it and you have a client that will have to um basically work with that transaction the API request you name it. You're typically going to have the API server somewhere not on the client and on the client you're typically going to have some level of caching if you will depending on what you're dealing with. 通常构建 architecture 时，会有一台 server，放在 cloud、on-premises 或其他地方；client 必须围绕那个 transaction、API request 等工作。 API server 通常位于远端而不是 client；client 上则根据情况有某种程度的 caching。

But nowadays there are newer technologies that the browser became so much more powerful in what it can do. I'll give you the example what I'm working on right now and why I had to do this. This is an engineering challenge. 具体取决于场景。但如今出现了更新的 technologies，browser 能力强大了许多。我举个正在做的例子，说明为何必须采用它。这是一个 engineering challenge。

主持人 We have offices in many parts of the globe at a and we have the application I'm building now helps you. 我们公司在世界很多地方有 office。

It's like a clone of the well architected uh tool but better at in my opinion like an engineer would have that this is built in Amsterdam and we're on premises even if we were cloud it would be the same issue now you want people in Singapore and Chicago and San Francisco to also do reviews and try to do live collaboration of a review the latency alone it's not going to make certain things fun and it's going to be hard and sometimes you're also going to have the issue If if I need to upload a I don't know 100 megabytes attachment that's also going to have because physics come into play. 我正在构建的 application 有点像 Well-Architected Tool 的 clone，但在我看来更好。假设一名 engineer 在 Amsterdam 构建它，系统部署在 on-premises——即使用 cloud，问题也相同。现在，你希望 Singapore、Chicago、San Francisco 的人也能进行 review，并实时协作。单是 latency 就足以破坏体验，让某些事情变得困难。有时还需要上传比如 100 MB 的 attachment；这也会受到物理规律限制。

How do you what you typically would do trying to solve this issue is easy. I add a CDN code that serves you static assets and serves you certain things and it gets you a a TLS handshake a TCP handshake but it's not really solving the problem. It's just basically a band-aid eventually going to have more problems. So a genius would think I can just use a distributed database. Let's use cockroach. Let's just use Postgres everywhere and just start adding everywhere. 通常解决方法很简单：加 CDN 来提供 static assets 等内容，省下一些 TLS/TCP handshake。但这并没有真正解决问题，只是贴上 band-aid，最终还会出现更多问题。于是，有人会聪明地想：直接用 distributed database，使用 CockroachDB，或者到处部署 Postgres。

But now you're basically dealing with a synchronization issue and now you got a distributed system. Good luck with this. It's not as simple as it looks. So the local first piece was how do I give people in different parts of the world the same experience to be as nappy as possible similar to Git where I do most of the transactions locally first. So think about transactional database locally 但现在你必须处理 synchronization，又拥有了 distributed system，祝你好运。它没有看起来那么简单。 local-first 的思路是：怎样让世界各地的人都获得同样轻快的体验，像 Git 一样先在 local 完成大多数 transactions。也就是说，在 local 拥有 transactional database，

嘉宾 and then I sync the parts that I actually need and to make it work. So now you're inverting the problem and you're creating a distributed data architecture where the client is a source of truth now which is usually unheard of. 然后只同步真正需要同步的部分。这样就反转了问题：你建立 distributed data architecture，client 现在成为 source of truth，这通常很少见。

主持人 Mhm. 嗯。

嘉宾 And then you're syncing to the server because you're going to have to have some sort of aggregation. 再把数据同步到 server，因为还是需要某种 aggregation。

主持人 So local first architecture is the principle that everything that you're going to do is going to do local first going to happen local first. local-first architecture 的原则，就是要做的一切首先在 local 发生。

But it doesn't prevent you from saying well this part of the page should actually be coming from server like analytics makes zero sense to do things in locally because you're going to blow up their storage right so there's new technologies that's called u opfs orange in private uh file system if I'm not mistaken if the server a http server web server respond with two http headers called cop and cop I can very long to explain what them but local first will tell This enables the browser to unlock a feature called um VFS virtual file system which I can now persist a file in your machine. 但它并不妨碍你说：页面这部分应该来自 server。比如 analytics 在 local 做就完全没道理，会撑爆用户 storage。现在有一种新技术叫 OPFS（Origin Private File System）。如果我没记错，HTTP/web server 返回两个叫 COOP 和 COEP 的 HTTP headers——解释起来很长——就能让 local-first方案启用 browser 的 VFS/virtual file system，把 file 持久化到你的 machine。

Oh,which is amazing. Yeah. But it's sandbox there's a bunch of restrictions is has to be there's a which is good thing it's a good thing. Yeah. But what he allows you to do is this idea of local first. 哦。这很棒。不过它在 sandbox 中，有许多 restrictions，必须如此。这是好事。对。但它让 local-first 成为可能。

Now when I load my application called where it can be anything the first page the shell which shows you something a distraction to bootstrap download a SQLite web assembly that will install on your machine create a new database run all the tables migrations and so forth in a few minutes 100 milliseconds and now every transaction happens locally. Okay. And now your server becomes more of a sync engine. Yeah. Less of the whole very large APIs and so forth. 现在加载我的 application——可以是任何应用——第一个页面，也就是 shell，先展示一点内容分散注意力，同时 bootstrap、下载 SQLite WebAssembly，把它安装到你的 machine，创建新 database，运行所有 table migrations 等，整个过程只需几百 milliseconds。之后每个 transaction 都在 local 发生。好。 server 则更像 sync engine。

This makes the whole experience feels like this is amazing. This feels like really snappy like it very looks any latency because everything's happening locally. It brings different challenges. Release has now become like open source in a way like you you do not break the client, right? You have to think about self-healing from the get-go. You have to think about migrations more carefully. You but you have so many other benefits as well. 对。不再需要大量庞大的 APIs 等。体验会非常棒，反应极其敏捷，几乎看不到 latency，因为一切都在 local 发生。它也带来不同挑战。 release 在某种程度上变得像 open source：你绝不能破坏 client，对吧？从一开始就必须考虑 self-healing，更谨慎地考虑 migrations。不过也有很多收益：server 和 API 变得更精简。

Your server, your API becomes much leaner. You have what? You have a bootstrap, you have a pull pull, you have a push and you have a workspace projection for only to sync the data for that particular user based on authentication, based on authorization. 你只需要什么？ bootstrap、pull、push，以及 workspace projection；后者仅根据 authentication、authorization，为该 user 同步对应 data。

嘉宾 I I will have to look into this. This sounds fascinating. 我得研究一下，听起来很迷人。

主持人 It is. I'm like I'm really loving it. It's I so much that I I pointed an agent to uh the the project I'm working on right now and I said look I want another local forest architecture with the privacy first in mind. So there's no database no server whatsoever. Everything happens locally 确实。我真的非常喜欢，以至于我把 agent 指向当前项目，对它说：听着，我还要一个以 privacy-first 为核心的 local-first architecture：完全没有 database server，一切都在 local 发生。

嘉宾 as a tool to help me prepare for midyear and annual performance reviews. So I have my own like uh record of achievements local first app. Everything's happen locally to me database there. If I want to export, I create a dump and it's fine. 它是帮助我准备 mid-year 和 annual performance reviews 的工具。我有一个个人 achievements 记录应用，所有内容都在自己本地的 database。想导出时就生成 dump，完全没问题。

主持人 Gotcha. 明白。

嘉宾 It's that's why another podcast. There's a lot to dive into. 这就是为什么要另录一期 podcast，里面有太多值得深入的东西。

主持人 I know I'm just I'm just trying to digest this. If you want if you're listening and you want an LFA local first architecture followup specifically with Hitler, let me know in the comment section. Yeah, let's go back to the development life cycle dev loop that we have here. 我知道，我只是在努力消化。如果正在收听的朋友想看一期专门和 Heitor 聊 LFA/local-first architecture 的后续节目，请在 comments 告诉我。 [笑] 好，让我们回到这里的 development life cycle/dev loop。

主持人 Yes. So we we talked about the plan on creating those ar those artifacts like the design the spec and the tasks and why you should not settled for the vanilla approach of using opensp spec or any framework for the matter but the go the secret is to codify your workflows your teams and eventually your company right and then you got to the apply which is effectively the implementation one of the tricks here for any spec driven development is that your context is now quite filled with a lot of information, but because you already externalize that context into artifacts design so forth, you don't need that baggage anymore. 好。我们谈过 plan，以及怎样创建 design、spec、tasks 等 artifacts，也谈了为什么不应满足于vanilla OpenSpec 或任何现成 framework。秘诀是 codify 你的 workflows、teams，最终 codify 整家公司。然后进入 `apply`，也就是 implementation。任何 spec-driven development 都有一个技巧：此时 context 已被大量信息填满；但因为这些 context 已经 externalize 成 design 等 artifacts，所以不再需要背着原有 baggage，否则每一轮、每一 turn 都会花更多token。

Otherwise, you're going to spend more tokens every round, every turn it takes. So, the apply is simply a moment where you say,"Let me clear the context." Yeah. Switch the model to something more mid tier or lower model if you will and let it execute. 所以 `apply` 就是一个明确时刻，你说：。 “清空 context。 ”对。

Now, this can go for all the way from 10 minutes all the way to maybe two hours depending on how complex this thing is. uh especially how many loops you have and so there's nothing really secret more of a autopilot now completely autonomous you're not in the loop the agents is driving everything yeah and you can drive multiple sub agents you can do orchestration you can do anything you want but openspec doesn't do anything secret it's just basically saying agent these are artifacts go that's basically what happens I think it's the simplest part I think it's fascinating that this concept of loop engineering and when people say I don't code anymore or it's easy to say, right? 把 model 换成 mid-tier 或更低 tier，让它执行。根据复杂度、loop 数量，这一步可以从 10 分钟到两小时。没有特别秘密，就是进入 autopilot，完全 autonomous；你不在 loop 中，由 agent驱动一切。对。你可以调度 multiple subagents，做 orchestration，做任何事。 OpenSpec 没有什么神秘能力，只是告诉 agent：这些是 artifacts，开始吧。基本就是这样，我觉得这是最简单的部分。我觉得 loop engineering 这个概念很有意思。

But if we look at so far kind of this workflow of discovery breakdown in items and then the the preparation, the customization, the guardrails already up front before that loop starts running is a lot of stuff that is pre-prepared. 人们很容易说“我已经不写 code 了”；但看看目前为止的 workflow：discovery，拆解成 items，之后进行准备、customization、预先设置 guardrails；loop 运行之前已经做了大量准备工作。

嘉宾 100%. I think it's the biggest lie to say even when um the marketing and the hype came out and saying we don't need engineers anymore. This problem is all solved. It was the same when I was doing service. 百分之百。最荒谬的谎言，就是 marketing 和 hype 曾声称：我们不再需要 engineers，问题已经解决。 serverless 当年也一样。

I was on the other side of the tape onto the provider and they said, "Well, you don't need many CIS admins anymore, many DevOps folks anymore because you don't need them to look at the server operations anymore." But it doesn't mean that their time is not no longer valued because it just moves higher up the chain. 我当时站在 provider 一侧，别人说：“你不再需要那么多 sysadmins、DevOps 人员，因为不需要他们盯着 server operations。 ”但这不代表他们的时间不再有价值，只是价值向链条更上游移动。

主持人 Coding was never really the bottleneck for the most part, but there was still very difficult coding that he was the bottleneck. We cannot lie. Especially C++ and a bunch of things that my god, I don't miss this. Uh but the value of thinking about what the problem is, how do we break it down, who's the customer, what the outcome is, how do we make it part of the business otherwise we're just playing, right? 多数情况下，coding 从来不是真正的 bottleneck；当然也确实存在非常困难的 coding，会成为 bottleneck，我们不能撒谎。尤其 C++ 等领域，天哪，我一点也不怀念。真正的价值在于思考problem 是什么、怎样拆解、customer 是谁、outcome 是什么、怎样让它成为 business 的一部分，否则只是在玩。

every developer before they became a developer dreamed of I would just code all day when they reach enterprise or they reach corporate like I'm mean meetings all the time like yes because coding is part of the problem part of the whole supply chain if you will but it's not the biggest part 每个 developer 入行前都梦想整天只写 code；到了 enterprise/corporate 却抱怨自己总在开会。是的，因为 coding 只是 problem、或者说整条 supply chain 的一部分，而且不是最大部分。

嘉宾 and the same for agents now I it came out today actually it was uh the blog post one of the most anticipated blog post about how did bun which is a nojs runtime if you willish rewrote from zigg to rust agents 也一样。今天刚好发布了一篇大家期待已久的 blog post，讲 Bun——一个类似 Node.js 的 runtime——怎样从 Zig 重写成 Rust，

主持人 and how we prepare the whole code base the patterns boring patterns that's basically what we're doing 以及怎样准备整个 codebase 和那些无聊但必要的 patterns。这正是我们在做的事。

嘉宾 when people say I don't code anymore I barely do anything and create a loop there's all this preparation because the agent starts fresh every time even if you create a memory MD or whatever people call these days it has to know what good looks like I was really looking forward to this blog post so I'm happy it's out yeah it came out this I was I was on the commute I was like yes I have to I have to read that as So there has been comments that people said specdriven development working with agents there is so much work up front that I would rather do it myself or I am faster manually and I think this work that you do up front for me is like an investment right you invest early 当有人说自己不再写 code，几乎什么都不做，只创建 loop 时，背后其实有所有这些准备。因为agent 每次都从全新状态开始；即使创建 `MEMORY.md` 或现在流行的其他文件，。它仍然必须知道“好”是什么样。我一直很期待这篇 blog post，很高兴终于发布了。对，今天刚出来。我通勤时看到，[笑] 心想：太好了。我必须读。有人评论说，和 agents 进行 spec-driven development，前期工作太多，还不如自己动手，或者手工更快。我觉得这些前期工作是一种 investment：早期投入，。

主持人 you reap benefits months down the line and it can be quite quickly if you're like I'm not going to invest but I'm just going to save and it's going to sit on my bank account then yeah at some point people are going to have bigger returns higher dividends bigger reap of rewards on their investments they made early on. For me, this is quite comparable. 数月后收获收益；有时回报还会很快。如果你说“我不投资，只储蓄，把钱放银行账户”，那么过一段时间，别人早期 investments 带来的 return、dividend 和 reward 自然更高。

So, it's it's a shame where I see people not investing in not just their own workflow, but how does this scale in teams or in organizations or thinking and experimenting because right now everyone's experimenting. So, right now is the time to experiment. I would say this is the discussion we're having about um investing in adjacent roles or SKs in adjacent places. So, you can use this. I'll give an example for this. 我觉得二者很相似。因此，当我看到人们不愿投资自己的 workflow，也不思考它怎样在 teams 或 organizations 中 scale，不去思考和实验，会感到可惜。现在所有人都在实验，因此现在正是实验的时机。我认为这也和我们谈的投资相邻 roles 或 skills 有关。举个例子：执行 `apply` 时，在最后极少数 tasks 中，有一个叫“更新 decision log”。

When you we do an apply, one of the tasks at one of the very few and at the end of the task that we do is something called a update decision log and we keep a a log of every decision we made in the project with the reason the why almost like an ADR but a very lightweight one and yesterday I created something I'm very proud of as I still have two more to create but now still thinking about how do we think about open source at a so forth it's called slash onboarding is a command as a skew as where you you will try to scan your project for the likes of code owners,git log, git branches, docs, opensp spec if there's any or any spec for that matter and then we will give you a high level review of how what's the architecture of the project is what are the main decisions what are the stable areas of the project unstable areas who are the people that are likely know more about this area that you should talk to and then guide you through a personalized on boarding. 我们记录 project 中做出的每项 decision 及其 reason/why，几乎像轻量版 ADR。昨天我做出了一个很自豪的东西——还有两个要做——同时继续思考公司怎样对待 open source。它叫 `/onboarding`，是一条 command，也是一项 skill。它会扫描 project 中的 CODEOWNERS、git log、git branches、docs、OpenSpec（如果有）或其他 spec，然后提供高层 overview：project architecture 是什么？主要 decisions 有哪些？哪些区域稳定、哪些不稳定？哪些人可能最了解某个区域，应该去和谁交流？之后它会引导 personalized onboarding：你完全不了解吗？

Do you know nothing about this? you know some areas you want to dive into this area do you want me to create an interactive HTML and you go from there so this investments usually pay off when you think about teaming based and if you come from an open source uh background you're always thinking how do I make it easier for someone to contribute 已经了解一些 areas，想深入这个 area 吗？你希望我创建 interactive HTML 吗？然后就从那里开始。这些 investments 在基于 team 思考时通常会产生回报。如果有 open source 背景，你总会问：怎样让别人更容易 contribute？

嘉宾 but also how do I make it harder for someone malicious to try to contribute something they shouldn't be contributing to begin with 同时怎样让 malicious actor 更难贡献一开始就不该加入的内容？

主持人 so agents are not so different from this agents 和这没有太大不同。

嘉宾 gotcha I also wanted to make it explicit this is the first time where it's just is just agent right running in a loop and you mentioned it could be 10 minutes it could be 2 hours have you thought of where the agent runs is that locally on someone's laptop is that remotely so they can shut something down they don't have to have their laptop open I see memes with people walking and their lid is like a little bit open so the agent can still run in these loops 明白。我还想明确指出：这是第一次，流程中只有agent 自己在 loop 里运行，对吧？你说它可能运行 10 分钟，也可能两小时。你考虑过 agent 在哪里运行吗？是在某人的 laptop 本地，还是 remote environment？这样人可以关掉设备，不必一直开着 laptop。我见过 memes：人走在路上，laptop 屏幕盖只留一条缝，好让 agent 继续跑 loop。

主持人 what are your thoughts on that 你怎么看？

嘉宾 we do everything locally today we have experiments going on trying to run into a remote machine and so forth but I would say we're very early on this one Uh it's not very different from remote developer machines. I used to work with media companies uh back in the days uh like broadcasting companies back in London and some of those were used to use remote developer machines as a way as a safety measure. For instance, you lock everything down and so forth. 今天我们一切都在 local 运行，也在实验 remote machine 等方案，但我。会说这方面还处于非常早期。它和 remote developer machines 没太大不同。以前我服务过 London 的 media/broadcasting companies，它们曾把 remote developer machine 当作安全措施：把一切锁定。

But he also creates a friction when it comes to developer experience certain things you can do. 但这也会给 developer experience 和某些操作制造 friction。

主持人 So I don't think we're there yet. For now all of this is running locally. 所以我觉得还没到成熟阶段。目前这一切都在 local 运行。

嘉宾 Yeah. They except the last parts where we do additional review gates which it happens with a tool I'm really loving enough. It's not a full endorsement by the way. 对。唯一例外是最后的 additional review gates，它们使用一个我很喜欢的工具——顺便说，不算全面 endorsement，

主持人 I'm not sponsored. 我也没有拿赞助。[笑]

嘉宾 It's called code rabbit. 它叫 CodeRabbit。

主持人 If you want to sponsor me, let me know. 如果你们想赞助我，请联系。

嘉宾 True. Yeah. So those things are becoming more and more useful now. What happened at the CI site? 确实。这些东西现在越来越有用，是在 CI 端执行的。

主持人 Gotcha. And when you say local, is it then still in some type of sandboxed environment or do people run the risk of this loop kind of going ham? And we prevented that by all the work up front. Not not neither of those. So it's still local, but one of the we're dealing with agent, right? We're dealing with money,money movement, and a bunch of things. So we need to be very careful in what we do. 明白。你说 local 时，它仍在某种 sandboxed environment 里吗？还是存在loop 彻底失控的风险？前期那些工作已经阻止了这种情况吗？两者都不是。它确实在 local，但我们处理的是 payments，对吧？涉及 money、money movement 等许多事情，所以必须非常谨慎。

Um there's tools like factory droids where you can have enterprise governance for instance. You can prohibit certain levels of commands, certain levels of things should be used. Even if an agent tries you say prohibited or sometimes you will say oh uh this is actually uh advised against by organizational policy I need your explicit permission to be able to run this for example. So there are levels of these things 有 Factory Droid 这类 tools，可以提供 enterprise governance。例如，可以禁止某些级别的 commands，规定某些操作不得使用。即使 agent 尝试，也会被告知 prohibited；或者系统会说：organization policy 不建议这样做，我需要你的 explicit permission 才能执行。它有不同层级的控制。

嘉宾 even for agentic workflows. Yeah, 即使 agentic workflows 也如此。

主持人 especially for that. 尤其如此。

嘉宾 I'll give you an example. As soon as you start using agents and use Kubernetes and agent was like, "Yeah, let me just delete this bot. Let me just delete this thing. 举个例子：一开始用 agents 操作 Kubernetes，agent 可能说：“好，我来删除这个 pod，再删掉这个东西。”

主持人 We need to 我们得……

嘉宾 Yeah. So you kind of can't. Okay. 对。[笑] 所以它就是不能这样做。好。

主持人 Uh let me try to remove the entire directory of home directory." So you just can't. 或者“让我删除整个 home directory”，也绝不能允许。

嘉宾 Good. 很好。

主持人 Uh so there are things that you can do nowadays with AI and enterprise with governance. 现在 AI enterprise 产品已经能提供这些 governance 控制。

嘉宾 Yeah. And factory droid is something separate from the open source droid agent harness, right? 对。Factory Droid 和 open-source Droid agent harness 是不同东西，对吧？

主持人 Yes. So the droid itself is the harness which is kind of open source but all of these companies now are investing into this enterprise governance if you will open code from DAX is the same idea as well. So the harness is where you do all these amazing things but you but like any remote development environment in cloud you're going to have to have policies somewhere. Gotcha. Interesting. I'm also going to look into this. 对。 Droid 本身是某种 open-source harness；但如今所有这类公司都在投资 enterprise governance。 Dax 的 OpenCode 也采用相同思路。 harness 让你完成所有这些很棒的事，。但就像 cloud 中任何 remote development environment 一样，某处必须存在 policies。

We we have been investigating kind of local sandbox environments where we want people to have comfort and more confidence running agents for longer times, right? If it's 5 minutes, it's okay. You can still kind of look at your screen and be like, "What is it doing?" But when we're talking about 2 hours, no one's going to sit for 2 hours and stare at the screen to make sure it doesn't delete the home directory. And if it does, you might still be too late cuz you were sleeping. 明白，有意思。我也要研究。我们一直在调查 local sandbox environments，希望大家更放心、更有信心让 agents 长时间运行。如果只有五分钟，还可以盯着屏幕问“它在做什么？ ”但运行两小时，没有人会坐在那里盯两小时，确保它没有删除 home directory。如果它真删了，就算人还没睡，也可能来不及。

嘉宾 Yeah. 对。

主持人 So, you want something in place. 所以需要一些保护。

嘉宾 Yeah. We heard stories about this, but yes, I mean, you can you can use hooks in literally every harness right now to prevent some of those things, 对。我们确实听过这种故事。现在几乎每个 harness 都可以用 hooks 防止部分危险行为。

主持人 but you're not dealing with if you're dealing with a few developers, sure. But if you're dealing with thousands of developers, then the conversation becomes different. 如果只是少数 developers，当然容易；但面对几千名 developer，对话就完全不同。

嘉宾 Yeah. I want to zoom into hooks since you mentioned that. For me, let's let's start with what what is a hook to to make sure the listener understands. Sure. So, a hook similar to anything that happens in your machine, it usually generates an event of a kind. Sometimes it's a log, sometimes an instruction to a computer to follow and off of that off of that event something will happen. 对。既然提到 hooks，我想深入一下。先从定义开始，确保听众理解：hook 是什么？好。和 machine 上发生的任何事类似，一项操作通常会产生某类 event。有时是 log，有时是给 computer 的 instruction；event 发生后，会触发另一个动作。

So if you're running an agent on your machine through open code, cloud code or codeex or any of those things or factory droids, there are certain decisions or checkpoints if you will that those events will be emitted. So before I run a tool, after I run a tool or I'm running the tool or something like this, you can intercept that event and say on top of the instruction you were meant to do, do this other thing. 如果在本机通过 OpenCode、Claude Code、Codex、Factory Droid 等运行 agent，在某些 decisions 或 checkpoints 上会发出 events。例如 tool 运行前、运行后、正在运行时。你可以 intercept 这个 event，并说：在原 instruction 之上，再做另一件事。

So for instance, you can say before you return the control to the user to say I've done it, run pre-commit hooks. So you know for sure they're always going to be run it. But it's not a smart way to do it. A smarter way to do is to do at the pre-commit hook. So if git is going to make a commit to this, it's going to tap into a hook event that you can now run certain commands and to say abort this operation. 例如，可以规定：把 control 交还给 user、声称“我完成了”之前，先运行pre-commit hooks。这样你知道它一定执行。但更聪明的方式，是直接放进 Git pre-commit hook。当 Git 要 commit 时，触发 hook event，运行指定 commands；不通过就 abort operation。

So the hook is basically event driven but from a process from a tool point of view. 所以，hook 基本是从 process/tool 视角实现的 event-driven 机制。

主持人 Mhm. And does it does a hook run when a loop is done or does it run with one iteration of a loop? 嗯。hook 是在整个 loop 完成时运行，还是每次 iteration 都运行？

嘉宾 It would it depends on where from the one we just discussed. will typically be from an iteration of the loop. 取决于放在哪里。刚才讨论的 hook 通常属于某次 iteration。

主持人 Yeah. 对。

嘉宾 But you typically want to have your own hooks baked if in in some ways. A loop is nothing more but a hook in a way. 但一般希望有一些自己内置的 hooks。从某种角度说，loop 本身也不过是一种 hook。

主持人 Gotcha. For me, the the concept of hooks are incredibly powerful. 明白。对我而言，hooks 这个概念极其强大。

嘉宾 I want my code to be easy, simple to change. I've said that many times. I've been inspired by one of the guests to say that. And you still want that when your agent is performing the code execution for you, right? when you're not doing it hands-on but when your agent is typing the code or generating the code rather. 我希望自己的 code 易于修改、保持简单。我说过很多次，这句话来自一位嘉宾的启发。即使由 agent 替你执行 code，你依然希望如此，对吧？你不亲手操作，但 agent 在输入、或者说生成 code。

So those conventions of code quality standards specifically in our repository or for a paved road for a specific technology I think we should move that as much as we can in determinism and hooks are a way to do that right your linting or sgrip rules I've seen people do things with or making sure there's certain security standards that are there or as much as you can conventions so the code is more predictable in terms of its quality structure architectural decisions Because in the end, I also feel like this investment is going to pay dividends because someone has to review that code. 因此，针对 repository 的 code quality standards、某项 technology 的 paved road 中的 conventions，我觉得都应该尽量转移到deterministic 层，而 hooks 正是方法之一。比如 linting 或 Semgrep rules；我也见过有人用它们确保 security standards、各种 conventions 得到遵守，使 code 在 quality、structure、architectural decisions 方面更 predictable。

And if you continuously have to review structure, you're going to have so much fatigue because we can go extremely fast in generating code. But when you have to review everything like it was written from scratch by someone who has no idea what they're doing and does not adhere to any of the conventions or it's more of a coin flip, sometimes yes, sometimes no, you lose your edge and you lose your cognitive load quite quickly. 最终，这种 investment 会产生回报，因为总得有人 review code。如果每次都要 review structure，会出现严重 fatigue。我们生成 code 的速度极快；但如果每次都必须像审查一个完全不懂行、也不遵守 conventions 的人从零写出的代码，结果像抛硬币一样时好时坏，你会迅速失去优势，也会迅速耗尽 cognitive capacity。

I'm smiling because I the reason I spent this um the last few months which I mentioned that was the hardest to make it team based is because I codify this exactly what you're mentioning now which is we're going to call it at the end of this uh this this image called slash retro. 我在笑，因为我过去几个月投入最多、也就是刚才说最难变成 team-based 的部分，恰好就是 codify 你说的这些。在这张图的最后，我们把它叫 `/retro`。

主持人 Yeah. 对。

嘉宾 Um when we do this continuing this when we do the implementation of it you typically do this ad hoc prompting if you will to fix certain things you don't like the way the test was structured. It doesn't matter how many SKs you have, it will happen. It's bound to happen. And that's when the quality gaps are happening. And that's when you start losing the trust a bit on whether he's doing what you're what you're supposed to be doing, the quality gates and so forth. implementation 过程中，通常会使用 ad-hoc prompting 去修正不喜欢的地方，比如 test structure 不符合预期。无论有多少 skills，这都一定会发生。而 quality gaps 正是在这里出现；你开始稍微失去 trust，不确定 agent 是否按照要求行动、是否通过 quality gates。怎样让它更 deterministic？

Is this more deterministic? How do you bring some of these things? The way I'm solving this now is in two ways, two checkpoints, not hook. We run as part of the openspec plan we run roughly 15 adversarial reviewers for the changes are being made. So think is Python code being touched? 怎样把这些规则带入流程？我目前用两个 checkpoints 而不是 hook 来解决。在 OpenSpec plan 中，会针对 changes 运行大约 15 个 adversarial reviewers。

You're going to run a Python adversor reviewer go same TypeScript same Postgress wait look at the queries that are being created or look at the DDLs that are being created for the way creating tables already are making changes this is going to cause data loss the reviewer will be able to catch it. 比如涉及 Python code，就会运行 Python adversarial reviewer；TypeScript 同理；Postgres 也一样。它会检查 queries 或 DDL：现在创建 tables 或修改结构，是否会导致 data loss？ reviewer 能捕获这类问题。

So you run all of these things locally, but we can also run at the CI and this will generate an attestation like we do in in high stake releases like I used to do in open source that every release it would generate an attestation in a provenence to prove all the steps that it took to be able to generate that release to begin with the CI/CD the jobs the environment variables commands and so forth all recorded and I'm doing the same idea from for as a merge check to prevent agents to fabricate evidence that they run tests that they did things that they were supposed to do. 这些检查既可以在 local 运行，也能在 CI 运行，并生成 attestation。就像我以前在 open source 做 high-stakes release 时，每次 release 都会生成 attestation 和 provenance，证明生成该 release 经历的所有步骤；CI/CD、jobs、environment variables、commands 等全部记录。现在我把同一理念用于 merge check，防止 agents 伪造 evidence，声称运行过 tests 或做过应该做的事。

So every change, every commit that you do would always have to accompany a cycle of a review based on the changes. So think you have a floor of always running security reviews. They always have to happen 因此，每项 change、每次 commit 都必须伴随一次基于 changes 的 review cycle。它有一条始终执行的底线：security reviews 永远必须运行。

主持人 always. 永远。

嘉宾 But you're also going to have conditional reviewers like is this if it's not touching Python, why would you run it? If it's not touching documentation, why would you run it? So I have this kind of a floors from security and outcome verification and also a conditional one that would run as these things run and I have a deterministic scripts that would verify if they actually run. 同时还有 conditional reviewers。没有修改 Python，为什么要运行 Python review？没有碰 documentation，为什么要运行 documentation review？所以既有 security 和 outcome verification 的固定底线，也有根据 changes 运行的条件检查。

Did they actually read those any files the hooks and a few other things if they did then we can generate an attestation with all the evidence to test the findings the things that need to be fixed and this gets validated at CI which premputes everything. It's a bit more complex than this but this is the simplest form I can do. That's why I'm calling a merge check. 我还有deterministic scripts，验证 reviews 是否真的运行：它们是否确实读取过相关 files？ hooks 和其他机制是否执行？如果执行了，才能生成带有全部 evidence、tests、findings 和待修复事项的 attestation；CI 再验证这些内容，防止伪造。

Once this happens, after we conclude this whole development cycle,the biggest learning I've had over the last 6 months is you tend to forget that because agents are doing everything for you, some of those things could be deterministic. But after you run a session for like three, four, seven hours, you're exhausted. The last thing you want is to think about what could this be a llinter? What could this be a custom rule or something or formatting rule? You just forget. 实际更复杂，但这是我能给出的最简解释，所以称它为 merge check。完成这一步、整个 development cycle 结束后，过去六个月我最大的发现是：agents 替你做一切时，你往往忘了其中一些事情其实可以 deterministic。但一个 session 运行三、四甚至七小时后，人已经筋疲力尽，最不想思考的就是：这能否变成 linter？能否做成 custom rule 或 formatting rule？

So I built a command with expiration from an Icelandic company from a friend of mine called / retro where you're having the same socratic method 你会直接忘记。所以我构建了一条 command，灵感来自一家 Icelandic company 的朋友，叫 `/retro`。它也使用 Socratic method，

主持人 but looking at the last session or the current session you just had and figured out what is it that you had to course correct the agent because you went ballistic, you went haywire or you didn't do what you actually wanted to do or things that you had to fix mentally because you know the agents sometimes doesn't do that much as a good job. It happens or that it simply you don't know how to make this more deterministic. 但审视刚结束的 last/current session，找出哪些地方迫使你 course-correct agent：它是不是？彻底失控、偏离方向，没有做真正想要的事？或者有哪些问题你不得不凭经验在脑中修正，因为 agents 有时。确实做得不够好；这种事会发生。也可能是你根本不知道怎样让过程更 deterministic。

嘉宾 So what this retrocomand does is interviews you. It looks into your whole context and sessions and so forth and figures out these are all the threads I can notice that we can have the discussion. We can dive into this and at the end this is a table of everything that could be made deterministic now `/retro` command 会采访你，查看完整 context、sessions 等，找出所有值得讨论的 threads。你们可以逐个深入；最后生成一张表，列出哪些内容现在可以 deterministic，

主持人 and everything else that could actually be nondeterministic but more lightweight less instructions or less something and this is how I used to improve this whole loop of development to introduce a merge check to introduce one reviewer at a time to introduce custom linting roles to introduce architecture guards to prevent a file importing some other file that shouldn't be because we're using ports and adapters and such. 以及哪些仍然可以。保持 nondeterministic，但减少 instructions，让它更 lightweight。我就是这样持续改进整套 development loop：加入 merge check；一次增加一个 reviewer；加入 custom linting rules；加入 architecture guards，防止某个 file import 不该 import 的 file，因为我们使用 ports and adapters 等架构。

嘉宾 So, it kind of becomes a continuous improvement. 所以它变成了 continuous improvement。

主持人 I was actually thinking since we've gone through this and there are tidbits that I want to put into practice myself first and foremost, but I also think from a listener's perspective, they might want to try this out. Are you planning to open source this? Is this available? Where can people find this? This is not yet open sourced. 我刚才。其实在想，既然我们已经。讲了这么多，其中有一些细节我自己首先就想实践；从听众角度看，他们可能也想试。你计划 open source 吗？目前可用吗？大家在哪里能找到？ [笑]现在还没有 open source。不过节目发布后，我可以在 YouTube video 下评论，提供一个 sample。

Uh, but I can make a comment on YouTube video after the fact uh with a sample of what it is. uh but we are discussing how ways of doing open source at engine and not only this work there's retro there's on boarding I'm now doing offloading when you're going when I go for holidays for instance or when you got just got back from vacation there's a few little tricks that you can do or even our own openspec custom workflow with all this merge verification loops if you will framework that I'm trying to build 嗯，我们正在讨论公司里怎样做 open source，而且不只针对这项工作。还有 `/retro`、`/onboarding`；我现在还在做 `offloading`，用于休假前，或者刚度假回来时，有几个小技巧。也包括我们自己的 custom OpenSpec workflow，以及我正在构建的整个 merge verification loops framework。

嘉宾 we're looking into this but if you were to try Now it's could be as simple as instruction as you are a agent specialized in help me reflect and find optimizations for my development workflow. Your job is very simple to look at into my context. Look into my previous session or my current session and ask me if I have any notes or what went wrong, what didn't go so well. Interview me. Use socratic method. Find the threads until there's nothing left. 我们都在研究是否开放。但如果你现在就想尝试，可以只写一段简单 instruction：[吸气] “你是一名专门帮助我反思、寻找 development workflow 优化点的 agent。你的工作很简单：查看我的 context，查看 previous/current session，然后问我是否有 notes，以及。哪里出错、哪里做得不够好。采访我，使用 Socratic method，沿着 threads 深挖，直到没有遗漏。

Once you have a better picture and you know precisely there's no other outstanding topics or if the user says so then create a table showing what exactly could be made deterministic so my user or us spend less effort less fighting less frustrations because we have a life outside job as well and what is it that could be additions to our nondeterministic ways of doing things could be a reviewer could be something else. 对情况形成更完整的图景，确认没有 outstanding topics，或者 user 明确表示可以结束后，创建一张表，准确展示哪些内容可以变得 deterministic，从而让 user 或团队花费更少 effort，减少争执和 frustration——毕竟我们在工作之外也有生活——以及能给 nondeterministic 工作方式增加哪些东西，比如 reviewer 或其他机制。

So make it look nice and it's just a simple table that you can I the user can ask questions if if needed 把它整理得清楚美观，做成一张简单 table，必要时 user 可以继续提问。 ”

主持人 and that's basically what wet is like 30 lines if I'm honest but just that thought of having something that you you can call at the end of a session or maybe after two three sessions I don't know keep notes somewhere on paper or I just keep a note like uh retro.md out in my home directories I keep notes of my frustration my frustration and things like, "Oh my god, Opus was doing fine. What happened here?" It happens. 这基本就是 `/retro`，坦白说只有约 30。行。但关键是拥有一个能在 session 结束后、或两三个 sessions 后调用的东西。不确定的话，可以在某处保留 notes；我在 home directory 外放了一个 `retro.md`，记录自己的 frustration，比如：“天哪，Opus 原本做得很好，这里发生了什么？

Um, and and I feed this later during the retro and then he keeps finding an amazing things. ”[笑] 这种事会发生。之后我把它提供给 retro，它总能找到一些惊人的东西。

嘉宾 But I have to warn you that if you're a perfectionist like I am, you're going to want to keep running these retros for a long time. And then sometimes you might get to bring your pragmatism a bit more because there's always going to be areas to improve. There's always going to be ways to do things. But for me, my favorite is moving from, oh, I love these agents. I trust these agents. And now agents are actually not doing the things they're supposed to be doing. 不过必须警告：如果你和我一样追求完美，会想长时间不断运行 retros。这时可能需要多一点 pragmatism，因为总有可以改进的 areas，总有不同做法。对我来说，最重要的是从“哦，我喜欢这些 agents，我信任它们”，变成“现在 agents 没做应该做的事”。 trust 开始下降，出现 trust loss and recovery。

Then it goes into this trust and uh the loss of trust and recovery uh idea. And then for you to get back to the baseline of the trust you had, it never gets there. It will increase slowly as it gets right. But this idea of a retro start moving. Maybe I could do a custom linting rule to prevent writing test this way, writing code this way. 之后即使表现改善，也永远回不到原来的 baseline；trust 只会随着它持续做对而缓慢上升。但 retro 能推动改进：也许可以写 custom linting rule，防止以这种方式写 test、或者写 code。

I learned recently in Go that we have the Golen CI uh linked tooling that you have a dependency guard feature that retro told me about and I was like yes you can do this thing. So then this there's the import will never happen and your binary remains less than 3 megabytes. I'm like 最近我才知道，Go 的 golangci-lint 工具里有 dependency guard 功能，这是 retro 告诉我的。我想：太好了，原来能这样做。设置后，某种 import 永远不会发生，binary 也能保持小于 3 MB。

主持人 perfect let's just do it. So this is something that's going to be highly personalized. So it goes back to the premise of if you ever worked in open source before. It's an edge for you because you're always trying to think of how do I make it easier for someone to contribute maybe the first time maybe recurrent. How do I prevent malicious actors or even yourself in a bad day in a tired day it will happen 完美，直接做。它会高度 personalized。这又回到最初的前提：如果做过 open source，你就拥有优势，因为总会思考怎样让别人更容易 contribute，无论第一次还是反复贡献；也会思考怎样防止 malicious actors——甚至状态不好、疲惫时的自己，这一定会发生——。

嘉宾 from that risk to get into your project. But what we missed in open source was this idea of I'm getting close to my end of my day. My battery is running low and I can remember these things. But you now have a log of everything that happened. So now I can use an agent to do what they do best. Look up heaps of data, lots of things and find meaning somewhere there. 把风险带进 project。但 open source 过去缺少一种能力：当我接近一天结束时，精力已经很低，没法记得所有事情。现在却有一份记录一切的 log，可以让 agent 做它最擅长的工作：检查海量 data 和内容，从中找到 meaning。

主持人 Yeah, this kind of self-inter looking at my session logs and improving from there. I feel like I can do that. And if I revert back in time, if I was doing this when I was early in career, I feel like this agent and this way of giving feedback is going to have me make a lot of decisions. A lot of decisions that I don't even have a clue on how to make, right? Oh, did you know X, Y, and Z? You can do this in this llinter. 对，这是一种 self-introspection：审视自己的 session logs，再据此改进。我觉得自己能做。但如果回到职业生涯早期，我当时也这样做，这个 agent 和 feedback 方式会让我必须做很多 decisions，而其中许多我根本不知道怎样做。比如它说：你知道 X、Y、Z 吗？可以在这个 linter 中实现。

I'm like, well, I didn't even know what we're doing right now. So, how much do I need to use my own critical thinking or how much can I let the agent kind of also advise me and inform me and kind of be my guider there? What's your advice? 我却想：我连现在做的东西是什么都还不懂。所以，多少部分需要依靠自己的 critical thinking？多少可以让 agent 提供 advice、information，做 guider？你有什么建议？

嘉宾 It would it would always be a a bit of both, right? I'll give an example that happened yesterday. Yesterday I was refactoring a I'm building an entire CI automation for GitLab because I I miss dearly GitHub in certain aspects of things. Um and I I wanted to have a way for anyone in the company at agent to say include the merge check includes as attestation to make sure that the agent are not lying to you fabrication but it's supposed to be just a single line. 始终是二者结合，对吧？举个昨天发生的例子。我正在 refactor 一套为 GitLab 构建的完整 CI automation，因为有些方面我非常想念 GitHub。嗯，我希望公司里任何人都只需加入一行 `include merge-check`，就能包含 attestation，确保 agent 没有通过 fabrication 欺骗你；它应该真的只要一行。

So this but I also want to have protections at alter code altering time to prevent this part of the code should have no side effects. There should be no calls, networking calls, io's should only be saying this is the hook I received or event I received and add a label that should be an action remove a label or something then something else would control the side effects makes it easier for test make things testable. 但我也想在修改 code 时提供 protections，确保这部分 code 没有 side effects：不能发 calls、networking calls 或 I/O，只应说明“这是我收到的 hook/event”，然后增加一个 label 作为 action，或者移除 label；其他组件再负责控制 side effects。这样更容易测试，也让一切 testable。

What the agent understood was okay sure no problem one line fine and then he created an entire refactoring plan where he was like all you need is two docker images and all these different deployments three different repositories I'm like no I like that you're thinking about docker images have it self-contained but for there's three different concerns here one of them is customer first how do I make it so easy that they just include and that decision fatigue goes goes away. agent 的理解是：好，没问题，只要一行。然后它创建了完整 refactoring plan，声称只需要两个 Docker images、各种 deployments、三个不同 repositories。我说，不。 [笑] 我喜欢你考虑了 Docker images 和 self-contained，但这里有三个不同 concerns。第一是 customer-first：怎样做到极其简单，让他们只需 include，decision fatigue 随之消失。

Second, how do I prevent myself from accidentally editing things that I shouldn't be editing? So, my architecture that started well and now became a spaghetti, but also how do I prevent an agent to basically lie to me and start editing these things because they have free will to a degree, right? 第二，怎样防止自己意外编辑不该编辑的东西？否则 architecture 起初很好，后来变成 spaghetti。也要防止 agent 对我撒谎，开始编辑这些内容，因为它在某种程度上有 free will，对吧？

主持人 And then the last one is how do I make this deployment easier so it doesn't become a burden for me to now maintain this whole thing because complexity never goes away. You're just shoving it somewhere else. I don't want to deal with that complexity even though I'm trying to make it as easy as possible to the user. If that's going to be an uneven calculus, then I want to shift the balance a bit more. And then that critical thinking has to happen. 最后一项是怎样让 deployment 简单，避免整套系统的 maintenance 变成我的 burden，因为 complexity。从不会消失，只是被塞到别处。我不想承担那份 complexity，尽管又要让 user 尽可能简单。如果计算结果不均衡，就要重新调整平衡。这里必须发生 critical thinking。

嘉宾 This is where sometimes it's hard for new engineers or engineers that haven't been long enough or have made enough mistakes. I made more than I can count. 这对新 engineer，或者从业时间不长、还没犯过足够多错误的 engineer 很难。我犯过的错误已经多到数不清。

uh to be able to have this kind of a forward thinking look and then say actually agent you did great for now but don't do this. The way you can counter this balance if you don't have enough of experience to have critical thinking or to read enough code or to have enough scars hopefully don't have that many uh is to run cycles of adversarial reviewers. 要有这种 forward-looking 视角，说“agent，你目前做得很好，但不要这样做”并不容易。如果经验不足，尚未形成 critical thinking、没有读过足够多 code，或者没有足够多伤疤——希望你别有那么多——可以通过多轮 adversarial reviewers 来平衡。

So you can always say for instance bring Fable and say use our judgment to when to launch other lower model less capable models than you to review the work that you're doing and then bring from a security point of view from a customer point of view and this is something that I even accidentally discovered that you can do this from a product point of view as well. You can create a PRD. You can create everything else. 你始终可以引入 Fable 之类的强 model，让它自行判断何时启动其他能力较低、成本更低的 models 来 review 当前工作；再分别从 security、customer 等视角 review。我还意外发现，product 视角也能这样做。

And you can say this is the type of customer I'm trying to get you the market or the segment. Create a syntactic customer for this, for this, and review these things. 你可以创建 PRD 等全部内容，然后告诉它：这是我想进入的 customer market 或 segment，为此生成一个 synthetic customer，并让它 review 这些内容。

主持人 So then you get different findings and then find what's common and then let's do it. Yeah, 这样会得到不同 findings；找出共同部分，然后执行。

嘉宾 it's not going to solve you not having any critical thinking, but it's going to reduce like an architect, your your main role is trying to not only make everyone else around you smarter, but also trying to reduce the risk for that decision. 对。它不能替代你缺失的 critical thinking，但能降低风险。就像 architect 的主要职责，不只是让周围所有人更聪明，也要降低这个 decision 的 risk。

主持人 Gotcha. 明白。

嘉宾 So, you can do it with agents as well. agents 也可以这样使用。

主持人 Yeah. I love that. Like even as you're explaining this, you communicate that this is something I figured out recently, right? Or something that I explored and now I learned and then I put it into practice. It really highlights that a lot of what we learn now and even what we communicate is so fresh that it would be a shame to not try things out and to experiment and to learn and to cuz I feel like earlier in software engineering there was not as much innovation for me. 对，我很喜欢。就连你解释这些时，也会明确说这是最近才弄明白、刚探索并学会，然后投入实践的东西。这凸显出：我们现在学到、交流的许多内容都非常新鲜；如果不去尝试、实验和学习，会非常可惜。因为我觉得过去 software engineering 并没有这么多 innovation。

This is right now a very cool time to start innovating to start learning to see what you can improve and I've been having a lot of fun doing it to be honest. Yeah, 现在是开始创新、学习、寻找改进点的好时代。坦白说，我也从中获得很多乐趣。

嘉宾 I think so as well. Yeah, I I I'm I'm having so much because I think the more experience you have, the more dogmas you also acrewue and then this age now it's like actually we could do something else. 对，我也这么觉得。我很开心，因为经验越多，累积的 dogmas 往往也越多；而这个时代告诉我们：其实可以换一种做法。

主持人 I was having this discussion again with a friend of mine, principal engineer, brilliant guy. It's like I kind of look up to him when it comes to rust like he's the genius of rust. Um, one of the things that he's doing, Nicholas, please uh forgive me for saying for sharing some of your brilliant work ahead of time. 我最近又和一位朋友聊过。他是 Principal Engineer，非常出色；在 Rust 方面我很敬仰他，简直是 Rust 天才。他叫 Nicholas——请原谅我提前透露你这项精彩工作。

Uh, but he's looking at how do we make sure that we have engineering design discussions in a structured way in a way that you can feed it to agents or you can do other things for instance almost like a decision of record but heavier on tech. And when I looked at the document with him yesterday, one of the things that struck me was like this is very Amazonian 嗯，他正在研究怎样以结构化方式开展 engineering design discussions，让内容可以交给 agents，或者用于其他事情；有点像 decision record，但技术内容更重。昨天我和他一起看 document 时，一个强烈感受是：这非常 Amazonian。

嘉宾 on having this all of these things so well thought out that you have to go and answer and have to go and write. But I also know from open source that when people see this they will fear they will shy away. they will just do the very minimal or they will probably just use shachi pt gemini or whatever to just try to write it down and then the cold critical thinking goes out the window 每件事都经过充分思考，你必须逐项回答、逐项写下来。但 open source 的经验也告诉我，人们看到这种东西会害怕、退缩，只填写最少内容，或者直接用 ChatGPT、Gemini 之类代写，结果 critical thinking 被完全抛到窗外。

主持人 what we can do what about I I I showed him this loop that we're just discussing now what if we have a skill that uses that piece or a command I think is better than sq uses the pieces as a template as a starting point but use socratic method and makes this part of the workflow so Then when you're trying to do the first brainstorming or explore opensp spec or whatever now you're embedding resilience uh aspects to things. 我们能怎么做？我给他看了刚才讨论的 loop。如果有一项 skill 使用 document 作为 template 和起点——不过 command 可能比 skill 更好——再用 Socratic method，让它成为workflow 的一部分。这样第一次 brainstorming，或者运行 `openspec explore` 等流程时，就已经嵌入 resilience 方面的思考，把 incident management 也纳入其中；它会变得自然。

So now you're adding instant management as part of this thing. So this becomes natural now [吸气]

嘉宾 and this whole document gets produced without them knowing this was 整份 document 会自动生成，使用者甚至不知道这原本就是目标。

主持人 the goal to begin with. Yeah. 对。

嘉宾 Similar to open source power tools. The whole point is for people to just this is so much easier to use. Add a logger. 就像 open-source Powertools：目的只是让人觉得“这用起来容易多了”。加一个 logger，

Now I got structure logging. Once you get a correlation ID, just add this flag. And now at the end when they review, oh yeah, I'm doing all this. I didn't even know it. 立刻得到 structured logging；拿到 correlation ID 后，只要加一个 flag。最终 review 时，他们会发现：哦，原来所有这些事我都做了，自己甚至不知道。

主持人 Yeah, 对。

嘉宾 this is the aha moment that I I wish we move more towards. 我希望我们更多走向这种 aha moment。

主持人 There's definitely some there should be some behavior psychology there because I've also noticed that if you give people the end result, if the end result is perfect and they don't trust it, it's never going to fly, right? 这里肯定涉及 behavioral psychology。我也注意到：如果直接给人最终结果，即使结果完美，只要他们不信任，就永远推不动，对吧？

But if you give people tools and they create that end result themselves, they build conviction by because they're in the loop. their critical thinking is used, they are building their own conviction by doing, then they really believe in the end result and all of a sudden you have automatic buy in. That was the goal in the first place is like you're good to go. 但如果提供 tools，让人自己创造最终结果，他们就会建立conviction，因为他们在 loop 中，使用了自己的 critical thinking，也通过行动形成确信。于是他们真正相信结果，突然就有了自动的 buy-in。这其实从一开始就是目标：现在可以继续前进了。

嘉宾 Pretty much. And that's the whole point we started the conversation about um 基本如此。这也回到我们开头谈的：

主持人 why engineers sometimes focus so much on the hard skills, which is truly necessary. You have to, especially agents, you have to know that they're lying. They're coming up with suboptimal results. But when you start going studying adjacent roles, this is where you start amplifying yourself. And agents are supposed to augment you. But first, you need to augment yourself with all of those skills. So then you can reach much higher heights. 为什么 engineer 有时如此专注 hard skills。它们确实必要，必须掌握；尤其面对 agents，你必须能识别它们何时撒谎、何时给出 suboptimal results。但开始学习 adjacent roles 时，你才会放大自身能力。agents 应该 augment 你；但首先，你需要用所有这些 skills augment 自己，这样才能达到高得多的高度。[音乐]

嘉宾 Yeah, Ira, thanks so much for coming on and sharing. Heitor，非常感谢你来节目分享。

主持人 No problem. This is great. Yeah, 不客气，这次很棒。[笑]

嘉宾 thanks for having me. 谢谢邀请。

主持人 This was the first time we did something like this, something visual on screen. So let me know in the comment section what you thought and we'll see you in the next one. 这是我们第一次做这种形式，在屏幕上加入视觉内容。欢迎在 comments 告诉我你的感受，我们下期再见。[音乐]