Stop being skeptical about AI for development with Charity Majors

频道: The Pragmatic Engineer
视频: https://newsletter.pragmaticengineer.com/p/stop-being-skeptical-about-ai-for
原文语言: en
统计: 共 122 轮 · Gergely Orosz 46 · Charity Majors 76

[0:00] Gergely Orosz

Why are there firmly two camps within software engineering when it comes to AI?Those hating its effects and those who are AI-pilled.Charity Majors emphasizes both camps and thinks they are talking alongside one another.Charity is a co-founder and CTO of Honeycomb,previously worked at Facebook and Parse,and is one of my favorite voices in engineering.Today, we discuss what it would take for us engineers to ship code we have never readand why this is more of a when question, not an if question.Why are reliability is quietly getting worse across the industryand why it will take some time to recover?

为什么一提到 AI，软件工程界就泾渭分明地分成两个阵营？一边是憎恶它带来的影响的人，一边是被 AI 彻底说服的人（AI-pilled）。Charity Majors 对这两个阵营都很在意，她认为双方其实是在各说各话、根本没在对话。Charity 是 Honeycomb 的联合创始人兼 CTO，此前在 Facebook 和 Parse 工作过，是我在工程圈里最喜欢的声音之一。今天我们要聊的是：要让我们工程师敢把自己从没读过的代码发上线，需要什么条件？为什么这是一个「什么时候」的问题，而不是「会不会」的问题？为什么整个行业的可靠性正在悄悄变差，而且要花上一段时间才能恢复？

[0:31] Gergely Orosz

Career advice in this age of AI.Why middle managers should consider going back to being ICand why junior engineers will be okay.If you want to hear from someone who was skeptical about AI in 2025but has changed her mind based on the evidence, this episode is for you.In today's episode, Charity will say, spoiler alert,that the question is not if we will stop reading code written by AI but when,and we should take lessons from Ops and QAon how they prove that software that others wrote works in prod.And she's got a very good point.As any Ops engineer or SRA will tell you,that's how software has always been written,by unreliable agents from their point of view.That is, software engineers like me, your colleagues, or you.And let's face it, you probably haven't read all the code in your code base either.This is where I need to mention our presenting sponsor, Antisys.Antisys verifies software written by unreliable agents.It runs your whole system in a hostile simulation and roots out the bugs for you.It does this by using an approach called deterministic simulation testing, or DST.Antisys is turbocharged testing by running your whole system under aggressive fault injection.Imagine Antisys is hundreds or thousands of versions of the Mario game running,

AI 时代的职业建议。为什么中层管理者应该考虑回去做 IC（个人贡献者），以及为什么初级工程师不会有事。如果你想听一个 2025 年时还对 AI 持怀疑态度、后来却根据证据改变了想法的人怎么说，这一期就是给你的。今天这期里 Charity 会说——剧透一下——问题不是「我们会不会停止阅读 AI 写的代码」，而是「什么时候停止」；而且我们应该向运维（Ops）和 QA 取经，学他们是怎么证明「别人写的软件在生产环境里能跑」的。她这话很有道理。任何一个运维工程师或者 SRE 都会告诉你：软件一直以来就是这么被写出来的——由在他们看来「不可靠的执行体」写出来的。也就是说，像我这样的软件工程师、你的同事，或者你自己。而且说实话，你大概也没读过你自己代码库里的所有代码。

【广告】这里我得提一下我们的冠名赞助商 Antithesis。Antithesis 专门验证「由不可靠执行体写出来的软件」。它把你的整套系统放进一个充满敌意的仿真环境里跑，替你把 bug 挖出来。它用的方法叫确定性仿真测试（deterministic simulation testing，简称 DST）。Antithesis 相当于给测试装了涡轮增压——它在激进的故障注入下运行你的整个系统。你可以想象成 Antithesis 同时跑着成百上千个版本的《马里奥》游戏，

[1:35] Gergely Orosz

each instance aggressively trying to break the game with increasingly weird input combinations.If it finds a breakage, this is where the determinism comes in.Instead of you having to try to reproduce a tricky bug you saw in production,Antisys can provide you with a perfect deterministic replay of anything it finds every time.With Antisys, you can specify properties at the whole system level,and Antisys will actively try to disprove them,so you can be confident that if your system holds up in Antisys, it will hold up in production.Head over to antisys.com slash pragmatic to learn more.Charity, it's so nice to do this in person.You're in my city. This is amazing.So today, I wanted to kick off with AI, but before we kick off with AI,I just want to make it kind of clear for people who don't know you that, you know,you're not an AI hater or an AI lover.You actually built a lot of cool stuff pre-AI, right?

每一个实例都在用越来越离谱的输入组合疯狂地想把游戏搞崩。一旦它找到一处崩溃，「确定性」就派上用场了：你不用再费劲去复现一个你在生产环境里见过的刁钻 bug，Antithesis 每一次都能给你一份完美的、可确定重放的复现。用 Antithesis，你可以在整个系统的层面上声明「属性」（properties），然后 Antithesis 会主动去尝试推翻它们——这样你就能有信心：如果你的系统在 Antithesis 里扛住了，它在生产环境里也扛得住。去 antithesis.com/pragmatic 了解更多。【广告结束】

Charity，能面对面做这期太好了。你人在我这座城市，太棒了。今天我想从 AI 开始聊，但在聊 AI 之前，我想先跟不认识你的人说清楚：你既不是 AI 黑，也不是 AI 吹。在 AI 之前你其实就做出过很多很酷的东西，对吧？

[2:23] Gergely Orosz

Starting at, we just saw Linden Labs. Was that your first job?My first job at Linden Lab right across the street.Right across the street. We were just talking about that.So you were building Second Life?

（Gergely）一开始是——我们刚才还路过 Linden Lab。那是你的第一份工作？／（Charity）我的第一份工作就在 Linden Lab，就在街对面。／（Gergely）就在街对面，我们刚还在聊这个。所以你当时在做《第二人生》（Second Life）？

[2:32] Charity Majors

Yeah, we were building Second Life, yeah.And then from there on, one of the big hits was Parse, the developer tool,which was beloved by developers, best back-end for mobile services I used to use it.And then what happened? Facebook bought you.Facebook bought it. Yeah, it was my first great lesson in most acquisitions fail.Most were terrible. This one failed. They shut it down.But ultimately, I'm very grateful to have had the experience,because if it wasn't for that, I've always been a startup kid.And so nobody knew my name.And it wasn't until I was leaving Facebook that investors were like,oh, would you like some money?

（Charity）对，我们当时在做《第二人生》。／（Gergely）从那之后，一个大热门是 Parse——那个开发者工具，开发者特别喜欢它，是我当年用过的最好的移动端后端服务。然后呢？Facebook 把你们买了。／（Charity）Facebook 买了它，对。那是我人生中关于「大多数收购都会失败」的第一堂大课。大多数收购都很糟糕，这一次也失败了，他们把它关停了。但归根结底，我很庆幸有过这段经历——因为如果没有它……我一直是个「创业公司小孩」，没人知道我叫什么。直到我要离开 Facebook 的时候，投资人才开始说：哦，你想不想要点钱？

[3:09] Charity Majors

And that's how we started Honeycomb.And then you saw stuff at Facebook, right? It inspired you.Yeah, yeah. Facebook. There was a tool called Scuba.And so we were in a weird position. We were building on AWS, Ruby on Rails, all this stuff.And then we got to use the internal Facebook tools.And Facebook had this tool called Scuba, and it was, we were experiencing hockey stick growth.It was just like, we had over a million mobile apps hosted on Parse by the time I left.Yeah.And every single week, a new one would break.It would hit the top 10 on iTunes or something out of nowhere.It would just be like, oh, wait.And these apps need a little in the haystack, you know.And it went from, it would take hours or weeks.We have to get lucky.We finally find, because it's not a, it might be one app that's spamming your logs,but that might not be the reason.They might all be backed up behind the reason, you know.So we started getting our data sets into Scuba and finding them.It just went from being a really hard engineering problem with a lot of luck to just being like,report problem.Click, click, click.Oh, there it is.And it was just mind blown.Like, you just, that was a huge problem for our entire existence.

（Charity）Honeycomb 就是这么开始的。／（Gergely）而且你在 Facebook 里看到了一些东西，对吧？给了你灵感。／（Charity）对对，Facebook。那里有个工具叫 Scuba。我们当时处在一个很奇怪的位置：我们在 AWS 上、用 Ruby on Rails 那一套东西做产品，同时又能用 Facebook 的内部工具。Facebook 有这个叫 Scuba 的工具。当时我们正经历曲棍球杆式的增长——我离开的时候，Parse 上托管的移动 App 已经超过一百万个。而且每一周都会有一个新的 App 出问题。它可能突然就冲进了 iTunes 排行榜前十，我们就「哦，等等」。这些 App 就是大海捞针。以前这种排查要花几个小时甚至几周，还得靠运气。我们最后能找到，是因为——问题可能是某一个 App 在刷爆你的日志，但它未必是真正的原因，也可能所有 App 都堵在那个真正的原因后面。后来我们开始把数据集导进 Scuba 里去找，它一下子就从一个需要大量运气的极难工程问题，变成了：报告问题，点、点、点，哦，在这儿。当时脑子直接炸了。这可是困扰我们整个存在期的巨大问题——

[4:17] Charity Majors

And then it was solved.With Scuba.And then when you started Honeycomb, so was this a bit of inspiration that you wanted to build something that feels like Scuba did?I just, the idea of, I was planning to go be an engineering manager, an engineer at Slack or Stripe or something.And I was just like, oof, I would be so much less powerful as an engineer without this.And so, you know, the grand plan in the beginning, I'm just like, well, all startups fail.So, you know, we'll fail, but I'll go sit in a corner and write Go code for a year or two.And then, then I'll open source it and I can take it with me wherever I go.And then that's how Honeycomb started.That's how Honeycomb started.And we'll, we'll, we'll get back to like observability or Honeycomb.But before we do now with, with AI, you know, it's changing everything.Yeah.But I kind of had a bit of a blast from the past, which is one of the first places we connected was in 2020.So almost five years ago or so, someone submitted a question to both my blog and your blog.That's right.And it was, the question was like, can you measure individual developer productivity?

（Gergely）然后它被解决了。／（Charity）被 Scuba 解决了。／（Gergely）那你后来创办 Honeycomb，是不是有一部分灵感就是想做一个用起来像 Scuba 的东西？／（Charity）我当时本来打算去 Slack 或者 Stripe 之类的地方当工程经理或者工程师。然后我就想：唉，没有这个东西的话，我作为工程师的战斗力会低太多。所以最初的宏大计划其实是：反正所有创业公司都会失败嘛，那我们也会失败，但我可以先躲在角落里写一两年 Go 代码，然后把它开源，这样我走到哪儿都能带着它。Honeycomb 就是这么开始的。／（Gergely）Honeycomb 就是这么开始的。可观测性和 Honeycomb 我们待会儿再回来聊。但在那之前——现在有了 AI，它在改变一切。／（Charity）对。／（Gergely）不过我这儿有点「往事重现」：我们最早的交集之一是在 2020 年，差不多五年前，有人同时给我的博客和你的博客投了同一个问题。／（Charity）没错。／（Gergely）那个问题是：个人开发者的生产力能不能被度量？

[5:20] Gergely Orosz

Now I wrote an answer and you wrote an answer.And I wanted to ask you, that was five years ago.No AI, no nothing.Today, someone shoots you a question saying, hey, Charity, can you measure one of an engineer's individual productivity?

我写了一个回答，你也写了一个回答。我想问你的是：那是五年前，没有 AI，什么都没有。今天如果有人扔给你这个问题——嘿 Charity，工程师的个人生产力能度量吗？

[5:35] Gergely Orosz

You know, they're using AI tools and all the, all this stuff.What would you tell them?I would tell them.God, I don't even remember what I said.I remember that blog post, but.We both agreed, by the way, that it was, it was.That you can measure some dimensions and they're not going to give you the full thing.And they will, for example, not tell you how a team is doing.If someone is, is actually a really key part of the team.And that as long as you measure individual things, we both agreed that you need to be in the details to know.And as a good manager or a good team lead, you will know.You will know.But you have to have data to back it up.It's like color and a painting on the wall.And, and is it Goodhart's law?

（Gergely）他们在用 AI 工具，还有这一堆东西。你会怎么回答？／（Charity）我会说……天啊，我都不记得我当时写了什么了。我记得那篇博客，但……／（Gergely）顺便说一句，我们俩当时的结论是一致的：你可以度量某些维度，但它们给不了你全貌；比如它们不会告诉你一个团队状态如何，也不会告诉你某个人是不是团队里真正关键的一环。我们都同意：只要你度量的是个体层面的东西，你就必须深入细节才能真正知道。作为一个好的管理者或者好的技术负责人，你是会知道的。你会知道。但你得有数据来支撑它——就像墙上那幅画里的颜色。还有，这是不是古德哈特定律（Goodhart's law）？

[6:15] Charity Majors

Yes, it's Goodhart's law.So like, never go well.It's this thing that matters, right?You need to actually understand, but you need it to not just be your opinion that was tossed off because you, you have an opinion about some, you know, we're all, we have biases.We, we are selective, you know, you need to look at the picture.I also believe that, you know, there's been this whole push towards individual output, but teams are still what matter.Team output.And honestly, if there's one thing that I am encouraged and excited about with the AI movement, I think it's forcing us all to ask ourselves early and often, what does good look like?

（Charity）对，古德哈特定律。所以说，永远不要……重要的是那件事本身，对吧？你得真的去理解它，但你得让它不只是你随口抛出的一个观点——因为我们都有偏见，我们都会选择性地看东西，你得看整幅画面。我还相信一件事：这些年一直有一股推向「个人产出」的风潮，但真正重要的仍然是团队，是团队的产出。老实说，如果 AI 这波浪潮里有一件让我振奋、让我期待的事，我觉得就是它在逼着我们所有人尽早并且反复地问自己：好，到底长什么样？

[6:56] Charity Majors

What does good mean?What does productivity mean?What would better look like?What would great look like?You know, and these questions are hard.I think it's telling that we all jumped so fast to speed.Yeah.Oh, fast.We can do it fast.Let's do the same thing faster, you know?

「好」是什么意思？「生产力」是什么意思？「更好」会是什么样子？「很棒」又会是什么样子？这些问题都很难。我觉得很说明问题的一点是：我们所有人都那么快地跳到了「速度」上。／（Gergely）对，快。／（Charity）哦，快，我们能做得快。那就把同一件事做得更快呗。

[7:15] Gergely Orosz

Boom.And I've come to feel like that is a very immature description of what better is.Yeah.Just, just today I saw the Anthropic team posted a podcast with Spotify's head of engineering or VP of engineering.I'm not sure which one in which they talk that, wow, Spotify with CloudCo, they're shipping 4,500 changes per day, per week.I'm not sure which one, but they talked about speed.And I was kind of thinking like my experience has been different because I struggled to publish any, like some of my episodes did not go on Spotify because it was down.Yeah.And yeah, they're talking about speed, but we're not talking about quality.We're not talking about more functionality, better functionality or just things that people want.And in the comments, some people were asking like, okay, so what exactly does that mean that they're shipping more frequently?

（Charity）砰。而我慢慢觉得，那是对「更好」一种非常不成熟的定义。／（Gergely）对。就在今天，我看到 Anthropic 团队发了一期播客，嘉宾是 Spotify 的工程负责人还是工程副总裁——我不确定是哪个——他们讲：哇，Spotify 用 Claude Code，现在每天（还是每周？我没听准）能发 4500 个变更。反正他们讲的是速度。我当时就在想，我的体验跟这个不一样：我有几期播客就没能发上 Spotify，因为它挂了。／（Charity）对。／（Gergely）是啊，他们在讲速度，但我们没在讲质量，没在讲更多的功能、更好的功能，或者人们真正想要的东西。评论区里也有人问：好，那「发布更频繁」到底具体意味着什么？

[8:06] Gergely Orosz

Yeah.Do customers really want the buttons on their app to move around all the time?I don't think they do.Yeah.It's an interesting one.It's the easiest thing to measure.Let's jump back to last year in 2025.You wrote a blog post right at the end of the year, looking back, saying that 2025 for AI was what 2010 was for the cloud.Can we talk about that before we go into like what this year, but like last year, like how was your perspective?

（Charity）对。／（Gergely）用户真的想要 App 上的按钮一直挪来挪去吗？我不觉得。／（Charity）对。这是个有意思的点，它是最容易度量的东西。／（Gergely）我们回到去年，2025 年。你在年底写了一篇回顾性的博客，说 2025 年之于 AI，就相当于 2010 年之于云。在聊今年之前，我们能先聊聊这个吗？去年在你看来是什么样的？

[8:34] Charity Majors

Of course, you're working at observability company.AI will give you lots of like business as well, but you said it went mainstream, right?Last year.In March of 2025, Fred Hebert and I gave a keynote at SREcon.We gave the closing talk and it's Fred and I standing in front of a, the term vibe coding had just been invented.Oh yes.And we were like, you guys should try vibe coding.Pause, groans, audible groans, just like people laughing like, ha ha ha.Our big pitch was that people should learn AI because you can complain better if you learn it, which is legit.I mean, I really mean it.But at the time, I think I still saw it as a really big feature or like bigger than a programming language, like the cloud, but not like generational, you know, not changing everything.And I think that was accurate.For me, it was November of 2025 when they released Opus 4.5.But I actually wrote about this recently, a couple blog posts back about how in retrospect, you could see it coming sooner.You could see, and it wasn't actually the models.It was the harnesses.It was all the tooling.And it was people starting to say that around July.They were like, this is coming faster than you think, and this is what it's going to look like.

（Gergely）当然，你在一家可观测性公司，AI 也会给你带来很多生意。但你说的是它去年「进入主流」了，对吧？／（Charity）2025 年 3 月，我和 Fred Hebert 在 SREcon 上做了主题演讲，讲的是闭幕场。当时「氛围编程（vibe coding）」这个词刚被发明出来。／（Gergely）哦对。／（Charity）我们站在台上说：你们应该试试 vibe coding。全场停顿，然后是能听见的呻吟声，还有人在笑：哈哈哈。我们当时的主要说法是：大家应该去学 AI，因为学了才能骂得更到位——这话我是认真的，真心的。但那时候我还是把它看成一个很大的特性，或者说比一门编程语言更大、像云那么大，但不是「划时代」的，不是会改变一切的东西。我觉得那个判断在当时是准确的。对我个人来说，转折点是 2025 年 11 月他们发布 Opus 4.5 的时候。不过我最近写过一篇（往前数几篇博客）讲：事后回看，其实你能更早看出苗头。而且真正在变的其实不是模型，是脚手架（harness），是围绕它的那一整套工具链。而且从 7 月左右就有人在这么说了，他们说：这东西来得比你以为的快，而且它会长成这个样子。

[9:54] Gergely Orosz

And there's those people who were saying it, the robots who were playing with either a cloth coat or maybe pie or open coat.So the harnesses, you're right.They were getting better at the tooling that, you know, it went from just being kind of a shell script that would try again to like, they built a lot of stuff around it.And then, you know, the Opus thing kind of, it was a weird time at the beginning.It's been a weird time every time for a long time.But the early months of this year, it felt like everyone around me was just trying it again and changing their mind.Everyone.Yeah.I think we were just talking about right before we started recording that both you and me respect people who do change their mind.Yes.And I don't think we were wrong to be skeptical that the first time.It's a pretty extraordinary claim that AI is going to write code about as well as the median software engineer can, you know, for a limited balance of that.Well, especially because if we look back at the history of software engineering, this claim has happened again and again.Oh, yeah.You know, neural nets should have been doing something magical.There's a sticker in your pack that says we already have a programming language that lets you, COBOL is the punchline.

（Gergely）而说这话的那批人，是那些在玩 Claude Code、或者 Amp、或者 OpenAI Codex（这几个工具名 ASR 含糊）的人。所以你说得对，是脚手架，是工具在变好——它从原本只是个「失败就重试」的 shell 脚本，变成了围着它建起一大堆东西。然后 Opus 那件事……一开始那阵子很奇怪。／（Charity）很长一段时间里，每一次都很奇怪。但今年头几个月，我感觉身边每个人都在重新试一遍，然后改变了看法。所有人。／（Gergely）对。我想我们刚开录之前还聊到，你和我都尊重那些会改变自己想法的人。／（Charity）是的。而且我不认为我们第一次持怀疑态度是错的。「AI 将会写出跟中位数软件工程师差不多水平的代码」，这在当时是个相当离谱的主张。／（Gergely）尤其是，如果我们回看软件工程史，这个主张已经被反复提出过很多次了。／（Charity）哦，是啊。神经网络本该做出什么魔法来的。你那包贴纸里有一张就写着——我们早就有一门能让你……的编程语言，笑点是 COBOL。

[11:00] Charity Majors

So I don't think we were wrong to be skeptical.And also, don't forget no code and low code.Oh, yeah.I mean, we know it turned out to be a joke, but the promise was the same.And we were skeptical and we were right.And now we're skeptical again and we were wrong.What I was saying in that piece, though, was I think we were right to be skeptical that time.But now I see the same thing playing out with would you be willing to ship some code that you didn't read?

（Charity）所以我不觉得我们当时怀疑是错的。／（Gergely）而且别忘了还有无代码和低代码。／（Charity）哦对。／（Gergely）我们知道那最后成了个笑话，但当年的承诺是一样的。／（Charity）我们那时怀疑，我们是对的。现在我们又怀疑，这次我们错了。不过我那篇文章里想说的是：我认为我们那一次怀疑是对的，但现在我看到同样的剧情又在「你愿不愿意把自己没读过的代码发上线」这件事上上演。

[11:27] Charity Majors

There's no point in arguing about if it will happen or when it will happen.Talk about what it would take.What would it take for you to be comfortable shipping code without you reading it and understanding it?

争论「它会不会发生」或者「它什么时候发生」都没有意义。要聊的是：需要什么条件。要满足什么条件，你才会觉得把一段自己没读过、没理解的代码发上线是可以接受的？

[11:39] Gergely Orosz

Because that is that's engineering.And it goes back to like, you know, my gut reflex would have been saying, oh, no, I would not do that because I've been used to that.However, you're right.You know, if I could have a way to, for example, I could see the change.I could I could tell that this was tested in like a harness or something.Same way where, for example, pre-AI, if there was a team member who said, I vouch for this and I've hammered it and I trust that person.So, like, you're right there.There's these things which are, of course, would never.But I thought that AI or something can do anything like that.But if it could, you're not entering.Right.Or, for example, if you and the AI would would both do it in tandem for a few months and you would be like you would get to how much are they catching?

（Charity）因为那才是工程。／（Gergely）这就回到——我的第一反应本来会是：哦不，我不会那么干，因为我已经习惯了（先读代码）。但你说得对，如果我有办法……比如我能看到这次变更、我能确认它在某种仿真靶场里被锤过；就像 AI 之前，如果有个团队成员说「我为这个背书，我已经把它锤过一遍了」，而我信任那个人。所以你说得对，确实存在这样一些东西——本来是「绝不可能」的。我以前以为 AI 或者别的什么做不到这类事，但如果它能做到，你就不是在……对。或者，比如说你和 AI 并肩干上几个月，你就会摸出来：它抓出了多少问题？

[12:28] Charity Majors

How much am I catching?Is it about the same?Is it more?Is it less?And you're training and it's getting better.Whether it takes five days or five years or whatever, I think it's pretty clear that directionally that's where we're going.And the other thing that I would say is this is good for us.Have you spent much time with the Phoenix architecture stuff that Chad Fowler has been writing about?

（Gergely）我抓出了多少？大致相当吗？更多还是更少？而且你在训练它，它也在变好。／（Charity）不管这要花五天、五年还是多久，我觉得方向上很明显，我们就是在往那儿走。另外我想说的是：这对我们是好事。你有没有花时间看过 Chad Fowler 一直在写的「凤凰架构（Phoenix architecture）」那些东西？

[12:46] Gergely Orosz

You have been quoting.Yeah, I've been quoting liberally.I should probably let you get to it in your own order.But I just feel like anyone who's ever done a painful rewrite should be on board with us.Yeah.But here's a quote from Chad Fowler.Immutable infrastructure, stateless services, containers, blue-green deployments, infrastructure as a code.These ideas all share a common premise.Never fix a running thing.Replace it.AI pushes this premise beyond infrastructure and into application code itself.When rewriting is cheap, editing in place becomes risky.Mutation accumulates entropy.Replacements resets it.Yes.Code is cache.This is a very interesting idea because you've compared, Chad compared, and you've also, of course, shared this,that when we look at how infrastructure changed before, you know, like specifically a server, you need to configure it.I think we call it like pets.Pets versus server.Having pets versus.Yeah.And at some point we stopped configuring individually.We stopped like fixing individual machines.We just like throw it away and have a new thing.And with code, we've always been used to the history of the profession, you know, 60 plus years or maybe a bit longer,is that we edit code.

（Gergely）你一直在引用它。／（Charity）对，我引用得很凶。／（Gergely）我大概应该让你按你自己的顺序讲到那儿。但我就是觉得，任何做过一次痛苦重写的人都应该赞成我们这个观点。／（Charity）对。／（Gergely）这里引一段 Chad Fowler 的话：不可变基础设施、无状态服务、容器、蓝绿部署、基础设施即代码——这些理念共享一个前提：永远不要去修一个正在运行的东西，把它替换掉。AI 把这个前提从基础设施一路推进到了应用代码本身。当重写变得便宜，原地修改就变成了一件有风险的事。修改会累积熵，替换则把熵清零。／（Charity）对。代码即缓存（Code is cache）。／（Gergely）这个想法非常有意思。因为你——是 Chad 做的这个类比，你当然也转述过——我们看基础设施过去是怎么变的，具体说服务器：你得去配置它。我们当时管这叫「宠物」，宠物式服务器对比……／（Charity）养宠物 vs. 养牲口。／（Gergely）对。而在某个时点我们不再一台台去配置了，不再去修单台机器了，就直接扔掉、换一台新的。可代码这边，这个行业六十多年甚至更久的历史里，我们一直习惯的就是「编辑代码」。

[14:03] Charity Majors

And are you thinking this might...Because of the economics of it, I mean, if you think about it, you could generate 10,000 variants of a function faster than you could write it once.And so when you start thinking about it that way, it's like, well, okay, we're going to need a lot of evals.We're going to need a lot of tests.But the generation is so cheap that it really, I think, it forces us in that direction.And I think that the expensiveness of writing code and maintaining code and the expense of software has always been bound up in its maintenance.And those lines of code, the reason that we trust something is because we've been using it.Because we know we...Like there's this deep thing about production.It's like, well, it's trusted.We know.And I've been...I know that as well as anyone.And I will also say this.Anyone who's ever done a hard database migration should have some real humility about our ability to extrapolate those contracts, store them.Like, I am not one of those people who's like, this is good.We're going to generate all code.I don't know how much code.I believe that we can go some distance in that direction and it will be good for us.I don't know how far we can go.I believe we can go farther than we are now.

（Gergely）那你觉得这可能会……／（Charity）因为经济账变了嘛。你想想看，你生成一个函数的一万个变体，比你手写一遍还快。你这么一想就会发现：好吧，那我们会需要大量的 evals（自动化评测），会需要大量的测试。但生成实在太便宜了，所以我觉得它真的会把我们推向那个方向。而且我认为，写代码、维护代码之所以昂贵，软件之所以昂贵，一直都绑在「维护」上。那些代码行——我们之所以信任某个东西，是因为我们一直在用它，因为我们知道……生产环境这件事有一种很深的东西：它是被信任的，我们知道（它行）。这一点我跟任何人一样清楚。我还要说一句：任何做过一次艰难数据库迁移的人，都应该对「我们有能力把那些契约抽取出来、存起来」这件事保持真正的谦卑。我不是那种说「这太好了，我们要生成全部代码」的人。我不知道能生成多少代码。我相信我们能朝那个方向走出一段距离，而且这对我们是好事。我不知道能走多远。我相信能比现在走得更远。

[15:24] Charity Majors

I just can't.And the last project I did at Parse...So we had spent like six months writing the original Ruby on Rails API.Yep.Spent two years rewriting it in Golang.Wow.Yeah, it was...It was...And was it two years because new sub being...Kept being added that you need to pull?

（Charity）我就是……我在 Parse 做的最后一个项目——我们花了大概六个月写出最初那版 Ruby on Rails API。／（Gergely）嗯。／（Charity）然后花了两年把它用 Golang 重写。／（Gergely）哇。／（Charity）对，那真是……／（Gergely）花两年是因为新东西不断加进来、你得一路追平？

[15:44] Charity Majors

To some extent.And also Golang was a pretty immature language at the time.We had to write, you know, the MongoDB drivers and like all the other bunch of things.And also just like when you're writing in Ruby and MongoDB and JavaScript and everything is, you know, there's no type safety.And it's just painful.Just, you know, and the strangler figs that they do where you build the architecture outside the architecture.And you literally find the contracts with your users by breaking them.One after the other.Like that just does not seem like the ideal artifact.We should be able to store them somewhere.We should be able to have architecture diagrams that we can review and discuss that generate that code to spec.This is very interesting because some of these ideas, they've been around decades ago.Specifically, you know, if we had Grady Booch as a third person sitting here, the idea of like, hey, we can have architecture diagrams that translate to code.UML started there.I think Grady would disagree that like he never wanted it to go there.But Irrational Software back in the 90s, they said, hey, you'll define UML.It generates code.It will be beautiful.Now, it wasn't beautiful because I guess some complexity and turns out a generating code was still expensive and reviewing it.

（Charity）一定程度上是。而且 Golang 当时还是一门相当不成熟的语言，我们得自己写 MongoDB 驱动之类的一大堆东西。还有就是，当你用 Ruby、MongoDB、JavaScript 写东西的时候，一切都没有类型安全，那就是很痛苦。还有他们做的那种「绞杀榕（strangler fig）」模式：你在旧架构外面再建一层架构，然后你是靠一个接一个地把用户的用法搞崩，来发现你和用户之间到底有哪些契约的。这实在不像是理想的产物。我们应该能把这些契约存在某个地方。我们应该能有可以评审、可以讨论的架构图，然后由它按规格生成代码。／（Gergely）这个很有意思，因为其中一些想法几十年前就有了。具体说，如果今天这儿坐着的第三个人是 Grady Booch——「我们可以用架构图翻译成代码」这个想法，UML 就是从这儿开始的。我猜 Grady 会不同意，他从来没想让它走到那一步。但 90 年代的 Rational Software 就说过：嘿，你定义 UML，它生成代码，一切会很美好。结果并不美好，我猜是因为复杂度；而且事实证明，生成代码依然很贵，评审也很贵。

[17:00] Charity Majors

But I wonder if some of these ideas now might be just feasible.That's my hope.That's my hope.I mean, I'm just barely old enough that my first job, I was like 17 at university, I was a CIS admin.I remember when, you know, I wasn't really aware of what was going on.I was just a kid.But yeah, I remember how stressful it was and how people were agonizing about how we'll never be able to get that information back.And everyone adapted just fine.I think I wrote the systems that, you know, they built the systems that replaced them, but not as in replace them and work them out of a job.They built the systems and they spent their time writing code instead of like running updates by hand on every server in the closet.And I guess this is an interesting one because clearly like the CIS admin role and profession has been, it doesn't exist today.It's kind of, let's just say, it has been eliminated.However, the people who are CIS admins, they did understand the operating systems.They understood hardware.Yes.They were in a really good position to adopt.And a lot of them just became either software engineers, product managers.I know someone who became a tech salesperson.Yeah.Yeah.Yeah.So it's almost like, like.

（Gergely）但我在想，这些想法现在是不是就变得可行了。／（Charity）这正是我的希望，就是我的希望。我年纪刚好大到——我的第一份工作是 17 岁在大学里当系统管理员（sysadmin）。我记得那时候……其实我没太意识到当时在发生什么，我就是个孩子。但我记得那有多让人紧张，人们多么焦虑地念叨「我们再也拿不回那些信息了」。结果大家都适应得挺好。我想是我写了那些系统——是他们自己建了取代自己的系统，但不是那种「取代掉他们、把他们裁掉」的意思。他们建了系统，然后把时间花在写代码上，而不是挨个跑到柜子里的每台服务器上手动跑更新。／（Gergely）我觉得这是个有意思的点，因为系统管理员这个角色和职业，今天确实已经不存在了，我们就说它被消灭了吧。可是，那些当过系统管理员的人，他们是真的懂操作系统的。／（Charity）对。／（Gergely）他们懂硬件。他们处在一个非常有利的位置去适应新东西。他们中很多人后来成了软件工程师、产品经理。我还认识一个人成了技术销售。／（Charity）对对对。／（Gergely）所以这几乎就像是……

[18:12] Gergely Orosz

And I will hold that our generation of engineers, still the best debuggers.I'm glad that people don't all have to learn about CPU and memory and all this stuff.But like, there's value in knowing that stuff.It comes in handy.I think there's some analogies there to the generation of code stuff.Also, you know, you took a bunch of inspiration in your recent writing about both CIS admins, but also QA.And you wrote something interesting.You said, lines of code are not the ideal artifact to review.And I'll quote a little bit from you.The tools to do this don't exist yet, but many of the ideas do exist.Most come from operations in QA to domains that software engineering has historically been rather snobbish about.Should we revisit our relationship to QA and ops where I feel we always put ourselves as software engineers here and ops and QA somewhere.And maybe time to see some humble pie.Ops equals toil.Right?

（Charity）而且我坚持认为，我们这一代工程师仍然是最好的调试者。我很高兴现在的人不用都去学 CPU、内存这些东西了。但懂那些东西是有价值的，它会在关键时刻派上用场。我觉得这跟「代码生成」这件事之间有某种类比。／（Gergely）另外，你最近的写作里既从系统管理员那里取材，也从 QA 那里取材。你写过一句很有意思的话：代码行不是理想的评审对象。我引你一小段：做这件事的工具还不存在，但很多想法已经存在了，而且大多来自运维和 QA——这两个领域一直被软件工程有点势利地看不起。我们是不是该重新审视一下我们跟 QA 和运维的关系？我感觉我们软件工程师总把自己摆在这儿，把运维和 QA 摆在另一个地方。也许是时候吃点谦卑派了。运维等于苦力活，对吧？

[19:11] Charity Majors

Yeah.I think it's time.I mean, ops and QA have always been more concerned with what is.Software engineering has always been much more concerned with what.How should it be?Mm-hmm.So ops and QA have always been more concerned about validating, about correctness, about does it work as expected?

（Charity）对。我觉得是时候了。运维和 QA 一直更关心「是什么」，软件工程则一直更关心「应该是什么」。／（Gergely）嗯。／（Charity）所以运维和 QA 一直更关心的是验证、是正确性、是「它是不是按预期在工作」。

[19:30] Charity Majors

Does it work.Does it work to start with?Does it work?Yeah.Yeah.I mean, it's always weird to me just how much software engineers really seem to believe that the world exists in the repo.It doesn't.It's production, you know?

（Gergely）它到底能不能工作。／（Charity）首先，它能不能跑起来？它到底行不行？对。我一直觉得很怪的一点是，软件工程师竟然真的那么相信「世界就存在于代码仓库里」。不是的，是生产环境。

[19:45] Charity Majors

The code has part of the information.Some of it, it's very necessary.We need that.But like, I know some software engineers who, and okay, some places don't even let software engineers look at production.Just like, how?

代码只承载了一部分信息。其中有些是非常必要的，我们需要它。但我认识一些软件工程师——而且好吧，有些地方甚至不让软件工程师看生产环境。我就想：这怎么可能？

[19:59] Gergely Orosz

Oh, I know a lot of people are very upset about AI.Kind of.But the things that get me very excited, genuinely excited about AI are that it is pushing the discipline in directions we have desperately needed to go for a very long time.Production is not what happens after development.It is a stage of development.And you've been saying this consistently for pre-AI, I'm just going to say for those who don't, because I remember we've, I think we also bonded a little bit over.There was this thing called trending on Twitter when it was still Twitter and it was tech Twitter.Everyone was there who mattered.And there was a trend going, it's Friday, don't deploy.Something that there was maybe a hashtag even like, I'm not sure, don't deploy Friday or something like that.And the point was, it was well-meaning.It said like, look, when you deploy often there's an outage and on the weekend we don't want to do.So there was a thing every Friday it went viral saying don't deploy on Fridays.And you came in and you said, you know what, you should be able to deploy anytime without fear because you should be able to just know, you know, however that might be CICD.And then on top of this, you were like, no, like you should actually just not even have a user acceptance testing environment at UAT.

（Charity）哦，我知道很多人对 AI 非常不爽，有点。但真正让我对 AI 兴奋、由衷兴奋的地方在于：它正在把这个行业往我们早就迫切需要去的方向上推。生产环境不是开发之后才发生的事，它就是开发的一个阶段。／（Gergely）这一点你在 AI 之前就一直在讲。我要替不了解的人补一句，因为我记得我们俩在这件事上也挺投缘的：当年推特还叫 Twitter、科技推特还在的时候——所有重要的人都在那儿——有个趋势叫「周五别发布」。当时甚至可能有个话题标签，我不确定，类似 #别在周五部署。这个说法本意是好的：它说，你看，一部署往往就出故障，周末我们不想搞这个。所以每到周五就会有这么个东西刷屏，说别在周五部署。然后你冲进来说：你知道吗，你应该能在任何时候无所畏惧地部署，因为你应该心里有数——不管靠的是 CI/CD 还是什么。而且在这之上你还说：不，你甚至根本不该有用户验收测试环境（UAT）。

[21:10] Gergely Orosz

You should just deploy production, like intestine production, right?As soon as you merge, it should be going out.Like you should have to stop the train to make your code and not go into production as soon as you've merged.Absolutely.And one more interesting thing is, is you had a long train of thought about like the AI and what it could be.Is one thing you said is our brains are not built for validation.Almost everyone I talked to, including Andres Heisberg, he said that, look, like it's very clear that code generation is cheap.We are generating more code.And the bottleneck for human engineers is for code review.And everyone's trying to figure out how do we make code review easier?

（Gergely）你就应该直接部署到生产、在生产里测试，对吧？代码一合并就应该发出去。应该是要「拉手刹」才能让代码在合并之后不进生产。／（Charity）完全正确。／（Gergely）还有一件有意思的事：你有一长串关于 AI 以及它可能变成什么样的思考。你说过一句：我们的大脑不是为「验证」而生的。几乎我聊过的每个人，包括 Anders Hejlsberg，都说过：很明显，代码生成很便宜，我们在生成越来越多的代码，而人类工程师的瓶颈在代码评审。所有人都在想：我们怎么让代码评审变得更容易？

[21:48] Gergely Orosz

How do we build nicer tools?Uber has built amazing tools to like try to like surface important code reviews.But everyone is pushing like, all right, let's do more code review.As an engineer, I'll be honest, like I never liked doing a code review.When there's very little to do and it's with someone I care about, I'll entertain it.It's more of a coaching opportunity then, right?

我们怎么造更好的工具？Uber 就做过很棒的工具，试图把重要的代码评审顶上来。但所有人都在往一个方向推：好，那就多做代码评审。说实话，作为工程师，我从来就不喜欢做代码评审。如果活很少、而且对方是我在乎的人，我还愿意陪一陪——那时候它更像是一次带教机会，对吧？

[22:08] Charity Majors

But as soon as there's an AI, it's kind of like, I don't know.I don't really care.Like, I'm just being honest here.Like, do you care when?I don't.I've never.So the problem, one of the problems is that I think code review means so many things to so many people in so many places.And so there's a lot of projection going on.A lot of people are, if you say that you don't want code review, you're saying you don't want to talk to your coworkers, you don't want to mentor juniors, you don't want to, you know, which is not true.We've just bundled so many things into this, like, you know, it's like.Hugely overloaded.Hugely overloaded.And some of those things are really good.Some of those things could be done better in other ways, you know.Some of those things are very cultural, very specific.My friend, David Pohl, who I worked with at Parse, and he's now working at GitHub on pull requests.Amazing.Love the Parse mafia.Yeah, exactly.He's like, to me, the code review is when we decide, do we want this in our product or not?

（Gergely）但一旦对面是 AI，我就……说不上来，我其实不太在乎。我说实话。你在乎吗？我不在乎，我从来没在乎过。／（Charity）问题之一在于，我觉得「代码评审」这个词，在不同的人、不同的地方那里意思差太多了，所以里面有大量的投射。很多人一听你说你不想做代码评审，就自动理解成你不想跟同事说话、不想带新人、不想……而这不是真的。我们只是把太多东西打包塞进了这一个词里。／（Gergely）严重超载。／（Charity）严重超载。其中有些东西是真的好，有些东西其实可以用别的方式做得更好，还有一些非常依赖文化、非常场景化。我在 Parse 的同事、我的朋友 David Poll，现在在 GitHub 做 Pull Request。／（Gergely）太棒了，爱死 Parse 黑帮了。／（Charity）对，就是。他说：对我来说，代码评审就是我们决定「这东西我们要不要放进产品里」的那一刻。

[23:08] Charity Majors

I'm like, well, that is a, that's a great, great discussion.That is what humans are good at.We should talk about, is this mental model coherent?Should we add this?Should we not?Like, love that.Architectures, you know.But, like, the code is not necessarily a great artifact for all of those.So should we be talking to people?

我就想：那是一个很棒很棒的讨论，那正是人类擅长的事。我们应该讨论：这个心智模型自洽吗？我们该不该加这个？要不要？我特别喜欢这种讨论。还有架构。但代码本身未必是承载这些讨论的好载体。所以我们该不该跟人讨论？

[23:28] Gergely Orosz

Uh, yes.Is the code review the right form factor?Maybe.But I think that the emotional reaction that so many people are getting to the, like, the validation in my book is at the very bottom of the list.I'd like to, like, touch, like, stay here a bit more.Can you break out the parts?

（Charity）该。那代码评审是不是合适的形式？也许吧。但我觉得那么多人产生的那种情绪反应，其实——在我这本账里，「验证」是排在最后面的。／（Gergely）我想在这儿多待一会儿。你能把这些部分拆开讲讲吗？

[23:46] Gergely Orosz

Because it feels to me code review is overloaded.But the parts of code review or the things that you have seen are good things and maybe we don't need to do as code review.And the things that are just, like, just have never been that good.And maybe we just need to throw it away.Yeah.I mean, I think, do we want this in our product?

（Gergely）因为在我看来，代码评审是个严重超载的东西。哪些部分、哪些事情你见过是真的好的？也许它们不必以「代码评审」的形式来做。而哪些部分其实一直都不怎么样，也许我们就该直接扔掉。／（Charity）对。我觉得，「我们要不要把这个放进产品」这件事很棒。

[24:02] Charity Majors

Is that is great.I mean, ideally you'd talk about that before you write the code for it.But, you know, whatever.And, you know, is this API design?You know, those are great conversations.Reading for syntax and bugs and that sort of thing.It's not evil, but it feels like it could be.It's a teaching opportunity if that's the best teaching opportunity you have.And I guess some folks at some point maybe need them.But it doesn't feel high.It's like a great use of anyone's.It feels the only time where it's useful is if someone joins a team.And initially it can be a little bit of feedback.Yeah.Especially when there's, like, nothing is written down.There's no guidance.There's no linting rules that would give you that.Well, see, that's, again, yes, we can fill in the cracks if we haven't built the guardrail.We can fill in the cracks all kind of ways with our own time.But there are so many things, I think, that we never think to extract out of the process of building and validating software.So we rely on us.So I am a huge fan of Intercom, you know, FIN, their engineering org.And I have been forever.Like, I noticed their CTO a decade ago had this saying, shipping is your company's heartbeat.And I love that.

这个很棒。当然理想情况下，你应该在写这段代码之前就讨论完。但算了，无所谓。还有，这个 API 设计怎么样？这些都是很好的对话。而逐行读语法、找 bug 之类的——它不邪恶，但感觉它可以不必是这样。如果这是你手上最好的带教机会，那它就是一次带教机会，我猜某些人在某个阶段确实需要。但它感觉不像是任何人时间的高效用法。／（Gergely）感觉唯一有用的场合是有人刚加入团队，一开始给一点反馈还行。／（Charity）尤其是当什么都没有写下来、没有指引、没有能替你做这件事的 lint 规则的时候。／（Gergely）对。／（Charity）你看，这又是——是的，如果我们没有把护栏建起来，我们可以用自己的时间去填这些缝，我们可以用各种方式去填缝。但我觉得，在「构建并验证软件」这个过程里，有太多东西我们从来没想过要把它抽取出来固化，所以我们只能靠人。我是 Intercom 的超级粉丝——他们的 Fin，他们的工程组织——一直都是。我注意到他们的 CTO 十年前说过一句话：发布是你公司的心跳。我特别喜欢这句话。

[25:17] Charity Majors

They ship a Ruby monolith, like, 10, 15 minutes, hundreds of times a day.That is not trivial.It's not a trivial thing to do.Right?So they're kind of the high watermark from my mind right now for teams that were founded pre-AI, have a lot of engineering discipline, who have become AI native.And they wrote a great post about how they do PRs that are AI validated.And the bar for them is very high.It's like they have all the wisdom of their most senior engineers looking at every single diff.And that is fantastic.Which means that you don't have to worry about remembering and looking and nitpicking and all the things that we're not good at anyway.And they can talk about, is this the direction we're going to go?

他们发布一个 Ruby 单体应用，每次 10 到 15 分钟，一天几百次。这不是小事，做到这个一点都不容易，对吧？所以在我心里，他们是那种「AI 之前就成立、有很强工程纪律、后来变成 AI 原生」的团队里的标杆。他们写过一篇很棒的文章，讲他们怎么做 AI 验证过的 PR。他们的门槛非常高——相当于把他们最资深工程师的所有智慧都装上去看每一个 diff。这太棒了。这意味着你不用再操心去记、去盯、去挑刺——那些本来我们就不擅长的事。然后他们就可以去谈：这是不是我们要走的方向？

[26:03] Gergely Orosz

Is this the right path?You've also written that non-deterministic systems require more engineering discipline, not less.So, like, what is the thing about these non-deterministic systems?We're specifically AI, right?

（Charity）这条路对吗？／（Gergely）你还写过：非确定性系统需要的是更多的工程纪律，而不是更少。那么，这些非确定性系统到底有什么特别的？我们说的具体就是 AI，对吧？

[26:15] Gergely Orosz

We're talking about AI.Let's just name it.That is, we see that AI does amplify both discipline and lack of discipline.Why do we need more?And when you say discipline, what specifics are we talking about?

（Gergely）我们说的就是 AI，直接点名吧。也就是说，我们看到 AI 会同时放大「纪律」和「没纪律」。为什么需要更多纪律？你说的「纪律」具体指什么？

[26:27] Charity Majors

Well, I mean, tests and evals, for one thing, right?Like, if we're treating the code like a trusted artifact and we're, you know, trying to predict everything with our human brains and everything, then we're writing the test that we can predict that it might break, you know?

首先就是测试和 evals（自动化评测），对吧？如果我们把代码当成一个可信的产物，试图用人脑去预测一切，那我们写的测试就只能覆盖我们能预想到的故障。

[26:44] Charity Majors

And then any time the system breaks, we, like, try and write a test for that.But that's not an especially high bar.And so I think the sort of the behavioral tests or the, I don't remember the word, it starts with C, but the QA folks have these suite of tests where it captures.There's also smoke tests.Yeah, there's so many.There can be, like, performance tests.There can be low tests.There can be, yeah, there can be, like, just kind of fuss testing as well.It's just something that's like, okay, if I'm not going to read this code, how do I know it's going to perform within boundaries of the last code that I generated?

（Charity）然后每次系统出问题，我们再回头补一个测试。但这个门槛并不算高。所以我觉得那种行为测试，或者——我记不起那个词了，C 开头的——QA 那帮人有一整套测试，它会捕捉……／（Gergely）还有冒烟测试。／（Charity）对，太多了。／（Gergely）可以有性能测试、压力测试，还有模糊测试（fuzz testing）之类的。／（Charity）就是那种：好，如果我不打算读这段代码，我怎么知道它的表现还在我上一次生成的代码的边界之内？

[27:22] Charity Majors

That is conformance testing.Conformance testing.Just as important for lots of workloads as, you know, absolute performance.Is it just not changing too much?And so we, I think we're going to need, the trust has to go somewhere, right?

（Gergely）那叫一致性测试（conformance testing）。／（Charity）一致性测试。对很多工作负载来说，它和绝对性能一样重要——它有没有变得太多？所以我觉得我们会需要……信任总得放在某个地方，对吧？

[27:36] Charity Majors

If you're debiting from this trust account and the creation of the code, it has to get built up somewhere else.And I feel like one of the things that I'm really excited about in the coming months is just, I actually really like thinking about it less as AI and more as deterministic and non-deterministic systems that have to play nicely together because determinism is not going anywhere.It's incredibly valuable.And we have to learn to make AI kind of boring, you know?

如果你在「代码创作」这个账户上支取信任，它就必须在别的地方被重新攒起来。我觉得未来几个月最让我兴奋的一件事是——其实我更愿意不把它当成「AI」来想，而是当成「确定性系统和非确定性系统必须好好共处」这件事来想。因为确定性不会消失，它极其有价值。而我们得学会把 AI 变得无聊。

[28:03] Charity Majors

It's a non-deterministic tool, which means that it is all over the place.But it's so valuable.But it's all over the place.So we have to learn how to give it carved pathways and places where we kind of corral it, where we use it in the way that it's a superpower and not in the way that like erodes our foundations.It's interesting because Martin Fowler, a year ago when he was on the podcast, the thing that he talked about is how the biggest change with AI is a non-determinism.And when we think back in the history of software, it's always been deterministic.Same for neural nets, but that was most of us software engineers didn't really touch too much of it because it just wasn't that useful for us.But we've been used to that when we programmed it, you know, it just happened the same way.Unit tests were easy because you just run them once.You don't really run them twice because why would you?

（Charity）它是一个非确定性的工具，意思是它会满天飞。但它又太有价值了。可它就是满天飞。所以我们必须学会给它开凿出通道、圈出场地，在它是超能力的地方用它，而不是在它侵蚀我们地基的地方用它。／（Gergely）这很有意思。Martin Fowler 一年前上这个播客的时候，他讲的最大变化就是非确定性。回看软件的历史，它一直是确定性的。神经网络也算是例外，但我们大多数软件工程师其实没怎么碰它，因为它对我们没那么有用。我们习惯的是：程序一旦写好，它每次都以同样的方式发生。单元测试很简单，因为你跑一次就行，你不会跑两次——为什么要跑两次？

[28:50] Gergely Orosz

And I wonder if this is we need to just realize how big of a deal this change is and that any business that employs us, like, you know, they want software that works the same way.We just had a recent post on Hacker News.There's this ATS application tracking system scoring system that HackerRank outsourced, which scores your resume.And so software engineers just like, and you can run it locally, it's open source.You can use a local model.I think they recommend Gemma, Google's small model.And when you run it like 100 times, it will score the same resume anywhere from like 66 points to 99 points.And typically most companies have 85 set as the bar.And you're like, hang on.So we've turned what they were advertising as a tool to help your recruitment.We just prove that it's just a coin flip.That's bad.Yeah.And we have to be able to say that it's bad.AI is not the right tool for every use case, you know.And I think every company is going through this in microcosm.And something I was saying to folks just earlier today, we've been doing a series of conversations on our AI norms and values.And it was like, a year ago, I don't trust us.Like a year ago, if we were like, yes, we should use AI, no, we didn't know enough.

（Gergely）我在想，我们是不是需要意识到这个变化有多大：任何雇我们的企业，他们要的都是行为一致的软件。Hacker News 上最近有一个帖子：有个 ATS（申请人跟踪系统）的评分系统是 HackerRank 外包出去的，用来给你的简历打分。软件工程师们——你可以在本地跑，它是开源的，还能用本地模型，我记得他们推荐 Google 的小模型 Gemma——你跑 100 次，同一份简历它给出的分数会从 66 分到 99 分不等。而通常大多数公司把门槛设在 85 分。你就想：等一下。所以他们宣传成「帮你做招聘」的工具，我们刚刚证明了它就是掷硬币。／（Charity）那很糟。／（Gergely）对。／（Charity）而我们得能够说出「这很糟」。AI 不是每一个使用场景的正确工具。我觉得每家公司都在小规模地经历这件事。我今天早些时候还在跟同事说，我们在做一系列关于 AI 规范与价值观的讨论。当时的感觉是：一年前，我不信任我们自己。一年前如果我们说「对，我们应该用 AI」，不行，我们懂得还不够多。

[30:08] Charity Majors

We've gone on such a journey over the past year, and we know so much more now.The like of one of my coworkers is like, AI is the wrong tool for this job.I'm like, I trust you.You know, you got to get worse before you can get better.So tell me about where you are right now with your, how inside of Honeycomb, how you're thinking about AI, how you're thinking about how to think about AI, and what values you came up with that works right now for you.Yeah, it starts with just acknowledging that the bar has gone up for all of us.That's what happens when we get power from new tools.Has the bar gone up, or has the, you know, the floor gone up?

（Charity）过去这一年我们走过了很长一段路，现在我们懂得多多了。现在我的一个同事说「AI 不是干这活的正确工具」，我会说：我信你。你得先变差，才能变好。／（Gergely）那跟我说说你们现在的状态——在 Honeycomb 内部，你们怎么看 AI、怎么思考「该怎么思考 AI」，以及你们最终定下了哪些现在对你们管用的价值观？／（Charity）好。它首先是承认一件事：所有人的标准都被抬高了。当我们从新工具那里拿到力量时，就会发生这种事。／（Gergely）是标准（bar）被抬高了，还是地板（floor）被抬高了？

[30:47] Charity Majors

That is a great question.Maybe yes.Maybe, yeah, I don't know.We're definitely in a sort of wandering in the wilderness phase.But you can't not wander, or you will be left behind.You know, we acknowledge that the bar is going up for all of us, and that the only viable way to define that bar is better outcomes.And asking ourselves, like, is this good?

（Charity）这是个好问题。也许两个都有吧，我不知道。我们现在肯定处在一个「在旷野里游荡」的阶段。但你不能不游荡，否则你就会被落下。我们承认所有人的标准都在被抬高，而定义这个标准的唯一可行方式，就是更好的结果——并且不断问自己：这好吗？

[31:09] Charity Majors

Is this better?What does good look like?Another thing that we point out is just, there is no human in the loop.You own the loop.The loop is yours.The loop is mine.It would not exist if it was not for me.So I am the owner, right?

这更好吗？「好」长什么样？我们强调的另一点是：没有「人在回路中（human in the loop）」这回事。你就是那个回路的主人。这个回路是你的，这个回路是我的。如果不是因为我，它根本不会存在。所以我是所有者，对吧？

[31:22] Charity Majors

There's no, oh, Claude said this.So, no, no, no.It's your work.You own it.Charity just talks about owning the loop.Owning the loop also means controlling what every agent inside of that loop is allowed to do, which brings us to our season sponsor, WorkOS.Today, agents are increasingly able to act on their own, and the old auth model was never designed for that.Who is this agent?

没有什么「哦，是 Claude 这么说的」。不不不。这是你的活儿，你对它负责。

【广告】Charity 刚才讲到「拥有这个回路」。拥有回路也意味着控制回路里每一个 agent 被允许做什么——这就说到了我们的季度赞助商 WorkOS。今天的 agent 越来越能自主行动，而旧的认证授权模型从来就不是为此设计的。这个 agent 是谁？

[31:44] Gergely Orosz

What's it allowed to touch?On whose behalf?You really don't want to get answers to these questions wrong.WorkOS is built exactly to solve this problem.WorkOS is fine-grained authorization, FGA, designed for how agents actually operate, plus SSO and SCIM,and not just user auth with agents bolted on after.The fastest-growing AI companies, Entropic, OpenAI, Cursor, Perplexity, already trust WorkOS.Check it out at workos.com.I also want to talk about Buildkite, the CI orchestration platform trusted by Cursor, OpenAI, Entropic, NVIDIA, Uber, Canva, and more.Charity talked about owning the loop.But here's a challenge.Thanks to AI, your agents are writing a lot more code.To trust this code, every change that an agent makes still has to be built, tested, and proven safe before it ships.So obviously, you need CI more than ever.But when agents are pushing 5, 10, or 50 times the commit volume to your pipelines, faster CI runners won't be enough to keep up with it.Shaving 30 seconds off a single build is meaningless when the queue is 100 plus jobs deep.What you really want is a CI system that gets faster as the volume grows, and CI that offers instant parallelization to give you unlimited concurrency and to intelligently route changes at runtime.

它被允许碰什么？以谁的名义？这些问题你实在不能答错。WorkOS 就是为解决这个问题而生的。WorkOS 提供细粒度授权（fine-grained authorization，FGA），是按 agent 真实的运作方式设计的，另外还有 SSO 和 SCIM——而不是先做用户认证、再把 agent 硬栓上去。增长最快的那批 AI 公司，Anthropic、OpenAI、Cursor、Perplexity，已经在用 WorkOS 了。去 workos.com 看看。

我还想聊聊 Buildkite，这个 CI 编排平台被 Cursor、OpenAI、Anthropic、NVIDIA、Uber、Canva 等公司信赖。Charity 讲到「拥有回路」，但这里有个挑战：因为 AI，你的 agent 在写多得多的代码。要信任这些代码，agent 做的每一次变更在上线前仍然必须被构建、被测试、被证明是安全的。所以显然，你比以往任何时候都更需要 CI。可是当 agent 往你的流水线里推 5 倍、10 倍甚至 50 倍的提交量时，光让 CI runner 跑得更快是跟不上的。当队列里堆着一百多个任务时，把单次构建省下 30 秒毫无意义。你真正想要的是一个「量越大反而越快」的 CI 系统——一个提供即时并行化、给你无限并发、并能在运行时智能路由变更的 CI。

[32:53] Gergely Orosz

This is what Buildkite does, and why global software leaders at every level continue to rely on it.The same architecture that observed the scale of Shopify and Uber a decade ago now runs about 1.4 billion job minutes a week across Cursor, Meta, Reddit, and Snowflake.While the rest of the CI world are crackling under the weight or re-architecting their platform, Buildkite continues to reliably grow.Agents run on your infrastructure or on Buildkite.Any cloud, any chip, your secrets, your scale.Every artifact and log is captured, so when something fails, either you or your agents have immediate insight for why.As you're entering the context you give to your agents, think about how you'll verify what they hand back.If your system is buckling under the increased volume, head to buildkite.com slash pragmatic.30-day all-access trial, no credit card, and an actual human engineer on standby.His name's Ola, and he's very helpful.And with this, let's get back to charity and communication norms with AI.I think there was this frenzy of, oh my god, I can do this.Oh my god, it's so cool.And I know you have also become very weary of this slot.I just don't even read it anymore.As soon as I can tell.

这就是 Buildkite 在做的事，也是各个层级的全球软件领导者继续依赖它的原因。十年前支撑 Shopify 和 Uber 那种规模的同一套架构，如今在 Cursor、Meta、Reddit 和 Snowflake 这些公司上每周跑约 14 亿任务分钟。当 CI 世界的其他玩家在重压下噼啪作响、或者在重构自己的平台时，Buildkite 仍在稳定增长。Agent 可以跑在你自己的基础设施上，也可以跑在 Buildkite 上——任意云、任意芯片，你的密钥，你的规模。每一个产物和日志都会被捕获，所以出问题的时候，你或者你的 agent 立刻就能看清为什么。当你在琢磨给 agent 什么上下文时，也想想你要怎么验证它交回来的东西。如果你的系统正在被暴涨的量压垮，去 buildkite.com/pragmatic。30 天全功能试用，不要信用卡，还有一位真人工程师随时待命——他叫 Ola，非常热心。【广告结束】

好，我们回到 Charity 和 AI 时代的沟通规范。我觉得之前有过一阵狂热：天哪，我居然能做这个；天哪，这太酷了。我知道你现在对这种「AI 垃圾（slop）」也非常厌倦了。／（Charity）我现在根本就不读了。只要我一看出来……

[34:01] Charity Majors

As soon as I recognize this might have been AI, it's like trash.Here's a baseline.You cannot send anyone something you haven't read.And in fact, if it would take them longer to read it than it took you to make it, it's probably slop.That's really disrespectful, actually.And I think, like, just like asking someone, like you're asking.Anytime I give you something, I'm asking for your time and attention.And if I'm giving you something that I don't even know what's in it, and I'm putting it on you, it costs you instead of me.That is not good.I also think that even before that, I've noticed as I start working on these norms and values, I'm noticing myself as I start to ask someone a question without trying to look up the answer.Ooh, I shouldn't do that.Or if I'm giving someone something that I kind of generated, and I'm like, ooh, you know.So part of it is just self-awareness.It's interesting because everything you talked about, it reminds me of when a new joiner would join a team, a junior engineer, a new grad.Either they had emotional intelligence or they picked up on really quickly that, for example, you go and ask a senior of their time once you put in a little bit of work.And you start to respect their time as well.

（Charity）只要我一认出这东西可能是 AI 写的，那就是垃圾。这里有一条底线：你不能把一个你自己都没读过的东西发给别人。而且事实上，如果对方读它花的时间比你生成它花的时间还长，那它多半就是垃圾。这其实是很不尊重人的。我觉得，任何时候我给你一个东西，我都是在向你索取时间和注意力。如果我给你的东西我自己都不知道里面写了什么，然后我把它甩给你，那成本就从我身上转嫁到了你身上。这不好。我还觉得，在这之前——随着我开始琢磨这些规范和价值观，我注意到自己：当我准备去问别人一个我自己都没试着查过答案的问题时，我会想，哦，我不该这样。或者当我要把一个我随手生成的东西给别人时，我会想，哦，这个……所以其中一部分就是自我觉察。／（Gergely）这很有意思，因为你讲的这些让我想起，当一个新人加入团队——一个初级工程师、一个应届生——要么他天生有情商，要么他很快就学会了：比如你要去占用资深同事的时间之前，你得自己先花点功夫。然后你也会开始尊重他们的时间。

[35:16] Gergely Orosz

And obviously, it doesn't start like that.We don't want them.But there's this balance.And I almost feel it's the same thing.We're like, look, like, respect your colleagues.Respect fellow humans.If you are communicating with them, make sure that you're not wasting their attention.Because now, I guess, attention is where we're kind of running low.Like, we have all of these, like, a bunch of people have a bunch of agents doing.But the point is, that's kind of the currency.And as long as you respect that, it doesn't matter.Like, I think we're not talking about don't use AI for this or that.Like, use it as much as you want or make yourself more efficient.Just don't degrade.Because it really degrades those personal skills, right?

当然，一开始不是这样的，我们也不希望他们（一上来就完美）。但这中间有个平衡。我几乎觉得这是同一件事：你看，尊重你的同事，尊重同类。如果你在跟他们沟通，就要确保你没有在浪费他们的注意力。因为现在，我猜注意力才是我们真正稀缺的东西——一大堆人手里有一大堆 agent 在跑活儿。但重点是，注意力才是那个货币。只要你尊重这一点，其他的都无所谓。我觉得我们不是在说「这个别用 AI、那个别用 AI」，你想用多少用多少，让自己更高效。只是别让它把你降级了——因为它真的会把那些人际能力磨掉，对吧？

[35:52] Charity Majors

You can use AI as a shortcut to help you not have to think too much.And you can use AI to help you think more deeply and more rigorously.And most of those use cases have their place.But when it comes to your core job function, we primarily want the second one, right?

你可以把 AI 当成一条捷径，让自己不用怎么动脑；你也可以用 AI 帮自己想得更深、更严谨。这两类用法大多数都有它们的位置。但当涉及你的核心工作职能时，我们主要想要的是第二种，对吧？

[36:10] Charity Majors

And especially if you're involving someone else and you're asking them to review or, you know,and this is not absolutist.Like, there are people who English is a second language.And they use it.And people who are, like, neurodivergent.And that is, again, that is still being respectful, you know?

尤其是当你把别人牵扯进来、请人家来评审的时候。而这也不是绝对主义的——有些人英语是第二语言，他们会用它；有些人是神经多样性（neurodivergent）的。这些同样是尊重，你知道吧？

[36:24] Charity Majors

So it's not like, like you said, it's not no AI.But it's like, make reasonable asks of each other.And, you know, we don't need to reinvent a new bar for quality or respect.Because we have great bars already for quality and respect.We just need to apply.For a while there, I think that there was a bit of, oh my god, this is so cool.Do you see what this cool thing can do?

（Charity）所以就像你说的，这不是「不许用 AI」，而是「互相提出合理的要求」。而且我们不需要为质量和尊重重新发明一套标准，因为我们本来就有很好的质量与尊重标准，我们只需要把它们用上。／（Gergely）有一阵子，我觉得确实有点「天哪这太酷了，你看这玩意儿能干什么」的劲儿。

[36:47] Gergely Orosz

And I think we're all just, like, so over it.The reason I really respect that you came from the cis, you know, the cis dev background.You also, you're very involved in SRE.These are all folks who have been pretty skeptical of AI.And you mentioned how you're seeing two camps, two very clear camps.There's, like, kind of the AI pills folks who, like, get it.And then the people who seem to, like, they just hate AI.And you said that you're not seeing these two camps have any sort of way to go between any feedback.Can we talk about what you're seeing and, like, maybe, you know, like, where you see some of these camps forming?

（Charity）而我觉得我们现在都对那个劲儿彻底腻了。／（Gergely）我特别尊重你是从系统管理员/系统开发那个背景出来的，你也深度参与 SRE。这些都是对 AI 相当怀疑的人群。你提到你看到两个阵营，两个非常清晰的阵营：一边是被 AI 说服、「懂了」的人，另一边是看起来就是恨 AI 的人。你还说，你没看到这两个阵营之间有任何往来的通道、任何反馈。我们能聊聊你看到了什么、这些阵营大概是怎么形成的吗？

[37:27] Charity Majors

See, the problem is that neither side is making it up.Like, they are seeing really scary trends.They're grappling with real hard problems that are getting worse.You know, and on the enthusiast side, it's like they're acutely conscious that it's a bit of a race.And that we need to push ourselves out of our comfort zone.And they see other companies moving faster, catching up, leapfrogging.They're really worried about, you know, we're falling behind.And the first thing, I don't want to make it sound like false equivalents because, well, there are elements of this that are true.I think every company is more one or more the other.But, like, they're not wrong.They're not wrong.We've never seen technological change this fast.We're on the inside of an exponential curve, which is very rare and it never usually lasts that long.But it's still happening, you know?

问题在于，两边都不是在编故事。他们看到的确实是很吓人的趋势，他们在搏斗的确实是正在恶化的真问题。在热情派这一侧，他们非常清楚这有点像一场赛跑，我们必须把自己推出舒适区。他们看到别的公司跑得更快、追上来、甚至弯道超车，他们真的很担心我们要掉队了。首先我不想把这说成「各打五十大板」，因为——嗯，这里面有些成分是真的。我觉得每家公司都会更偏向其中一边。但，他们没有错。他们没有错。我们从没见过这么快的技术变革。我们正处在一条指数曲线的内部，这非常罕见，而且通常持续不了太久。但它还在发生。

[38:24] Charity Majors

Things that are happening that shock us and we would be wise to prepare for them.So, like, that's real.That's real.And these folks are usually at most companies, usually they are the small minority and they are constantly feeling outmanned.One of the things that's ironic, though, is that both of these sides feel like they are the tiny minority and they're outmanned.And they're being suppressed.And they are standing up for what is truth and valor in the face of the big AI folks or the big skeptics.But the other side, and this often starts to come down to the group that is on call and the group that is not.Ooh, yep.Because the people who the buck stops with them, they are seeing melting mental models.They're seeing slop.They're seeing all their hard work just dissolve.And they don't see any end in sight.So, just to be clear, we're seeing that the people who are on call for a lot of these systems, they're seeing more incidents.They're seeing carelessness being caused by it.They're actually seeing that since that group started to use more AI, our systems are getting way worse.Way worse.Yeah.And that's very real.I'm not making it out.No, no, no.Actually, I was just talking to someone inside of Meta.

（Charity）有些正在发生的事让我们震惊，我们最好为它们做好准备。所以那是真实的，那是真实的。而这些人在大多数公司里通常是极少数派，他们时时刻刻觉得自己寡不敌众。不过讽刺的是，这两边都觉得自己是那个渺小的少数派、都觉得寡不敌众、都觉得自己被压制，都觉得自己是在面对「AI 大佬们」或者「大怀疑派们」时挺身捍卫真理和勇气的那一方。而另一边——这件事往往归结为「谁在值班（on call）、谁不值班」。／（Gergely）哦，对。／（Charity）因为责任最终落到谁头上，谁就在眼睁睁看着心智模型在融化。他们看到的是垃圾代码，是自己所有的辛苦成果在溶解，而且看不到尽头。／（Gergely）说清楚一点：我们看到的是，那些为这些系统值班的人，他们遇到的故障更多了，他们看到的是（AI）带来的粗心大意。他们实实在在地看到，自从那群人开始更多地用 AI，我们的系统变得糟糕多了。／（Charity）糟糕多了。对。而且这是非常真实的，我不是编的。／（Gergely）不不不，我其实刚跟 Meta 内部的人聊过。

[39:34] Gergely Orosz

There's been this big drama where people have been reassigned.Oh, God, I know.I saw your post.So, not just my post since, and I haven't written about this since, and I'm not sure when this podcast came out, I might have not talked about it, is inside of Meta, they track SEVZeros, which is the highest severity.I remember.You remember SEVZeros.There has been a flurry of SEVZeros, so many of them.And you cannot hide.Like, this is, you know, Meta, like, this is black or white.And the past about two months, it's been crazy.And just so it happens, it's happening inside of Instagram, it's happening inside of WhatsApp, where the trust and safety, basically the reliability folks, have been axed, removed.So, it's impossible to deny the connection as well.Of course, it's not a direct one, but again, and each one has it as a postmortem.But Meta has not had this badge for closer to a decade.Yeah.Move fast and break things.And you put two plus two together.And when I told this story at a conference, people came up to me and they said, I'm so glad you talked about this because my company, different company, often VC funded or publicly traded, like, this is happening.People are, like, whispering to me, like, we are not Meta, but the same thing is happening.

（Gergely）那边最近有一场大戏，很多人被重新分配了岗位。／（Charity）哦天，我知道，我看到你那条帖子了。／（Gergely）不只是我那条帖子——那之后我还没写过这件事，我也不确定这期播客什么时候发，可能我到时候还没讲过：在 Meta 内部，他们跟踪 SEV0，也就是最高等级的故障。／（Charity）我记得，SEV0 我记得。／（Gergely）SEV0 出了一大堆，非常多。而且这东西藏不住——这可是 Meta，非黑即白。过去大概两个月，情况很疯狂。而且刚好，它就发生在 Instagram 内部、发生在 WhatsApp 内部——那些地方的「信任与安全」、基本上就是可靠性那批人，被砍掉了、被裁掉了。所以这个关联也没法否认。当然它不是直接的因果，每一次故障都各有各的复盘。但 Meta 已经将近十年没有过这种记录了。／（Charity）是啊，「快速行动，打破常规」。／（Gergely）你把二加二一算就明白了。我在一次会议上讲这个故事的时候，有人过来跟我说：我太高兴你讲了这个，因为我们公司——另一家公司，往往是风投支持的或者已经上市的——也在发生这种事。有人悄悄跟我说：我们不是 Meta，但同样的事情正在发生。

[40:52] Gergely Orosz

Same thing is happening.And you know what they all told me?They told me, I thought it's just us.Or I thought it's us and then my buddy who works at this other company.And suddenly it was like, oh, it's all of us.No, it's all of us.Yeah.No, it's a real thing.And the intercom folks, you know, what I love about them is they publish the real gnarly stuff, right?

（Gergely）同样的事情正在发生。而且你知道他们都跟我说什么吗？他们说：我以为只有我们这样。或者：我以为只有我们，还有我那个在另一家公司的哥们儿。然后突然之间就变成——哦，是我们所有人。／（Charity）不，是我们所有人。对。这是真事。而 Intercom 那帮人，我喜欢他们的一点就是：他们会把真正难看的部分也发出来，对吧？

[41:15] Charity Majors

They don't color it out.They don't color it out.And they showed that for 18 months, reliability and code quality went down.And it had just started to possibly be going back up.But it's still not there where it was.Still not there where it was.And they're very honest about it.And they're honest about it.Finally.So on.This is the thing.Like, stop, like, spitting in my, and telling me that, you know, like, it's just, this is my thing.It's like, we need to hear the wins.We need to hear what's, we need to hear about what's possible.We need to hear what's exciting.But you got to couple it with the costs.You got to couple it with the, is it worth it?

（Charity）他们不粉饰。／（Gergely）他们不粉饰。而且他们展示了：有 18 个月，可靠性和代码质量是往下走的。最近才刚刚有可能开始回升，但还没回到原来的水平。／（Charity）还是没回到原来的水平。／（Gergely）而他们对此非常坦诚。／（Charity）他们很坦诚。终于有人这样了。这就是我要说的事：别再往我脸上吐口水、还告诉我这是……这就是我的点：我们需要听到胜利，我们需要听到什么是可能的，我们需要听到令人兴奋的东西。但你必须把代价一起讲出来。你必须一起讲：这值得吗？

[41:58] Charity Majors

You got to couple it with what are we doing?What is happening?And I feel like part of the reason that both of these sides are getting so frustrated is because they're not, they're not connecting at all.And so the people who are seeing really incredible, there are some really incredible things happening in software right now.Like, with rewrites and with, you know, automating away, like, real toil.Like, not a single person that I've talked to would give it up.Yeah.Which is amazing.Like, they, they, it's so exciting.Nobody wants to take it away.But half of the people are seeing the wins and they're not connecting it to the cost.Which makes them think that, that their co-workers are just fuck nuts.Who are just like, oh, they just don't want to lose their jobs.They're just afraid of getting automated out of existence.They're just blah, blah, blah, blah, blah.Like, no, dude, you be on call and then see how you feel.You know?

你必须一起讲：我们在干什么？正在发生什么？我觉得这两边之所以都这么挫败，一部分原因就是他们根本没有连上线。那些看到了真正惊人成果的人——软件领域现在确实有一些非常惊人的事情在发生，比如重写、比如把真正的苦力活自动化掉。我聊过的人里没有一个愿意把它交回去。对，这太棒了，太让人兴奋了，没人想把它拿走。但一半的人只看到了收益，却没有把它跟代价连起来。这让他们觉得自己的同事就是一群脑子有病的人，觉得他们「只是不想丢饭碗、只是怕被自动化掉、只是叽里呱啦」。不，兄弟，你去值一次班，然后再看看你什么感受。

[42:49] Charity Majors

And, and there's a mirror effect kind of happening where the folks who are on call, who are responsible for this stuff, they don't actually believe that these wins are real.They think they're all cooked because they're not hearing the quiet part said out loud that, yeah, we're seeing this win, but this is what it costs.We're still cleaning this up.We're still, and so that, that's my, that's my beg to everyone who loves Gary Gettys Podcasts and listens to this is,tell the whole story, talk about the costs.We're all doing, we're all in it together.Yeah, because you're right.Like this technology is not going anywhere.It will make really big positive change at a bunch of places.It's here.But it's not magic.It's, it's not magic.And I think this is what you said in, in make AI boring and another great article of yours, what you said is AI is just technology.Just technology.And you were arguing that let's just realize it's technology, it's a tool and let's learn to use it well.Now, one other thing you said, which is very interesting is software will be the killer app with AI, which is very unique.Let's talk a little bit about that.Software is made of logic and language.AI is made of logic and language.

（Charity）而且还有一个镜像效应：那些在值班、对这些东西负责的人，其实并不相信那些收益是真的。他们觉得那全是编的，因为他们没听到那句被咽下去的话——是的，我们看到了这个收益，但这是它的代价，我们现在还在收拾这个烂摊子。所以，这是我对所有喜欢 Gergely 播客、在听这期节目的人的恳求：把完整的故事讲出来，把代价也讲出来。我们都在这条船上。／（Gergely）对，因为你说得对，这项技术不会消失。它会在很多地方带来非常大的正向改变。它已经在这儿了。／（Charity）但它不是魔法。／（Gergely）它不是魔法。我想这就是你在《让 AI 变无聊》以及你另一篇好文章里说的：AI 只是技术。／（Charity）只是技术。／（Gergely）你的论点是，我们就把它当成技术、当成一个工具，然后学会把它用好。你还说过另一件很有意思的事：软件会是 AI 的杀手级应用。这个观点很独特，我们聊聊这个。／（Charity）软件由逻辑和语言构成，AI 也由逻辑和语言构成。

[44:03] Charity Majors

And because of that, we can bake in guardrails.We can bake in checks.We can bake in validation that we, I don't know how we do that in other parts of our lives or other applications.And so it totally makes sense to me that software is what AI is best at.I mean, you see like in the courts, they're starting to get lawsuits for, the court is suing lawyers who are submitting briefs that have hallucinated crap in them.How do you check for that?

（Charity）正因如此，我们可以把护栏烤进去，把检查烤进去，把验证烤进去——而这在我们生活的其他部分、在其他应用里，我真不知道该怎么做。所以在我看来，软件就是 AI 最擅长的东西，这完全说得通。／（Gergely）你看法庭那边，已经开始出现诉讼了：法院在起诉那些提交了含有幻觉内容的诉状的律师。你怎么去检查那个东西？

[44:35] Charity Majors

You know, with the same, we have structured data.We have, you know, a whole, and I just don't know how you account for that in the same way.It might also mean that whatever will work outside of the software industry for AI, it will be a subset of what will work in the second.Basically, if we can do something with AI, if we can automate a process or something, you might be able to do it in other industries, but maybe not.But if we cannot do it, good luck.You will not be able to do it because we have the domain where you can validate stuff.We have incredible training data on code that compiles, right?

（Charity）我们这边有结构化数据，有一整套东西，我实在不知道在那边怎么用同样的方式去核对。／（Gergely）这可能也意味着：AI 在软件行业之外能跑通的东西，会是它在软件行业里能跑通的东西的一个子集。基本上就是，如果我们能用 AI 做某件事、能自动化某个流程，那你在别的行业也许能做，也许不能。但如果我们都做不到，那你就自求多福吧——因为我们这个领域是能验证东西的领域。我们有海量高质量的、能编译通过的代码训练数据，对吧？

[45:11] Gergely Orosz

Yes.Like in a bunch of places, you might have like training data, like with magazines, you might have like low quality magazines or whatnot.Do you see what I mean?I mean, back to your point about humans like their determinism.They like things to happen the same way.And it's very interesting because as I think of it, you know, one of my businesses is writing.I write a newsletter that is, I like to think it's good and it's worth reading.It is.And I would have said, if you asked me, what is AI really good at?

（Charity）对。／（Gergely）而在很多别的地方，你的训练数据可能是杂志之类的——有些是低质量杂志之类。你懂我意思吧？回到你说的人类喜欢确定性这一点：他们喜欢事情每次都一样地发生。这很有意思，因为我想到，我的一门生意是写作。我写一份 newsletter，我愿意认为它写得不错、值得一读。／（Charity）确实值得。／（Gergely）如果你问我 AI 到底最擅长什么，我以前会说……

[45:38] Gergely Orosz

Now, obviously, it's good at coding, but before that, it was good at writing.It was like my mind was blown that it can actually control the language.When all the newer models come out, I do this test where I say like, all right, like, you know, write an article in the style of the pragmatic engineer.And every single time I can tell it's AI generally because it's repetitive.It has this thing.So my point is, AI is actually not as good as writing prose as it's a lot better in writing code.Way better at writing.When I ask to write code, like, I often I'm like, yeah, this is something I could have written.Whereas when I asked it to write words, I'm like, I would have never written this and it has training data on me.So who knows?

当然现在它擅长写代码，但在那之前，它是擅长写作的。我当时脑子都炸了：它居然真的能驾驭语言。每次有新模型出来，我都会做一个测试：我说，好，用《务实工程师》的风格写一篇文章。而每一次我都能看出来这是 AI 写的，因为它很重复，它有那种固定的腔调。所以我的意思是，AI 写散文其实没有它写代码那么好。／（Charity）写代码好得多。／（Gergely）当我让它写代码时，我常常觉得：嗯，这东西我自己也能写出来。而当我让它写文字时，我会觉得：这句话我永远不会这么写——而它是有我的训练数据的。所以，谁知道呢？

[46:14] Charity Majors

This might prove that software is the best fit.I think it is.Software is a simplified version of language for a purpose.Yeah, I, you know, at first, everybody was like trying to come up with ways to be more efficient and write with AI and everything.And I sunk a lot of cycles into that.And I have decided not to think anymore because writing is thinking on paper.Sure.And there's no shortcut for doing that thinking.Anything that I write, it's not content.You know, it's not content where it's just like, well, generate me a couple thousand words.Which I'm not shaming anyone who generates content, but that's not what I'm trying to do.I'm trying to think through hard and interesting problems and share them with people.And I don't think AI is the appropriate tool to use for that.I use it for structure.I'll be like, hey, read this and give me feedback and stuff.But, you know, so I think we should not forget that as we improve our, you know, our skills, our capability, our experience, our thoughts, we do become more valuable.And I have this idea and this might be a flawed idea, but I think it's I think it will be correct that, you know, five years from now, how will people be hired?

（Gergely）这也许证明了软件才是最契合的领域。／（Charity）我觉得是。软件是为某个目的而简化过的语言。是这样——一开始所有人都在想办法用 AI 更高效地写东西，我也在这上面烧了很多时间。后来我决定不再（用它）思考了，因为写作就是在纸上思考。／（Gergely）当然。／（Charity）而那份思考没有任何捷径。我写的任何东西都不是「内容」。它不是那种「给我生成几千字」的内容。我不是要羞辱任何生产内容的人，但那不是我想做的事。我想做的是把困难而有趣的问题想透，然后分享给别人。我不认为 AI 是干这件事的合适工具。我用它做结构：比如「嘿，读一下这个，给我点反馈」。但是——所以我觉得我们不该忘记：当我们提升自己的技能、能力、经验和思想时，我们本人是会变得更值钱的。／（Gergely）我有个想法，可能是个有缺陷的想法，但我觉得它会被证明是对的：五年后，人会怎么被雇用？

[47:26] Gergely Orosz

Now, of course, we know the tools will be better and all that.But in the end, I think it'll be like this.Someone's sitting here and I'm going to be interviewing with you.I'm going to be trying to get into your company.Honey, probably Honeycomb, right?

当然，我们知道工具会更好，等等。但最终我觉得会是这样：有个人坐在这儿，我在跟你面试，我想进你的公司——大概是 Honeycomb 吧？

[47:37] Gergely Orosz

And we will be having a conversation and you will judge me based on how I respond.And the more I have spent thinking and bettering myself, the more valuable I will be to you because you will have all these candidates and some of them will have outsourced or other things to AI and they will have a blank because that thing is off.Guess who you will want to work with, right?

我们会有一场对话，而你会根据我怎么回应来判断我。我花在思考和自我提升上的时间越多，我对你就越有价值。因为你会有一堆候选人，其中一些人把这些事外包给了 AI，他们身上会有一块空白，因为那部分是关掉的。你猜你会想跟谁共事？

[47:58] Charity Majors

I am so excited about leaning into the parts of being human together.I don't like the feeling of chatting all day back and forth between agents and people on Slack.Like it feels way too similar.It's just gross.Honeycomb is a fully distributed company, which was never we always wanted to have a hybrid model.But the office has not come back.And I feel all kinds of ways about this because I love not leaving the house.But at the same time, I crave this more full, like I'm so glad you're here.It's so nice to see you.We were just talking how it is different.We've done a podcast remote and it was a decent one, but this is more enjoyable.Yes.And so part of what I hope we do is just remember that we're in charge of the machines.They serve us.And this is still what matters.Now, I want to pull back to something different.I'll just talk a bit more about ops and DevOps and get one of your spicy steaks.So now that we have AI, we can actually just, you know, badmouth some of the other thing or just be real.Let's talk about DevOps.Just can we go back a little bit in time?

（Charity）我特别期待去加倍投入「一起做人」的那些部分。我不喜欢一整天在 Slack 上，在 agent 和人之间来回聊天的感觉，它们太像了，让人不舒服。Honeycomb 是一家完全分布式的公司——我们本来一直想做混合模式，但办公室再也没回来过。我对此百感交集，因为我爱不出门；但同时我又非常渴望更完整的（连接），比如：我真高兴你在这儿，见到你真好。／（Gergely）我们刚才还在说这有多不一样。我们远程录过一期，那期也不错，但这次更享受。／（Charity）是的。所以我希望我们能做到的一部分，就是记住：我们才是机器的主人，它们是伺候我们的。这才是真正重要的东西。／（Gergely）现在我想拉回到另一个话题，多聊聊运维和 DevOps，掏出你的一些辛辣观点。既然现在有了 AI，我们其实可以顺便吐槽一下别的东西，或者就说点实话。我们聊聊 DevOps 吧，能不能往回倒一点？

[49:05] Gergely Orosz

You were there.Why was it created?And in the end, there was this massive DevOps movement in the 2010s.Do you think it succeeded?Do you think it failed?So before DevOps, we needed a DevOps because there was devs and ops.And there was the proverbial wall that code got thrown over, right?

（Gergely）你当时就在场。它为什么会被创造出来？最后在 2010 年代形成了一场声势浩大的 DevOps 运动。你觉得它成功了还是失败了？／（Charity）在 DevOps 之前，我们之所以需要 DevOps，是因为有 dev 和 ops 两拨人，中间有那堵著名的墙，代码就是从墙上扔过去的，对吧？

[49:25] Charity Majors

And ops were the people who were in charge of the IT.They deployed.They managed the servers.They set the Linux version.And crafted Linux, you know, pluggable storage models and everything.That was always a bad idea because it's split brain.Half of you are writing the code and the other half are understanding it.I would argue that you can't really understand the code you write unless you're operating it.So, you know, the DevOps movement did a lot of good trying to knit back together that sort of original sin.And, you know, around the time that I was a sysadmin, there was this big push.All right, ops people, learn to code.And great.I'm glad that happened.Everyone who works with computers should be writing code.I feel like the wave after that was a little less successful, which is like, okay, software engineers, time to learn to understand your code in production.But I also think that, in my mind, 20 years of DevOps was really about one thing.Trying to create one feedback loop that connected people writing code to that code in production.And it failed.I mean, it failed.To this day.Like, they're done by two different domains.You know, there are some people who, I mean, it's...And I'll show you this diagram that you drew.

（Charity）运维是负责 IT 的那批人。他们部署，他们管服务器，他们定 Linux 版本，他们精雕细琢 Linux 的可插拔存储模型之类的东西。这一直是个坏主意，因为它是「裂脑」：一半人写代码，另一半人理解代码。我甚至会说，除非你在运行它，否则你并不真的理解你写的代码。所以 DevOps 运动做了很多好事，试图把那个「原罪」重新缝合起来。在我还是系统管理员的那个年代，有过一次大推动：运维的各位，学写代码吧。很好，我很高兴那件事发生了。任何跟计算机打交道的人都该会写代码。但我觉得再下一波就没那么成功了，那一波是：好，软件工程师们，该学着在生产环境里理解你们的代码了。而我也认为，在我心里，二十年的 DevOps 其实就是关于一件事：试图创造一个把「写代码的人」和「代码在生产环境里的样子」连起来的反馈回路。而它失败了。我是说，它失败了。／（Gergely）直到今天。／（Charity）对，它们仍然由两个不同的领域负责。当然有些人……／（Gergely）我把你画的这张图给大家看一下。

[50:44] Gergely Orosz

We're now at an agency.We'll put it on the...So viewers can see it.This is your...I think it's a really nice draw up of how there's no feedback loop.Like, the ops people, or oftentimes we call it platform teams, they manage the infralayer.Engineers deploy there.And so, to be clear, I think that's actually good in finding healthy.I think that there are separations of concerns where you can't expect anyone to do everything.And the nice separation of concern is, do I own...Am I responsible for the stability of the things that you put code on?

（Gergely）我们现在有画面了，我会把它放上去，让观众能看到。这是你画的，我觉得画得非常好，说明了为什么没有反馈回路：运维的人——我们现在常常叫他们平台团队——管着基础设施层，工程师把代码部署上去。／（Charity）说清楚一点，我其实觉得这样是好的、是健康的。我认为确实存在职责分离，你不能指望任何人什么都做。而一个很好的职责切分是：我负责的是「你把代码放上去的那个东西」的稳定性吗？

[51:15] Charity Majors

Or am I responsible for the code that I put on the thing?Right?That is a nice seam because you want the infrastructure to be stable.To protect itself.To be resilient and all these things.And you want your code to be oriented towards, is every single user having a good experience?

还是我负责「我放上去的那段代码」？对吧？这是一条很好的接缝，因为你希望基础设施是稳定的、能自我保护、有韧性等等；而你希望你的代码是面向「每一个用户是不是都有好的体验」的。

[51:35] Gergely Orosz

You can have one of those things be true and the other not be true.Like, they are decouple-able.And actually, this is like even the most modern companies.I often refer to Anthropic as this company which operates in a very different way to most companies.They're very successful despite doing a lot of different things.However, internally, they have platform teams.They have the cloud platform teams.And then they have Applied AI, which is more of the feature teams, the integration.And the two, I talked to both of them.They just have a very different outlook.They have a very different view on even basic stuff like, will software engineers be obsolete?

（Charity）这两件事可以一个成立、另一个不成立，它们是可解耦的。／（Gergely）而且事实上，即便是最现代的公司也是这样。我经常提到 Anthropic 这家公司，它的运作方式跟大多数公司非常不同，做了很多不一样的事却仍然非常成功。但在内部，他们也有平台团队，有云平台团队；然后有 Applied AI，更接近功能团队、做集成。这两边我都聊过，他们的世界观非常不一样。哪怕是最基本的问题，比如「软件工程师会不会被淘汰」，他们的看法都完全不同。

[52:09] Gergely Orosz

The people on the platform team were like, no, we're working really hard.And on the Applied, they're like, well, maybe it will happen.Yeah, that does not surprise me one tiny biota.But so this company, Anthropic, that started with a flying page, they arrived at the same place?

（Gergely）平台团队的人说：不会，我们正拼命干活呢。而 Applied 那边说：嗯，也许会吧。／（Charity）这一点都不让我意外。／（Gergely）但这家公司，Anthropic，是从一张白纸起步的，结果也走到了同一个地方？

[52:24] Charity Majors

Yeah, yeah.No, I think it's the right separation of concern.And I'm not trying to erase it.But I think that to be a good engineer, you need fast feedback loops.And this is part and parcel with the whole, oh, the source of truth is the code.But if that's where you live, if you live in the land of how it should theoretically work, no.And I think that with agents, they're breaking that, right?

（Charity）对，对。不，我觉得这是正确的职责切分，我不是要抹掉它。但我认为，要做一个好工程师，你需要快速的反馈回路。这跟那个「真理之源是代码」的观念是一体两面。可如果你只住在那里，如果你住在「理论上它应该怎么运行」的国度里，那不行。而我觉得有了 agent，它们正在打破这一点，对吧？

[52:50] Charity Majors

They're breaking that and they're forcing another thing on the observability trip is a lot of people,if you say like, what is observability?They'll be like, ah, well, there's three pillars.There's metrics, logs, and traces.We talked about this last time.Metrics and logs, I would say, are system exhaust.They're the exhaust pipe.And they're never going away because every team runs a ton of third-party software.They didn't write it.They don't own it.They just have to run it.And it's outputting shit.Yeah.And you just got to put it somewhere.You observe it.You see what.Yeah, yeah, yeah.And then you do stuff with it.Yeah.And, you know, you should put it somewhere cheap.There's a ton of it.It's not super high value, but you definitely need it, right?

（Charity）它们在打破这一点，而且在逼出另一件事。在可观测性这条线上，很多人如果你问他们「什么是可观测性」，他们会说：啊，有三大支柱，指标（metrics）、日志（logs）和链路追踪（traces）。我们上次聊过这个。指标和日志，我会说它们是系统的尾气，是排气管。它们永远不会消失，因为每个团队都要跑一大堆第三方软件——不是他们写的，不归他们所有，他们只是必须运行它，而它在往外吐东西。／（Gergely）对。／（Charity）你总得把它放到某个地方。你观察它，你看看……／（Gergely）对对对。／（Charity）然后你拿它做点事。／（Gergely）对。／（Charity）而且你应该把它放在便宜的地方。这类数据量巨大，价值不算特别高，但你确实需要它，对吧？

[53:28] Charity Majors

And you can't do anything about it.You just take it and put it somewhere.Then there's your code.There's your crown jewel.The code that makes you a company.And for that code, your telemetry should be a product decision.It should be you store it once with all the connective tissue because the value of richdata goes up, not linearly, not even exponentially, combinatorially.If you have a wide event or a trace with 29 bits of data and you add a 30th, that 30th ismore valuable than all the others.Like, it is just so powerful.And with non-deterministic software, you know right up front, you can't predict what it'sgoing to do.You have to.Like, that is a product decision to capture that trace.So let's talk specifically about modern observability and like companies that are, you know, likeeither building AI-related code or just complicated code that they're generating.In the old world, again, like I'm just being, you know, like observability 101 back in a day.The way I would have written the code is you write the code and you think like, hmm, somethingfunny might be going on here.Let me do a log or an info or a warn.And then I would also try to maybe if we're printing some production, I realize like, okay,

（Charity）而且你对它无能为力，你只能拿着它放到某处。然后是你自己的代码，那是你的皇冠明珠——那是让你成为一家公司的代码。对这部分代码，你的遥测（telemetry）应该是一个产品决策。你应该带着全部的连接组织把它存一次，因为丰富数据的价值增长不是线性的，甚至不是指数的，而是组合式的。如果你有一个宽事件（wide event）或者一条 trace，上面已经有 29 个字段，你再加第 30 个，那第 30 个比前面所有字段都更有价值。它就是这么强大。而面对非确定性软件，你一上来就知道你无法预测它会做什么，所以你必须（捕获）。捕获那条 trace 本身，就是一个产品决策。／（Gergely）那我们具体聊聊现代可观测性，以及那些正在写 AI 相关代码、或者只是在生成复杂代码的公司。在旧世界里——我这是在讲当年的「可观测性 101」——我写代码的方式是：写着写着我想，嗯，这儿可能有点蹊跷，那我打条 log，或者 info，或者 warn。然后如果我们在生产里打印东西，我会意识到：好吧，

[54:48] Charity Majors

well, I guess it's crashing and we don't have any logs there.So I guess it's some other part.Let me put a tool that will like log everything and I'll have a bunch of stuff.Now, this is the simplest way of thinking.In kind of a modern business where I'm like, I know this is high value stuff.What are ways that I can go about that's actually maybe a bit like more practical than becauseI just told you a super basic one.Auto instrumentation has gotten so good in recent years.If you're using open telemetry and everyone should be using open telemetry.All of the common patterns, like all of the models are trained on them.So it is literally faster and easier to build with instrumentation than not to.And with instrumentation and do just what once once I have the code and a compile stepor an extra step, it just adds it to the right lines.This is what's important, right?

（Gergely）它崩了，可我们那儿没有任何日志，那大概是别的部分出的问题。那我上个工具，把什么都记下来，我就有一堆东西了。这是最朴素的想法。那么在一个现代的、我知道这是高价值的业务里，有哪些比我刚才说的那个超级初级的做法更实际一点的路子？／（Charity）近几年自动埋点（auto instrumentation）已经好得不得了了。如果你在用 OpenTelemetry——而所有人都应该用 OpenTelemetry——所有常见的模式，所有模型都是在这些东西上训练过的。所以现在带着埋点去构建，字面意义上比不带更快、更省事。有了埋点，一旦我有了代码，再加一个编译步骤或者额外一步，它就会把埋点加到该加的行上。这才是关键，对吧？

[55:37] Charity Majors

It's part of just developer intent, right?This is how you declare your intent and that's how you check up on your intent in production.It's honestly gotten so much simpler.You know, I don't fault developers or anyone else for not kind of closing that loop withDevOps because the fact is it was prohibitively hard and time consuming and difficult because,you know, you're an old school software engineer and you sit down, write some code.You're like, ah, here, I should instrument it and look at it in production.So you're like, okay, I've got a bit of data and I want to do something with it.All right.Is it a metric, a log, a trace, an exception, an error, a profiling?

这就是开发者意图的一部分，对吧？这是你声明意图的方式，也是你在生产环境里回头验证自己意图的方式。老实说，它已经简单太多了。我不怪开发者或者任何人没能跟 DevOps 把那个回路闭上，因为事实是，过去这件事难到、耗时到、麻烦到近乎不可能：你是个老派软件工程师，坐下来写代码，然后想「啊，我该给它埋点，然后去生产环境看看」。于是你说：好，我拿到了一点数据，我想拿它做点什么。好，它是指标、日志、trace、异常、错误，还是 profiling？

[56:20] Charity Majors

You know, just like, okay, if it's a metric, is it a counter?Is it a gauge?Is it a, you know, just like all down, it takes so, and then, well, what type of data is it?Is it going to have high cardinality?

然后：好，如果它是指标，那它是计数器（counter）？是仪表盘量（gauge）？还是……全都得往下问一遍，太费劲了。然后：这是什么类型的数据？它会不会是高基数（high cardinality）的？

[56:32] Charity Majors

Is it going to be a, you know, just like, and you can blow it.Yeah, it's just like, if it's a log line, which log level do I do?Do I append it to?Like, it's just, you could double, triple, quadruple the amount of time that you spentwriting the code trying to instrument it and then still wouldn't be done.Like, you deploy it and then it's like, okay, I know the name of the thing that I added,but how do I find it?

它会不会是……然后你还可能搞砸。对，就像：如果它是一行日志，我该用哪个日志级别？我要把它追加到哪儿？这么下来，你花在「给代码埋点」上的时间可以是你写代码时间的两倍、三倍、四倍，而且还没弄完。你把它部署上去，然后想：好，我知道我加的那个东西叫什么名字，可我要怎么找到它？

[56:54] Charity Majors

How do I display it?How do I create a dashboard?It's just like, that was prohibitively, that was really hard.But now we can bring all of this to you, right, in your development environment.It is easier and faster to instrument with telemetry than without it.And you don't have to leave your development environment to go and get it, you know?

我怎么把它显示出来？我怎么建一个 dashboard？这些以前难到近乎不可能，是真的很难。但现在我们可以把这一切直接带到你面前，带进你的开发环境里。现在带遥测埋点比不带更容易、更快，而且你不用离开开发环境去别处取它。

[57:16] Charity Majors

You could have the agent, like, we've built some really cool shit at Honeycomb where it'lljust, it'll be like, oh, hey, that thing that you wrote, you know, maybe you want to lookat this.And you can, you can control how robust it is.You can, you know, but it's right there.And that's how it should be.It should be part of your development loop.Can we talk about what spans are?

（Charity）你可以让 agent 来做——我们在 Honeycomb 做了一些很酷的东西：它会主动说，哦，嘿，你刚写的那个东西，也许你想看看这个。而且你可以控制它做到多严密。它就在那儿，本来就该这样。它应该是你开发回路的一部分。／（Gergely）我们能聊聊 span 是什么吗？

[57:34] Charity Majors

Because I'll quote Eric Riddock, who was in the world of LinkedIn, the basic idea of observabilityfor applications is don't use logs or metrics, just put it all in spans.What are spans?Spans are bits of a trace.I mean, a trace is just a structured log with some fancy fields, right?

（Gergely）因为我要引一句 Eric Riddock（人名 ASR 存疑）——他在 LinkedIn 的圈子里——他说：应用可观测性的基本思路就是，别用日志、也别用指标，把所有东西都放进 span 里。什么是 span？／（Charity）span 是 trace 的组成部分。我是说，trace 其实就是一条带了一些花哨字段的结构化日志，对吧？

[57:53] Charity Majors

And so the span is the subset of the trace that makes up the entire duration.And I don't know if you've followed any of this, but like the default building block hasbeen the transaction for as long as the web has been around.Yeah.That doesn't work anymore.With, specifically with AI.Yeah.We just, we just ship something called timeline that is like, it sits on top of spans.So, you know, if, if you, you know, if you, if you run something like intercom, you havegot a chat thing and a customer's like, I'm complaining.Conversation going on.Yeah.Customer's like, I'm complaining.You're like, okay.So you've spent up an agent, supervisor agent that spins up more agents and each of themcalls APIs.Each of them calls like storage backends and stuff.And then the customer has another, it could span hours, right?

（Charity）而 span 就是 trace 里构成整段时长的那些子段。我不知道你有没有关注这方面，但自从 Web 出现以来，默认的基本构件一直是「事务（transaction）」。／（Gergely）对。／（Charity）那个东西现在不管用了。／（Gergely）具体来说是在 AI 场景下。／（Charity）对。我们刚发布了一个叫 Timeline 的东西，它建在 span 之上。你想想，如果你在跑类似 Intercom 那样的东西，你有一个聊天窗口，客户在那儿投诉——／（Gergely）对话在进行中。／（Charity）客户说我要投诉，你说好的。于是你启动了一个 agent，一个主管 agent，它又启动更多 agent，每个 agent 都在调 API，每个都在调存储后端之类的东西。然后客户又来一次……这可能跨越好几个小时，对吧？

[58:41] Gergely Orosz

And you need to be able to zoom out and visualize the whole thing.It's super cool.And so this is a new primitive that you came up for these use cases where there's a conversationor like an LM is involved and you have like.It's like a meta trace.Okay.Yeah.So I guess.A trace of traces.So we need these new building blocks actually just be able to work with.Yeah.Interesting.So I guess this is something to keep in mind.Like any, any, any engineer who's like building on top of LLMs.Who is an AI engineer now?

（Charity）你需要能够拉远视角、把整件事可视化出来。这超酷的。／（Gergely）所以这是你们为这类场景造的一个新的原语——有对话、有 LLM 参与的场景。／（Charity）它像是一条元 trace。／（Gergely）好。／（Charity）trace 的 trace。／（Gergely）所以我们确实需要这些新构件才能干活。／（Charity）对。／（Gergely）有意思。所以我猜这是要记住的一点：任何在 LLM 之上做开发的工程师……／（Charity）也就是现在所谓的 AI 工程师。

[59:14] Gergely Orosz

As, as we know.It's either that or you've just got all these tabs open with traces.You're just copy pasting IDs from one to the next.Yeah.Or if you're a large enough company, you might've built your own in-house tool.Or you might've built your own in-house tool.But we know that's, it's doable, but it's painful.It's doable.It's painful.I'm really looking forward to seeing over the next few months or year or whatever, just the, the marriage of tests and telemetry and evals from a telemetry perspective.With agents and AI agents being around, a lot of them are, are now very useful to connect to observability stores.You can go on and do stuff.However, one question that comes up is, well, agents have a finite context window and observability.You can really easily overload that.What are approaches you've seen of agents either using honeycombs or, or, or some other data sources to like make them productive?

（Gergely）我们都知道。／（Charity）要么就是你开着一堆装着 trace 的标签页，在它们之间来回复制粘贴 ID。／（Gergely）对。或者如果你公司够大，你可能自己造了个内部工具。／（Charity）或者你自己造了个内部工具。／（Gergely）但我们知道那是能做的，只是很痛苦。／（Charity）能做，但很痛苦。我特别期待在接下来几个月、一年或者更久，看到测试、遥测和 evals 从遥测视角上的结合。／（Gergely）有了 agent、AI agent 之后，很多 agent 现在接上可观测性数据存储是很有用的，你可以让它去干活。不过随之而来一个问题：agent 的上下文窗口是有限的，而可观测性数据很容易就把它撑爆。你见过哪些做法，能让 agent 用 Honeycomb 或者别的数据源真正产出效果？

[1:00:12] Charity Majors

Have you seen some patterns?There's a lot of trash data out there.Um, and, and a lot of traditional telemetry data, metrics, logs, traces, whatever it's all.So it tends to fill up your context window with crap when the most important part of the data is again, the relationships between the data.So if you can, and in fact, one of the AI SRE startups posted this great piece a couple months ago about how they, they see the agents that they deploy in the wild bypass the observability data most of the time.And they go upstream to find richer, intact telemetry data.So that's what I would say.Either you give your agents that, but it's, it's the relationships that matter, right?

（Gergely）你看到过什么模式吗？／（Charity）外面有大量垃圾数据。而且很多传统遥测数据——指标、日志、trace，随便什么——都是这样。所以它往往会把你的上下文窗口塞满垃圾，而数据里最重要的部分，再说一遍，是数据之间的关系。所以如果你能……而且事实上，几个月前有一家做 AI SRE 的创业公司发过一篇很棒的文章，讲他们看到自己部署在真实环境里的 agent，大多数时候会绕开可观测性数据，直接往上游去找更丰富、更完整的遥测数据。所以我的建议就是这个：要么你把那种数据给你的 agent；但重点是，重要的是关系，对吧？

[1:01:01] Gergely Orosz

Because that's what actually helps the AI make decisions.And when it comes to observability, I cannot not mention your book, Observability Engineering, and you have a second edition.Can you tell me why you felt the need to write it and what's new in it?

（Charity）因为那才是真正帮 AI 做判断的东西。／（Gergely）说到可观测性，我不能不提你的书《可观测性工程》（Observability Engineering），你出了第二版。能说说你为什么觉得有必要写它，以及里面有什么新东西吗？

[1:01:15] Charity Majors

Oh, man.The whole thing is new.So O'Reilly, any, any time a book is considered successful, and if the topic is still relevant, they'll ask if you want to write a second edition.So it's not really, but I was really excited to write it.The first book, I don't want to say I wasn't proud of it.You're like, you're not like your children and your books are not supposed to like say anything bad about them, you know, because it's fine.But it was written 2019 to 2021.The definition of observability meant one thing when we started and another by the time we ended.And there was at no point where I was like, oh, this book is great.Let's ship it.It was just like, oh, I can't do this anymore.Just like, please take it.And I hope that's enough.Now it feels like the definition of observability is more settled.It's everything else in the world that's like changing and crazy and all.So I think it's a good book.I hope it can help a bunch of folks.It's got six parts.So the first part is, and I wrote parts one and six.First part is just kind of like grappling with what does it mean to run deterministic and non-deterministic systems, you know?

哦天。整本都是新的。O'Reilly 的规矩是，只要一本书被认为是成功的、而且主题还有相关性，他们就会问你要不要写第二版。所以严格说不是我主动，但我当时非常兴奋要写它。第一本书——我不想说我不为它骄傲。人家说你不该说自己孩子和自己书的坏话嘛，反正它挺好的。但它是 2019 到 2021 年写的。我们动笔时「可观测性」这个词是一个意思，写完时又是另一个意思。整个过程中从来没有一刻我觉得「哦这本书太棒了，发吧」，而是「哦我实在写不动了，你们拿去吧，希望这够了」。现在感觉「可观测性」的定义已经比较稳定了，反倒是世界上的其他一切在疯狂变化。所以我觉得它是一本好书，希望它能帮到一批人。它一共六个部分。第一部分和第六部分是我写的。第一部分基本上是在搏斗一个问题：同时运行确定性系统和非确定性系统，到底意味着什么？

[1:02:20] Charity Majors

And then, you know, my co-authors, Liz and Austin and George.Part two and three is how do you instrument your code and how do you understand it?And there are parallel tracks for doing this with or without AI.And a couple of great guest columns from Jeremy.And then parts four and five are we have a whole lineup of guest authors and use cases and deep dives.Hanson Ho did one on Frontend and Frontend and Mobile.We've got some great ones on CICD.Clickhouse did one on columnar storage.Some really, really stellar things.There's a chapter from Kesha at Finn on how they use it iteratively to like do observability.Wow.So this is a brand new book.It's not a lot of second editions are like, oh, we added like two chapters.This is an entire rewrite and it's twice as long.The first one was 250 pages.This one is 600 pages.Okay.So I'm interested now.I'm going to get this book.And the part six, it's my baby.And it was originally supposed to be three chapters for observability engineering teams.And it turned into the third of the book.It's 200 pages.But it's topics for observability governance for leaders.And it starts with an open letter to CTOs telling them why all their big AI goals are blocked behind our ability to make sense of their system.

（Charity）然后是我的合著者 Liz、Austin 和 George。第二、三部分讲怎么给你的代码埋点、怎么理解它，而且有「用 AI」和「不用 AI」两条并行的路径，还有 Jeremy 写的几篇很棒的客座专栏。第四、五部分是一整排客座作者、使用场景和深度剖析：Hanson Ho 写了前端和移动端的一篇；CI/CD 那块有几篇很好的；ClickHouse 写了列式存储的一篇；还有一些真的非常出彩的东西。其中有一章是 Fin 的 Kesha 写的，讲他们怎么迭代式地做可观测性。／（Gergely）哇。／（Charity）所以这是一本全新的书。很多第二版是「哦我们加了两章」，而这本是彻底重写，篇幅是原来的两倍：第一版 250 页，这一版 600 页。／（Gergely）好，我现在有兴趣了，我要去买这本书。／（Charity）第六部分是我的心头肉。它原本只打算写三章、写给可观测性工程团队看，结果变成了全书的三分之一，200 页。它讲的是面向管理者的可观测性治理话题。开篇是一封写给 CTO 的公开信，告诉他们：你们所有宏大的 AI 目标，都卡在「我们能不能看懂自己的系统」这件事后面。

[1:03:47] Charity Majors

You know, and then we talk about, you know, software delivery.No buzzwords.Just systems theory.Right.Just if you like Donella Meadows stuff, then you will like it.And then there's a chapter on how to quantify the impact of observability for your finance.How to treat observability as an investment versus a cost center.And when you should use observability as a cost center.And when you should treat it like an investment.Because it inherits the type of software that you're observing, you know.And there's a great guest chapter from Rick Clark on staff plus principal distinguished engineers who are trying to drive massive change without authority.How do you do that?

然后我们会谈软件交付，没有任何时髦词，只有系统论。对，如果你喜欢 Donella Meadows 那一套，你就会喜欢它。接着有一章讲怎么向你的财务部门量化可观测性的影响；怎么把可观测性当成投资而不是成本中心来对待；以及什么时候你该把它当成本中心、什么时候该当投资——因为它会继承你所观测的那类软件的属性。还有 Rick Clark 写的一篇很棒的客座章节，写给那些想在没有正式权力的情况下推动巨大变革的 Staff+/Principal/Distinguished 工程师：你要怎么做到？

[1:04:30] Charity Majors

And how is observability vital to that?And then there's a chapter on build versus buy versus open source.I mean, it sounds to me that anyone who is inside or wants to be inside a platform engineering team, may you be an engineer or a leader.If you're in charge of...You probably want to read this book.And at the end, there's a chapter that is possibly one of my favorites.Which is called The Art and Science of Vendor Partnerships.And it's just talking about how we can't build all the software that we need.And great vendor partnerships are ones where you have influence over their roadmap and they trust you to do these things.And like talking about how most transformations fail.The ones that succeed, succeed because someone on the inside has trust and credibility.People believe when you say something, it is true.You know, it cuts through bureaucracy like a hot knife through butter.When it comes to partnering with, you know, the sales org of another company, you do not have trust and credibility.You work to build trust through reciprocity.You learned just how much you can trust them over time, right?

（Charity）以及可观测性为什么对这件事至关重要？然后还有一章讲自建、采购还是用开源。／（Gergely）在我听来，任何身处平台工程团队、或者想进平台工程团队的人——不管你是工程师还是管理者，如果你负责……／（Charity）你大概会想读这本书。而在最后，有一章可能是我最喜欢的之一，叫《供应商合作关系的艺术与科学》。它讲的就是：我们不可能把需要的所有软件都自己造出来。而好的供应商合作关系，是你对他们的路线图有影响力、他们也信任你去做这些事。还讲到大多数转型都会失败，那些成功的之所以成功，是因为组织内部有人拥有信任和信誉——你说什么，人们就相信那是真的。这种信誉能像热刀切黄油一样切开官僚层。而当你要跟另一家公司的销售组织合作时，你并没有信任和信誉，你得通过互惠一点点建立信任，你会随着时间学到自己到底能信他们到什么程度，对吧？

[1:05:40] Gergely Orosz

But the best vendor relationships are the ones where you genuinely, you feel like their successes are your successes.Your successes are their successes.You're happy to see each other because each of you are delighted because you know you're getting something from them.It feels like you are two different teams working at the same big company.That is rare.Doesn't usually happen.And that's fine.Most vendor relationships are ones where you shake hands, you exchange money and services, and that's fine.But I think in an era of AI, these are durable skills.These are durable skills for very senior engineers who care about impact.Senior engineers and also engineering leaders and anyone who wants to become an engineering leader.Because I guess, like, I mean, both of us have been in engineering leadership, like you've been in much higher positions than I have.But I think it's fair to say that the way for you to get to that CTO role, that head of engineering, that director of engineering, is to do the work for six or eight or six months, a year to year and a half.And to do so, you need to know these things.I feel, Observer of the Engineering, I'd be underselling this book, I'll be honest, the title.

（Charity）但最好的供应商关系是那种：你真心觉得他们的成功就是你的成功，你的成功也是他们的成功。你们见面很开心，因为彼此都很高兴，因为你知道你能从对方那里得到东西。那种感觉就像你们是同一家大公司里的两个不同团队。这很罕见，通常不会发生，这也没关系。大多数供应商关系就是握个手、钱货两清，这也挺好。但我觉得在 AI 时代，这些是持久的能力，是那些在意影响力的资深工程师的持久能力。／（Gergely）资深工程师，还有工程管理者，以及任何想成为工程管理者的人。因为我们俩都做过工程管理——你做到的位置比我高得多——但我觉得可以这么说：你要走到 CTO、工程负责人、工程总监那个位置，得先把这些活干上六个月、八个月、一年到一年半。而要干这些活，你就得懂这些东西。老实说，我觉得《可观测性工程》这个书名把这本书说小了。

[1:06:46] Gergely Orosz

But I'm also going to get it.And I'll probably think of ways to share a bit more.But thank you for writing.And thank you to all your co-authors.But speaking of leadership, I'd love to talk about a little bit of engineering leadership because there's a lot of things that are changing.But I loved one of your very recent takes on leadership, and I'm going to quote you.The most effective leaders are kind, caring humans, and skilled business operators.The second most effective leaders are terrible humans and skilled business operators.And after that comes everyone else.There are plenty of good kind humans who are sloppy operators and bad at business because being good at business is very hard.And you said this in relation to what happened at Twitter slash X, referring to Elon as a terrible human, but a skilled business operator.Yeah, well, I don't know that I would call him the skilled business operator.But my point was that Twitter had 16 years to figure it out.And everyone could see that they were not figuring it out.And whatever else he is.Figuring out the business, specifically.Figuring out the business.Yeah.Building products.You know, reaching folks.And you could argue that X has gotten better or worse, but you can't argue that he is running it with 20% as many people.

（Gergely）不过我也要去买。我大概还会想办法多分享一些。总之谢谢你写了它，也谢谢你所有的合著者。说到领导力，我想稍微聊聊工程领导力，因为有很多东西在变。我特别喜欢你最近关于领导力的一个观点，我引一下你：最有效的领导者是善良、关心人的人，同时是熟练的生意操盘手。第二有效的领导者是糟糕的人，但也是熟练的生意操盘手。再往后才是其他所有人。有很多善良的好人，但他们是马虎的操盘手、不擅长做生意——因为把生意做好非常难。你说这话是针对 Twitter/X 发生的事，把马斯克称作一个糟糕的人但熟练的生意操盘手。／（Charity）嗯，我其实不确定我会不会称他为熟练的生意操盘手。但我的意思是：Twitter 有 16 年时间去把这件事想明白，所有人都看得见他们没想明白。而不管他别的方面怎么样——／（Gergely）具体说是把生意想明白。／（Charity）把生意想明白，对。做产品，触达用户。你可以争论 X 变好了还是变坏了，但你没法争论的是，他是用原来 20% 的人在运营它。

[1:08:06] Gergely Orosz

Yep.And it's working.And it's working.And some of that, you know, 30 engineers on core, on the core product.And another 30 and like 60 engineers, there were 1,700 before.You know, and you could argue, and I think it would be true that it's some of the work that those engineers did that allow.But like, this is the point.If we don't do it ourselves, meaning hold ourselves to a high standard, build with efficiency, constantly be like trying to get better.We don't do it ourselves.Someone will come and do it to us.And this is what you also said, you closed, saying if we want to remain in leadership, if we want to set the culture and the tone and take the ethical sense that we believe in, we first have to win at the business.And I think this is like, especially now that there's so many changes happening and technology changes, there's been whirlwinds, business will go up and down.I guess the reminder that like you want to keep your eyes on the prize, which is, especially if you're a leader.The 2010s, there was so much money sloshing around in Silicon Valley and time started to get tough and all of these companies canceled their DEI programs and blah, blah, blah.Yeah, they never believed in that.

（Gergely）对。／（Charity）而且它转起来了。／（Gergely）它转起来了。而且其中一部分是——核心产品上 30 个工程师，另外 30 个，一共大概 60 个工程师，而之前是 1700 个。你可以说——而且我认为这是真的——正是之前那些工程师做的一些工作才让这成为可能。／（Charity）但这正是重点：如果我们不自己动手，也就是不给自己定高标准、不高效地构建、不持续地想变得更好，如果我们自己不做，就会有人来替我们做。／（Gergely）你在文章结尾也说了：如果我们想继续留在领导位置上，如果我们想设定文化和调性、坚持我们相信的伦理，我们首先必须在生意上赢。我觉得这一点，尤其是现在变化这么多、技术在变、到处是旋风、生意会起起落落，这是个提醒：你得盯住那个真正的靶心——尤其如果你是领导者。／（Charity）2010 年代，硅谷里到处都是钱在晃荡。等日子开始难过，所有这些公司就把 DEI 项目全砍了，等等等等。／（Gergely）对，他们从来就没真信过。

[1:09:11] Charity Majors

They were just trying to buy people off.You know, and that is very telling to me.And I have taken a lot of lessons away from that, which is just that it's not enough to be a good person.I believe that people who are kind and care about people can and usually do do better than sociopaths in the same roles, but only if they're good at business.Learn the business, stay close to it.You got to.With AI, now that coding has become cheap, now that engineers are running agents, how do you see the role of good, skilled engineering managers and engineering directors change?

（Charity）他们只是想花钱把人打发了。这一点对我来说很说明问题，我从中吸取了很多教训：光做个好人是不够的。我相信，善良、在乎人的人在同样的岗位上，能够、而且通常确实比反社会者做得更好——但前提是他们得懂生意。学生意，离生意近一点。你必须这样。／（Gergely）有了 AI，写代码变便宜了，工程师在跑 agent 了。你怎么看优秀、熟练的工程经理和工程总监这个角色的变化？

[1:09:50] Charity Majors

What has changed?Well, the first thing that's changed is I think everyone has to, gets to be hands-on.Specifically to generate some code, to ship to production to some extent.You should know what it feels like to submit a diff, to get a PR through.You know, you should know what it feels like.It's just easier now than it's ever been to pick it back up, to fill in the blanks, you know.And it's always been the case that leaders were better if they had a hand in it.And now it's just, it's just, there's no excuse not to, teams are getting smaller.In general, I think this should be a good thing.If we can figure out how to own more surface area, it should be a good thing.I worry that the way it's happening is, it's being done by CEOs who are like, oh, well, this other company is doing it or it's magic or we're going to do layoffs or like it.And I really dislike the anti-management tone.So like, no argument that power tends to drift towards managers over time and needs to get pushed back into years.No argument there's a tendency to have too many managers, you know.The bureaucracy kind of like generates a sort of, you know, it's easier to say yes than it is to say no.And so these things happen, so they need to be pushed back from time to time.

（Gergely）什么变了？／（Charity）第一件变了的事是，我认为每个人都必须、也都有机会亲自动手了。具体说就是去生成一些代码，某种程度上要把东西发到生产环境。你应该知道提交一个 diff 是什么感觉，知道把一个 PR 推过去是什么感觉。现在重新捡起来比任何时候都容易，把空白补上比任何时候都容易。而且一直以来，领导者只要还亲手参与，就会做得更好。现在就是——就是没有借口不这么做了。团队在变小。总体上我觉得这应该是件好事。如果我们能想明白怎么让每个人扛更大的面积，那这应该是好事。我担心的是它正在发生的方式：是由那些 CEO 推动的，他们说「哦，别的公司在这么干」「这是魔法」「我们要裁员」之类的。而且我非常不喜欢那种反管理的调子。当然，我不否认权力会随时间往管理者那边漂移、需要被推回给一线；我也不否认存在管理者过多的倾向。官僚体系会自己长出来，说「是」总比说「不」容易，所以这些事会发生，所以时不时需要把它推回去。

[1:11:11] Charity Majors

But I believe that management and middle management is deeply essential.And I look forward to seeing how that works out for them, not having any bit.But like the role of a manager, middle management, in my view is sense-making and context-giving.Because like, I don't believe in a world where engineers are just given tasks.Here's your DRI.Go do the things.AI can do that.I want people who understand what we're trying to do, understand how we're trying to do it,or who are there to help us figure out how we're going to do it.And you can't engage emotionally, creatively, collaboratively without understanding.And that understanding is incredibly difficult to build, and it's fragile and it never lasts very long.For those of us listening who are middle managers, it's been a tough few years.Because what they're seeing is there's a push to have fewer of them.A lot of their colleagues, if they're in unlucky places, they were made redundant.And many of them have struggled to get similar positions.We're talking director positions.We're talking head of engineering, senior engineering manager.That role is disappearing faster than ever.I think directors might still be there.For folks who are in this position, and they do like middle management, they do believe they're good at it.

（Charity）但我相信管理、尤其是中层管理，是极其必要的。我很期待看到这件事最后会怎么收场。在我看来，管理者、中层管理者的角色是「意义建构（sense-making）」和「给上下文」。因为我不相信那种世界：工程师只是被丢过来一堆任务——这是你的 DRI，去干吧。那种事 AI 就能做。我想要的是那些理解我们在试图做什么、理解我们打算怎么做、或者能帮我们一起搞清楚该怎么做的人。而如果不理解，你就没法在情感上、创造性上、协作上真正投入。而那种理解极难建立，它很脆弱，而且从来维持不了多久。／（Gergely）对我们这些正在听的中层管理者来说，这几年很难熬。因为他们看到的是：有一股力量要减少他们的数量。如果运气不好，他们很多同事被裁掉了，而且很多人很难再找到类似的职位——我们说的是总监、工程负责人、高级工程经理。这个角色消失得比以往任何时候都快。我觉得总监这一层可能还在。对那些身处这个位置、并且真心喜欢中层管理、也认为自己擅长的人来说……

[1:12:32] Gergely Orosz

What do you think tactics could be to give them a bit more career options?Tactically, I would say go back to BNIC for a while, even if you know it's not what you want to do.If you're at all capable, if you're not capable of it, then I would try to work.You've got to get AI on your resume.You just have to.And this is a huge career risk.If you're working somewhere where you're not getting these skills, that is a massive risk.I would do whatever I could.And this is very interesting that you're saying get AI in your career.Because I remember about a year, year and a half ago, I started to pay attention to like, okay, this is happening.And I remember a year ago, I wrote an article about how to become an AI engineer.And I talked with engineers who just like at their workplace started to do AI, and now they're AI engineers.Next thing I'm hearing right now is people who have like two to three years of AI engineering experience are so in demand.I'm doing research on a job market, and they're like, this is the best job market ever.However, you know, the people who are like, okay, I have none, but I want to get it.And let's say they're out of a job, they're struggling because no one's giving them the benefit of a doubt.

（Gergely）你觉得有什么战术能给他们多一点职业选项？／（Charity）战术上我会说：先回去做一段时间 IC，哪怕你知道那不是你想干的。如果你还有能力做的话；如果你完全做不了，那我会想办法……你必须把 AI 写进你的简历，你必须。这是一个巨大的职业风险：如果你所在的地方让你学不到这些技能，那是巨大的风险。我会不惜一切去争取。／（Gergely）你说「把 AI 弄进你的职业履历」，这非常有意思。因为我记得大概一年、一年半以前，我开始注意到：好，这件事真的在发生。一年前我写过一篇《如何成为 AI 工程师》，我采访了一些工程师，他们就是在自己公司里开始做 AI，现在就是 AI 工程师了。而我现在听到的下一步是：那些有两三年 AI 工程经验的人，抢手得不得了。我在做就业市场研究，他们说这是史上最好的就业市场。然而，那些说「我一点经验都没有，但我想要」的人，尤其如果他们失业了，就很难——因为没人愿意给他们一个疑罪从无的机会。

[1:13:38] Charity Majors

It is really hard, and I'm not saying it's right, but it's how it is.And I guess the reason we're ringing this alarm bell is we know this change has not been asked fast.So do it now because later.Do it now.The next time you go out for a job interview, anyone, you're going to be asked.And you're going to be filtered out if you don't have it.And the delta between those who are just getting started and those who have been doing it, it was here for a little while.It was very easy to get started.Now it's here.But it's opening.The longer it goes, the harder it will be to catch up.You just got to get some.Let's talk about directors.Yeah.Directors are usually the ones who they have been in management for like 10 years, usually.And there's a real feeling of fear often of like, God, tech has changed a lot in 10 years.And this is where I would say your body, like the way we experience anxiety and the way we experience excitement is physiologically almost the same.Like I used to play piano, right?

（Charity）这真的很难，我不是说这样是对的，但现实就是这样。／（Gergely）我猜我们之所以敲这个警钟，是因为我们知道这个变化快得离谱。所以现在就动手，因为以后……／（Charity）现在就动手。下一次你出去面试，任何人都会被问到这个。如果你没有，你就会被筛掉。而「刚起步的人」和「已经干了一阵的人」之间的差距——有那么一段时间，入门是非常容易的；现在门还开着，但时间越久，追上去就越难。你就是得先弄到一点。／（Gergely）我们聊聊总监吧。／（Charity）好。／（Gergely）总监通常是那种已经做了十年管理的人。他们常常有一种真实的恐惧：天啊，技术在这十年里变了太多了。／（Charity）这时候我会说，你的身体——我们体验焦虑的方式和我们体验兴奋的方式，在生理上几乎是一样的。比如我以前弹钢琴，对吧？

[1:14:41] Charity Majors

And before a performance, I'd be like, I'm excited.I'm so excited to do this, you know, because I'm like trembling and sweat.But like the difference is agency.If you sit back and wait for the water to come to you, you're just going to be freaking out.But if you run towards the waves, if you're like, just like run towards, try it.You know, if you have a job now and you're a director and you're afraid of it, it's always seen as kind of noble.When managers want to go back to being ICs, I think it's very well respected.Own it.Run towards the waves.Own it.Be part of the wave, the frontier of people who are like, I'm so excited.Just tell yourself.It doesn't have to be true.I'm so excited to be an IC again.It's never been easier to go back and try.I'm going to do it.And I'm going to talk about my experience and tell everyone else about it.Just you got to own it.Don't wait.And then let's talk about junior engineers.Obviously, it's a hard time to get started as a junior.But how do you think about the value that they bring?

（Charity）演出之前我会跟自己说：我很兴奋，我太兴奋了——因为我在发抖、在出汗。但两者的区别在于「能动性（agency）」。如果你往后一靠、等着水漫上来，你就只会崩溃。但如果你朝着浪跑过去，如果你就是往前冲、去试，（就不一样了）。如果你现在有份工作，你是总监，你对此感到害怕——管理者想回去做 IC，这一直被看作是一件挺高尚的事，我觉得是很受尊重的。认下它，朝着浪跑过去，认下它。做那波浪的一部分，做那批说「我太兴奋了」的前沿的人。就跟自己这么说，不必是真的：我太兴奋能重新做 IC 了。现在回去试一试比任何时候都容易。我要去做，而且我要讲我的经历、告诉所有人。你就是得认下它，别等。／（Gergely）那我们再聊聊初级工程师。显然，现在作为初级入行是很难的时候。但你怎么看他们带来的价值？

[1:15:43] Charity Majors

The hardest thing about quantifying the value of junior engineers is that we don't know how to quantify the value of any engineer.So it's all vibes.You know, it's so interesting because I feel like we're over here doing all this hand-wringing about, will juniors be okay?

（Charity）量化初级工程师价值最难的地方在于，我们本来就不知道怎么量化任何工程师的价值。所以全是凭感觉。这很有意思，因为我感觉我们在这边捶胸顿足地问：初级们会不会没事？

[1:15:56] Charity Majors

Will they ever learn the basics?But, like, my friend Boris, who has a new observability startup, and he talks to these high school, college kids all the time.He's like, they are cooking.They are.They don't know what the software development lifecycle is.But they are just, like, off to their, they are doing so much cool shit.I believe that the kids are going to be okay.We just have to hire them.We just have to give them a shot.They're going to come up with a lot of the conclusions and the ways and the hows that are going to be things that we wouldn't have thought of.But we just have to hire them.We just have to be willing to give them a shot.This week, NSF, I've talked with a bunch of founders, young startups, and they've been telling me the stories of this open source contributor who was outstanding.So they wanted to hire him or her.Turns out it was a 17-year-old kid.They still hire it.And now they tell me, like, oh, my gosh, the things they do.So I think when you're saying the kids' kids are going to be fine, just give them a shot, even if it's an internship.Yes, totally.I feel more company should, because internship is low risk, low duration.Yeah.And even if that person doesn't work out with an internship under their belt, so much better for everyone.

（Charity）他们还学不学得会基本功？可是我朋友 Boris——他在做一家新的可观测性创业公司——他天天跟那些高中生、大学生聊。他说：这帮孩子简直在起飞。他们真的在起飞。他们不知道软件开发生命周期是什么，但他们正在做超多酷东西。我相信这帮孩子会没事的。我们只需要雇他们，只需要给他们一个机会。他们会得出很多我们根本想不到的结论、方法和做法。但我们必须雇他们，必须愿意给他们一个机会。／（Gergely）这周（此处 ASR 含糊）我跟一批创始人、一些年轻创业公司聊过，他们跟我讲了这样的故事：有个开源贡献者特别出色，他们想把这个人招进来，结果发现是个 17 岁的孩子。他们还是招了。现在他们跟我说：我的天，这孩子做的事太厉害了。所以你说「孩子们会没事的，只要给他们一个机会」，哪怕是一个实习机会。／（Charity）对，完全同意。／（Gergely）我觉得更多公司应该这么做，因为实习是低风险、短周期的。／（Charity）对。而且哪怕那个人最后没成，有过一段实习经历，对所有人都好太多了。

[1:17:05] Gergely Orosz

Totally, totally.One question that came up when I asked that you're going to be in the show what I should ask, they said AI fatigue.Like, someone asked, like, can you please ask charity as an engineer if I'm starting to get just really, really drained of this?

（Charity）完全同意，完全同意。／（Gergely）我问「我该问你什么」的时候，有个问题冒出来：AI 疲劳。有人问：能不能替我问问 Charity——作为一个工程师，我开始觉得被这一切彻底榨干了，怎么办？

[1:17:19] Gergely Orosz

Have you had this?Do you see people having it?And what is a good way to, you know, just deal with it?We know what's here.We know what's here to say, but still.I mean, my follow-up question would be, like, which variety of AI fatigue?

（Gergely）你有过这种感觉吗？你看到别人有吗？有什么好办法应对？我们知道这东西赖着不走了，但还是（累）。／（Charity）我的追问会是：是哪一种 AI 疲劳？

[1:17:31] Charity Majors

Okay, tell us a lot of varieties.You know, because for some people, when they say AI fatigue, they're talking about receiving slop.Some people are talking about all the hype and the, oh, have you heard the phrase or the term doom trolling?

（Gergely）好，那给我们讲讲有很多种。／（Charity）因为对有些人来说，他们说 AI 疲劳，指的是天天收到 AI 垃圾（slop）。另一些人说的是那些炒作。还有——你听过「末日钓鱼（doom trolling）」这个说法吗？

[1:17:50] Charity Majors

No.Cal Newport is, I think, his name.He's a computer scientist.He's an AI researcher professor on the East Coast.And it's his term for what the CEO of Anthropic and OpenAI keep doing about, oh, my God, this might be the end of blah, blah, blah.And he's like, it's just doom trolling, and they need to stop it because they're stressing everyone the fuck out.And stop because it's just not responsible.You know, so, like, yeah, I think there's a lot of fatigue around that.I think that a lot of people, their family members are afraid.You know, it's just, it's always before the history of technology.It's been something cool or fun or this will make, the iPhone, it'll make your life better.And now it's just, like, fear.It's pretty crappy.So there's that.There's the fatigue of, like, I found myself being off social media because I'm just so tired of all of the AI slop posts.It's just, like, I'm not interested.There are a lot of different varieties here.And, yes, we are all feeling it.So I guess I would repeat my call for us to remember that we are in control.We are in charge.I think the universal nature of the frustration means that this is a great time to propose experiments where we take back control.

（Gergely）没有。／（Charity）Cal Newport，我想他是叫这个名字，他是个计算机科学家，是东海岸一位研究 AI 的教授。这是他造的词，用来形容 Anthropic 和 OpenAI 的 CEO 一直在干的事：哦天哪，这可能是某某某的终结。他说，这就是末日钓鱼，他们该停下来，因为他们把所有人都吓得半死；停下来，因为这就是不负责任。所以我觉得围绕这个有很多疲劳。我还觉得，很多人的家人在害怕。技术史上一直不是这样的——一直以来它是某种很酷、很好玩、或者能让你生活更好的东西，比如 iPhone。而现在只剩下恐惧，这挺糟糕的。这是一种。还有一种疲劳是，我发现自己已经不上社交媒体了，因为我实在受够了所有那些 AI 垃圾帖，我就是没兴趣。这里面有很多不同的种类，而且是的，我们都在感受它。所以我想我会重申我的呼吁：记住我们才是掌控者，我们说了算。我觉得这种挫败感的普遍性，恰恰说明现在是提出实验、把控制权拿回来的好时机。

[1:19:06] Charity Majors

Maybe you and your team agree we don't actually want any more AI-generated PR descriptions.We don't, you know, none of us use AI on Wednesdays.Maybe we take a week, you know, just, like, take control back.Try something.Propose something.I guess because change is so big, experimenting has never been easier.And I guess most businesses, most directors, most leaders would welcome teams saying, you know, we're going to try out because their answer will probably be, I mean, you're in this position.Your answer, I guess, will be sure.Better yet, don't even tell me.Come and tell me what worked afterwards.And what didn't.And what you learned.And what didn't.And then other teams can learn from that, right?

（Charity）也许你和你的团队达成一致：我们其实不想再要 AI 生成的 PR 描述了。或者：我们周三都不用 AI。也许我们拿出一周时间，就是把控制权拿回来一点，试点什么，提议点什么。／（Gergely）我猜正因为变化这么大，做实验反而从来没这么容易过。而且我猜大多数企业、大多数总监、大多数领导者都会欢迎团队说「我们打算试试」，因为他们的回答多半会是——你就在这个位置上，你的回答我猜会是「当然可以」。／（Charity）更好的是：别提前告诉我，事后来告诉我什么管用。／（Gergely）以及什么不管用。／（Charity）以及你学到了什么。／（Gergely）以及什么不管用。／（Charity）然后别的团队就能从中学习，对吧？

[1:19:45] Gergely Orosz

I think sometimes people are waiting for top-down permission, but, like, we don't know what permission to give until it works so much better when it's bottoms up, when people are just trying to take control of your time and your calendar.I guess maybe we just forgot that there have been major changes in the industry.I remember the iPhone change.And I remember the people when the iPhone came out, iPhone and Android, the smartphones, the people who were the most kick-ass iOS engineers, you know who they were?

（Charity）我觉得有时候人们在等自上而下的许可，但问题是，在它跑通之前我们根本不知道该给什么许可。自下而上、由人们主动去夺回自己的时间和日历，效果好得多。／（Gergely）我猜我们可能只是忘了，这个行业以前也发生过重大变化。我记得 iPhone 那次变化。我记得 iPhone 和 Android 智能手机出来的时候，那些最猛的 iOS 工程师，你知道他们是谁吗？

[1:20:14] Gergely Orosz

There were typically, like, 18 or 19-year-old kids who went into this and they tried it out.And guess what?Two years later, they were the main experts.The staff engineer was a 22-year-old.And then the entry-level engineer was a 40-year-old.And again, not always.But my point is, when there's such big change, you can actually become an expert by...Very little time.By you taking...Just taking charge.Taking charge.And also, no one's really going to tell you no because no one knows what's working.Exactly.There's some liberty there.So, as closing, just to go back to a little bit of being human and slowing down, what are one or two books that gave you something?

（Gergely）通常是 18 岁、19 岁的孩子，他们一头扎进去、动手试。然后你猜怎么着？两年后，他们就是主要的专家了。Staff 工程师是个 22 岁的人，而入门级工程师是个 40 岁的人。当然不总是这样。但我的意思是，当变化这么大的时候，你真的可以在很短的时间里成为专家——／（Charity）非常短的时间。／（Gergely）靠你自己……／（Charity）就是主动扛起来。／（Gergely）主动扛起来。而且也不会真有人对你说不，因为没人知道什么才管用。／（Charity）正是。／（Gergely）这里面有一种自由。那么作为收尾，回到「做人」和「慢下来」这个话题——有没有一两本书给了你一些东西？

[1:20:52] Charity Majors

Ooh.I really got a lot out of catastrophe ethics.I haven't seen it mentioned in many places.And I think it might be...I think real philosophy nerds would be like, eh, that's kind of a pop book, you know?

哦。我从《灾难伦理学》（Catastrophe Ethics）里收获很大。我没在很多地方看到它被提起。我觉得真正的哲学发烧友大概会说：唉，这算是本通俗读物吧。

[1:21:07] Charity Majors

And I think the people who are not real philosophy books are like, that's kind of a lot of philosophy.But, you know, he's a bioethicist, I think.Travis Reeder, our E-D-E, our catastrophe ethics.And he talks about how the puzzle of modern life is that it feels like everything we're implicated, every choice we make.Are you going to use milk?

（Charity）而那些平时不读哲学书的人又会觉得：这哲学也太多了吧。作者我记得是个生物伦理学家，Travis Rieder，书名是《灾难伦理学》。他讲的是：现代生活的难题在于，你好像在每一件事上都被牵连进去了，你做的每一个选择都是。你要喝牛奶吗？

[1:21:27] Charity Majors

Well, you know, the cows were tortured.Are you going to use almond milk?Well, water is a problem.Well, you swim.I'm not like little hormones.And it's just like there is no...Whatever you do, you are hurting someone.And it feels like the problems are so large that none of our decisions really matter.And that tension, like what...And then he kind of walks through traditional ethical frameworks like utilitarianism and stuff and just shows how there is no recipe anyone can follow that doesn't lead you to some really stupid...And he's like, this is just no gods, no masters.We are...Which doesn't mean that everything's relative.Doesn't mean...What it means is that the way to live an ethical life of integrity is you need to educate yourself about the world.You know, you need to be...You need to know things, right?

那奶牛是被虐待的。你要喝杏仁奶吗？那水资源是个问题。你去游泳……总之，不管你做什么，你都在伤害某个人。而且这些问题大到让人觉得，我们的任何决定其实都无关紧要。那种张力……然后他会带你走一遍传统的伦理学框架，比如功利主义之类，然后展示：没有任何一个人人可以照着做的配方，能不把你带向某些非常愚蠢的结论。他说，这就是「无神也无主」。这不意味着一切都是相对的，也不意味着（什么都行）。它的意思是：要过一种有正直感的伦理生活，你需要去了解这个世界。你得知道事情，对吧？

[1:22:21] Charity Majors

And then, listen, inside, you know, where are you drawn?What suffering really speaks to you?Or what caused you?You know, because no one can tell you what matters.You have to decide what matters.And so that introspection and...It's so at odds with the sort of performative rage, you know, which I'm just so exhausted.All right, so that's one.Number two, this is a book that I've recommended a couple times, but I'm just going to keep recommending it because it's so good.It's by Adam Becker, and it's called More Everything Forever.And he is a journalist based in San Francisco.He has a philosophy undergrad and a PhD in astrophysics, and he just demolishes all of the AI religion,the singularity, and the effect of altruism, and accelerationism, and the whole, like,what if we could have infinite growth forever-ism?

然后是往内听：你被什么吸引？哪一种苦难真正打动你？或者说你的动因是什么？因为没人能告诉你什么才重要，你必须自己决定什么重要。所以那种内省……它跟那种表演式的愤怒截然相反——那种东西我实在是受够了。好，这是第一本。第二本是我已经推荐过好几次的书，但我还是要一直推荐，因为它太好了。作者是 Adam Becker，书名叫《More Everything Forever》。他是一位在旧金山的记者，本科念哲学，天体物理学博士。他把所有那些「AI 宗教」——奇点论、有效利他主义、加速主义，以及那整套「要是我们能永远无限增长该多好」的主义——全都拆了个稀巴烂。

[1:23:18] Charity Majors

And he's like, the heat death of the universe, you guys.Literally the only thing we know about exponential growth is that it must end.It must end in an S-curve or in a crash.It must end.And he's got this dry sense of humor.And there are a couple times where he's just, like, describing some of the very real things.He's just like, why do Oxford ethicists want this?

他说：各位，宇宙会热寂的。关于指数增长，我们唯一确切知道的一件事就是它必然会结束。它必然以 S 型曲线结束，或者以崩溃结束。它必然结束。而且他有一种很干的幽默感。有好几处他就是在描述一些非常真实的东西，然后他会说：牛津的那些伦理学家到底为什么想要这个？

[1:23:44] Charity Majors

He's talking about, like, taking over star systems.It's just ridiculous.And he also, he gets in a whack.He just, like, talks about all these people who are working so hard on life extension.And he's like, these are a bunch of sad little boys who miss their daddy.And I was just like, oh, my God.It is the oldest fear of humanity.It's a fear of death.And you just see it.You cannot unsee it.So, yeah, those are my two.They're both so good.Well, Charity, thank you so much.This is finally made it happen.Finally.It's a good time.I always really, really enjoy talking with Charity.I hope you also liked it.I appreciated how Charity talks about the trust account.If we are debiting trust from the creation of code because AI wrote it and no human read it,then that trust needs to be refilled somewhere else.Testing evils and guardrails are all ways to add more trust that we lost by using AI.I also appreciated how she talked with empathy about both AI camps.The enthusiasts or AI-pailed folks are seeing the practical wins while those operating productionsystems see the slop.Neither side is wrong, but they should talk to each other more.So if you see wins with AI, share with the broader team, but also talk about it when it

（Charity）他讲的是那些人想去占领恒星系统之类的，简直荒唐。他还顺手来了一记重击：他说了一堆人在拼命做延寿这件事，然后他写道——这就是一群想念爸爸的可怜小男孩。我当时就想：我的天。这是人类最古老的恐惧，对死亡的恐惧。你一旦看见它，就没法再假装看不见了。所以，就这两本，都太好了。／（Gergely）好，Charity，非常感谢你。这事终于成了。／（Charity）终于。／（Gergely）时候正好。

（结语·Gergely）跟 Charity 聊天我总是非常非常享受，希望你也喜欢。我很欣赏 Charity 讲的那个「信任账户」：如果我们因为代码是 AI 写的、而且没有人类读过，就从「代码创作」这一栏支取了信任，那这份信任就必须在别处被补回来。测试、evals 和护栏，都是把我们因为用 AI 而失去的信任重新加回去的办法。我也很欣赏她带着共情去谈两个 AI 阵营：热情派、被 AI 说服的那批人看到的是实实在在的收益，而那些运行生产系统的人看到的是垃圾。哪一边都不算错，但他们应该多跟对方说说话。所以如果你在 AI 上看到了收益，就分享给更大的团队；但同时，当它

[1:24:50] Gergely Orosz

creates more work, reduces reliability, or when it degrades quality.And for those of us feeling anxious about all of this change, especially directors andmanagers, I'll leave you with Charity's advice.Anxiety and excitement are psychologically almost the same, but a difference betweenthem is agency.So instead of waiting for change to come to you, take charge however you can and makechanges yourself.Do check out the show notes below for related to Pragmatic Engineering deep dives on howAI is changing software engineering and for another discussion with Charity on observability.And I can very much recommend her book, Observability Engineering, 2nd Edition.If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.A special thank you if you also leave a rating on the show.Thanks and see you in the next one.

带来更多工作、降低可靠性、或者让质量退化的时候，也要把这些讲出来。而对于我们这些为这一切变化感到焦虑的人——尤其是总监和管理者——我把 Charity 的建议留给你：焦虑和兴奋在心理上几乎是同一件事，而两者的区别在于能动性。所以，与其等着变化找上门来，不如尽你所能主动扛起来、自己去做出改变。记得看下面的 show notes，里面有《务实工程师》关于 AI 如何改变软件工程的相关深度文章，还有我和 Charity 之前那期聊可观测性的对谈。我也非常推荐她的书《可观测性工程》第二版。如果你喜欢这期播客，请在你常用的播客平台和 YouTube 上订阅。如果你还能给节目留个评分，那就特别感谢了。谢谢，下期见。