团队为什么只是装作在审查 AI 代码｜Michaela Greiler 博士

简要描述Brief Description

为什么团队只是假装在审查 AI 代码 | Michaela Greiler 博士Why Teams Only Pretend to Review AI Code | Dr. Michaela Greiler

目录Table of Contents

• Hangar DX 简介与 AI 时代的代码审查
  Intro to Hangar DX and code review in the AI era
• 代码审查因 AI 而发生变化了吗？
  Has code review changed with AI?
• 为什么 AI 正在使团队评审实践走向碎片化
  Why AI is fragmenting team review practices
• 在加快交付速度与保证质量之间取得平衡
  Balancing faster shipping with quality
• 代码审查中的信任与心理安全感
  Trust and psychological safety in code reviews
• 团队文化如何塑造协同一致性
  How team culture shapes alignment
• AI 放大了熟悉的评审挑战
  Familiar review challenges, amplified by AI
• AI 可以发挥作用的地方——以及人类判断至关重要的地方
  Where AI can help—and where human judgment matters
• 代码审查的投降：假装在做审查
  Code review surrender: pretending to review
• 代码审查会消失吗？
  Could code reviews disappear?
• 范围：分阶段的代码监督与相称的升级处理
  Scope: staged code oversight with proportional escalation
• 根据风险和一致性调整审查深度
  Matching review depth to risk and alignment
• 引导智能体，而非接受其输出
  Steering an agent versus accepting its output
• 基于风险的审查，并让工程师保持掌控权
  Risk-based review and keeping engineers in control
• 提升团队评审效果的实用方法
  Practical ways to improve team review
• 为什么领导者应该展现脆弱的一面
  Why leaders should model vulnerability
• 验证、测试与诚实的团队实践
  Verification, testing, and honest team practices

Hangar DX 简介与 AI 时代的代码审查Intro to Hangar DX and code review in the AI era

比如我们有 bug 查找、事故预防、指导与学习、追踪与跟踪、知识共享，对吧？所有这些。我们希望通过代码审查实现这一切。呃，我之前就觉得这简直不可思议，对吧？[铃声] 大家好，欢迎收听 Hangerdx。这是一档关于开发者体验以及工程团队如何解决生产力难题的播客。我是主持人 Ankit，Aviator 的联合创始人。在 Aviator，我们正在构建一个用于验证 AI 生成代码的平台，为其设置防护措施并减少 AI 垃圾内容。所以我今天特别高兴。我的嘉宾是 Michaela 博士，她花了很多时间思考代码审查。我多年来一直在广泛研究代码审查技术，而这并不只是从大语言模型时代才开始的。like we have buckf finding, we have accident prevention, we have mentoring and learning, we have like tracing and tracking, we have knowledge sharing, right? All of that. We want all of that out of code reviews. Uh which I thought like this is crazy even before, right? [bell] Hello folks and uh welcome to hangerdx. This is a podcast about developer experience and how engineering teams solve productivity challenges. I'm your host Ankit, co-founder of Aviator. At Aviator we are building verification platform for AI generated code that creates guardrails and reduce AI slump. So I'm very excited today. My guest is uh Dr. Michaela who has spent a lot of time thinking about code reviews. I've done extensive research in test build code review techniques for several years and this not just during the LLM era.

所以，很多事情都发生了变化，这也是我们接下来要聊的话题。Michaela曾在微软的许多不同团队工作过，我们会围绕这些经历展开很多有趣的讨论。说到这里，Michaela，很高兴你能来。非常感谢你抽出时间。要不我们先简单自我介绍一下？So a lot of things would have changed and this is something we will be talking about. Michaela has booked and Microsoft in many different themes. It'll be like lot of interesting conversations around that. With that, Michaela, I'm very excited to have you here. Thank you so much for your time. Why don't we actually do a quick introduction?

主持人：是的，是的。非常感谢你邀请我。我非常高兴能来参加播客。你经常聊代码审查，所以我觉得我来对地方了，也很适合聊开发者体验。是的，我热爱软件工程，也很喜欢和团队一起努力，让软件工程成为一种更好的体验，对吧？比如，既要有更好的产出，也要关注我们如何看待自己所做的事情、看待自己的手艺。你知道，我很喜欢一句话：我在做开发者体验（DX）研究时用过这个说法——愉快地做好我们最擅长的工作，对吧？这种愉悦感也是我看重的，所以不只是做好我们最擅长的工作，对吧？还要做得愉快。那么，作为人，我们怎样才能从自己所做的事情中获得最大的收获？我认为这确实会带来更好的结果。对此也有研究，对吧？员工满意度，总的来说，员工体验能为企业、客户以及所有人带来更好的成果。所以我真的很努力地关注这一点，而且我也很喜欢这么做，这么多年来一直如此。是的。Host: Yeah. Yeah. Thank you so much for having me. I'm very excited to be on a podcast. You talk a lot about code reviews. So, I think I'm at the right place and developer experience as well. Yeah. So, I love software engineering and really working with teams uh to make software engineering a better experience, right? like having better outputs but also how we feel about what we do our craft right how we you know I really like to I had this phrasing when I did uh research on DX doing our best work joyfully right so this joyful part is also something that I value so it's not only about doing our best work right but also joyfully so how can we actually as humans get the most out of um what we are doing and I think this really leads to better result there's also research on that right that employee satisfaction ction in general employee you know experience leads to better outcomes for the business for the customers for everybody so I really try to focus on that and I love you know doing it and I've been doing it for a long time yeah

AI 是否改变了代码审查？Has code review changed with AI?

嘉宾：太棒了，你写过很多东西，不过呃，也许我们就从当前的情况开始吧，你知道，事情一直在变化。Guest: awesome there's a lot of things that you've written but uh maybe we just start with the current state you know things are changing

主持人：软件工程的发展速度比我们过去20到30年间见过的都快得多。那么，过去一年里，你对代码审查流程的理解，以及你对代码审查价值的看法，有变化吗？Host: at crazy pace in software engineering than whatever we have seen in the last 20 30 years so has your approach for understanding kind of like the code review processes, the value of code review changed in the last year.

所以，一年多以前，我确实有那么一段时间在想：你知道，代码审查还能应付这一切吗？就是说，天哪，我所了解的关于代码审查的一切，是否依然有价值？还是说我得彻底重新思考这一切？我真的试着从头重新构想代码审查。好笑的是，你知道，我现在逐渐得出的结论，和我以前持有的价值观和原则并没有太大出入。当然，确实有些事情在变化，我也认为代码审查必须随之改变。但我和团队一起探讨代码审查，以及代码审查可能成为瓶颈的问题，或者人们在其中遇到的困难和挑战，已经有 15 年了。这并不是什么新问题，并不是说“天哪，以前代码审查是一种多么愉快、多么轻松的实践，现在我们却陷入了困境”。它其实一直是一种非常有价值、但也很难做好的实践，对吧？你会遇到社交层面的挑战、技术层面的挑战，还有组织层面的挑战，而这些在大语言模型出现之前就已经存在了，对吧？So there was definitely a point it's more than a year ago that I was like wondering you know is code review holding up to all of that right like oh my god is everything that I know about code reviews like is it is it still valuable right or do I have to rethink everything completely and I really try to reimagine code reviews from scratch and and you know the funny place the funny thing is that I'm I'm reaching a place where I'm not far off from you know the values and the principles that I had before right there things are changing that definitely and I think code review also has to change but I've been you know working with teams on code reviews and the bottleneck that code reviews can become or the problems and the struggles that people have for 15 years now right like it's it's not a new problem it's not like oh my god code review was were you know it was such a pleasant you know practice or easy practice before and now we are struggling it's more that it's a very valuable practice but it's a hard practice right you have social challenges you technical challenges, you have organizational challenges and all of that existed before large language models, right?

但现在情况确实变得更严峻了，对吧？代码审查面临的压力肯定更大了。数据也能反映出这一点，对吧？比如 PR 更大了，数量也更多了。嗯，所以，那些没有把各方面都安排妥当的团队，肯定比以前遇到了更多问题；而且以前大家在代码审查上就已经有不少问题了，对吧？所以我们得重新思考。有意思的是，我好像又开始回归以前看重的那些东西了，对吧？比如，认真思考我们为什么要做这件事、预期结果是什么——这就是我五年前在研讨会上讲授的原则之一，对吧？But now things are, you know, getting more serious, right? There's definitely more pressure on code reviews. We see it with data, right? Like larger PRs, more PRs. Um, so, you know, teams that don't have their ducks in a row, definitely, you know, have more problems than they had before and people had problems with code reviews even before, right? So, we we have to rethink. Interestingly, I'm I'm sort of leaning back to the things that I valued before, right? Like for example, really thinking about why we are doing this like what is the outcome is something like one of the principles that I taught in workshops 5 years ago, right?

当一个团队遇到困难来找我时，我首先会跟他们澄清的一件事就是：你们做代码审查的目标究竟是什么？会采用哪些方法？因为代码审查并非只有一种形式，对吧？确实有不同的方法。你可以当面审查，可以开会，也可以进行异步代码审查，对吧？这取决于你们具体在看代码库的哪一部分，等等，对吧？所以它不是只有一种形式，以前也从来不是。我觉得现在我确实重新回头做的一件事是——就像我重新回到起点重新思考时，我也重新开始做研究，对吧？所以我采访了很多开发者，也和团队合作，认真研究…… sulisutwhen a team was coming and struggling one of the first thing that I clarified with them is you know what is your goal actually to do code reviews and what techniques because code reviews it's not one thing right there are definitely different techniques that you can have you can you know review in person you can have like a meeting you can have asynchronous code reviews right it depends on you know what kind of part of the codebase you're really looking at and so on right so it's not one thing and it has never been and I think now one of the things that I definitely went back is Like when I went back to the drawing board, I also went back to research, right? So I'm interviewing a lot of developers. are working with teams really studying you know the

为什么 AI 正在使团队评审实践日益碎片化Why AI is fragmenting team review practices

他们面临的问题，以及他们采用的技术，都需要他们做出有根据、同时也基于经验的判断：这个方向该怎么走？大家真正遇到问题的地方在哪里？我确实看到，大家的代码审查实践变得更加零散了。对吧？不知道你是否也有同样的感觉，但随着 AI 的普及，大家并没有站在同一起跑线上——委婉地说是这样。即使在同一个团队、同一个组织或公司里，人们采用 AI 的方式也大不相同，不仅体现在成熟度或使用程度上，还体现在他们采用的技术和做法上。有人坚持一次性完成的方法：他们觉得就该这么做——我先进入规划模式，然后一次性生成，最后提交这个结果。另一些人则更偏向迭代：反复调整，改这里、改那里。现在，无论是编程还是代码生成，都有非常不同的做法；代码审查也是如此。problems that they are facing the the techniques that they are having to make an informed also empirical decision on you know where should this go where are people like really having problems and I definitely see people have a even more fragmented review practice right I don't know if you you're seeing the same but now with the adoption not everybody is on the same page right to put it you know lightly so even within the same team within the same organization company you AI adoption is very differently not from maturity or how much but also like the techniques that people you know that they do right one guy is after one shot approach right this is how they think that this should go right like I'm planning in planning mode and then I have a one shot and only you know this is what I'm submitting another person is more the iterative guy right like going over and iterative and changing here and there so there are very different approaches to programming now or to co-gener generation and the same for code reviews.

嗯，而且诊所运营会变得更加分散。我觉得面对这一切，我们确实需要制定一个整体策略，对吧？比如，让大家重新达成共识，明确我们已经整合了各项诊所业务。Um, and the practice gets even more fragmented and I think with all of that we really have to put a strategy around all of that, right? Like that we are getting back on the on the same page that we have consolidated practices.

嘉宾：是的。Guest: Yeah.

主持人：是的，当然。我觉得这里还有很多事情正在发生，呃，你知道，我想你也提到了评论中的情感层面。呃，考虑到你会举办工作坊……Host: Yeah. Absolutely. And I think there's also a lot happening in this uh you know there's I think you also mentioned the emotional part of the reviews. Uh given that you run workshops

嘉宾：你觉得今天最大的挑战在哪里？我是说，显然，现在有这么一场，呃，你知道的，在某些……的冲突。Guest: where do you see the biggest challenge today? Like I mean obviously there is this whole uh you know conflict in some

在加快交付速度与保证质量之间取得平衡Balancing faster shipping with quality

不同工程师的思维方式之间存在差异：有些人非常重视保护措施，确保我们妥善开展审查；而很多工程师则会想：“我们怎样才能更快地交付？”甚至领导层也在问：“我们怎样才能更快地交付？”那么，你觉得这种摩擦通常会如何显现？尤其是你举办研讨会或与这些公司的人员交流时，你会如何应对这类对话？ways between different uh mindsets of engineers where there are some people who really want to protect and make sure we do reviews properly and there are many engineers who are like okay how do we ship faster even leadership is like how do we ship faster? So um where do you see sort of like you know this friction sort of like turning out like especially when you do workshops or talk to pe uh like these companies how how are you navigating those conversations?

主持人：是啊，问得好。也许其中一点——这更多是些轶闻。我有一些相关数据，不过你知道，我今天才想到，最好也能有更多真正量化的数据。挺有意思的是，当我观察人们对 AI 的使用，以及他们如何用 AI 做事时，对吧，往往那些不喜欢 AI、真的很讨厌它的人，却投入最多、用得最频繁，对吧？大概是那种“天哪，我得想办法在半年后还保住工作”的心态。所以我觉得，我们正处在一个非常奇怪的时代，对吧？Host: Yeah, good question. Maybe one of the and this is more anecdotal. I have some data on it but you know I actually just thought today it would be a good to have more really quantitative data on that as well. The funny thing is that when I'm looking at people and their AI consumption and how they're doing stuff, right, it's it's often the people that don't enjoy AI, right? They really hate it. They despite it that are heavily invested, heavily using it, right? Like sort of a oh my god, I have to, you know, still have a job in in half a year. So it's it's a very strange era in which we are, I would say, right?

所以我看到，有些人其实更喜欢 AI，可能用得也比较适度；还有些人用得非常多，但实际上却很讨厌它，对吧？而且我觉得，这又回到了团队文化上。我还看到，如果团队文化……如果团队在工程实践方面有很好的价值观，他们总能一起找到办法，讨论我们该如何应对 AI，如何推进这件事，如何看待代码审查，或者如何思考这些问题。不过，外部的压力肯定也存在。我有几位工程师跟我说：“嗯，你知道……”So I see people that actually enjoy AI more that maybe use it more moderately and some people that really heavily use it but actually despite it a lot right and when I and and I think it's it's coming back to team culture right so um what I'm also seeing is that if the team culture if the team you know has very good values on you know engineering practices they somehow find their ways right together about you know what what are we doing about AI love how are we going about this how do we value um you know code reviews or thinking about that but there's definitely pressure also from outside right I have a couple of engineers that tell me well you know

代码审查中的信任与心理安全感Trust and psychological safety in code reviews

别问我代码审查的事，因为这是一个商业决策。我觉得这个观点特别有意思，对吧？它大概是这么说的：作为一名工程师，我想审查代码，我想做这做那，对吧？但归根结底，这是一个商业决策。如果你不想把钱花在我做代码审查所需的时间上，那你就得接受相应的取舍，对吧？比如质量下降、理解程度降低。这是个很有意思的话题。不过，如果你们制定了一些大家都认同的规则，那么每个人都会觉得安心一些。我认为，信任和心理安全感是这个话题中非常重要的部分，对吧？如果团队成员彼此信任，我就可以说：“我不明白这个。”这非常重要。这样你们就能进行尝试，也能把大型语言模型的能力推到极限，对吧？如果你在这样的团队里，就可以举手说：“我们试过这个了，我不明白，这对我来说太难了。我们往回退一步吧。”我觉得这非常非常重要。我可能会从这里开始：认真了解大家在什么情况下敢于表达自己的想法，在什么情况下不敢，然后大家一起讨论。don't ask me about code reviews because it's a business decision which I found a very interesting take right so it says like well as an engineer I would like to review the code right I would like to do this and that but in the end it's a business decision if you don't want to spend money on you know time on me doing code reviews then you have to you know live with with the tradeoffs that you have right with quality that's going down with understanding that's going down right it's an interesting conversation but um when you put things in place right where people agree on then everybody feels a little bit more secure I think trust and psychological security are very important parts of this conversation right and if people trust each other in a in a team you know that I can say well I don't understand this I mean this is super important and then you can experiment then you can also push um large language models to the limit right if you're in a team like that where you can you know raise your hand and say you know we tried this I don't understand like this is too much for me let's go you know step you know step go one step back I think this is very very important and um I would probably start with that right like really trying to find out um where are people daring to speak their mind um and where they are not and and then having the conversation together.

很多时候，团队的价值观是相同的，对吧？就是，嗯，我们想要的是同一件事，只是出发点不同，对吧？也许有人非常积极地推动 AI，而且，你知道，甚至会推着大家去用他们自己都不理解的代码，因为他们觉得自己不得不这么做，嗯，也没有足够的安全感去真正说：“不，等一下，这可能不是正确的做法。”是的。Very often teams have the same values, right? It's um we want the same thing but we are coming from different directions, right? Maybe somebody pushes AI really hard and know pushes even code that they don't understand because they feel forced to do it um and not secure enough to actually say well no hold on this is maybe not the right way to go. Yeah.

嘉宾：有意思。那么他们是如何找到共同点的？我觉得，在某些方面，就像 AI 在很多时候编写了大部分代码一样，也会出现这样的情况：正如你所说，即便是发布代码的作者，或者说提交拉取请求的人，也可能没有亲自读过代码，对吧？他们也可能并不理解代码。所以这涉及两个方面：一方面是信任，就像你提到的，我们该如何在团队中建立信任；另一方面则是责任，也就是……Guest: Interesting. So how do they find common ground? Like in some ways I feel like also with AI writing most of the code many times there's also behaviors where as you're saying you know even the author who published the code or like kind of like send a pull request may not have read the code themselves right or may not understand the code themselves so there is two parts right one is um the trust aspect which is also something you're talking about like how do we build trust as a team I think the other aspect is also the responsibility which is like

主持人：这段代码的责任归谁？你有没有看到一些地方能够推动这些讨论，让团队在同样的原则上达成一致？还是说这仍然是一个持续进行的讨论，而且各处都不太一致？Host: who owns the responsibility of this code like are you seeing sort of like places where you are able to navigate those conversations so kind of like you know teams get aligned uh on the same sort of you know principles or this is still sort of like an ongoing conversation and it's all over the place

嘉宾：嗯，这大概是最古老的故事了，对吧？这跟大语言模型或人工智能其实完全没什么关系，对吧？早在人工智能出现之前，我去一家公司举办研讨会，或者为人们提供咨询服务时，基本上一开始就能看出这会有多容易或多困难，这主要取决于公司的文化、公司的组织架构，甚至是谁聘请了我、谁希望我在那里，对吧？我最好的体验是——而且幸运的是，这种情况也经常发生——人们就是这样找到我的：工程师会主动联系我，希望我能成为他们团队的一员，帮助……Guest: well this is probably the oldest story of all right like this has really nothing to do with large language models or AI right so even before AI when I was going into you know a company giving a workshop or working consulting with people. I could probably tell you know very much from the beginning how easy or how hard this will be just based on culture you know culture in the company about structures even who hired me who wants me to be there right I live the best experiences and and luckily also very often this is how people find me also because I position myself like this is that engineers really reach out and want me to be you know part of their you know part of their team and help the

团队文化如何塑造协同一致性How team culture shapes alignment

让团队相互理解、凝聚共识并分享。而一旦做到这一点，你知道，就真的能推动很多事情。大家可以聚到一起，你知道，让他们聊起来，也许还能看到彼此的立场。我不是说事情总是一帆风顺，对吧？但你知道，肯定是有共同点的，而且大家开始意识到，这往往不是谁对谁错的问题，只是看问题的角度不同。你知道，我是怎么处理这件事的。很少会有人说：“嗯，我其实就是想让这家公司垮掉，或者你知道，我就是想让这个代码库里全是技术数据。”我的意思是，通常情况并不是这样，对吧？更多时候，嗯，可能是我时间太紧，没法真正读代码；或者我被那些发到我这里来的 AI 垃圾内容搞得太烦了，于是我就说：“好吧，我也不看了。”team understand and consolidate and share. And when that happens, you know, you can really move a lot. You can people come together, you you know, you get them talking, maybe see each other's sides. Not saying that everything goes very smooth all the time, right? But, you know, there's definitely common ground and people start to see, you know, that it's it's often not a right or wrong thing. It's just different perspectives. You know, how I I'm approaching the thing. It's not that seldomly there's a guy saying, "Well, I actually want this company to go down or, you know, this this code base to be completely full of technical data." I mean, this is not how it normally works out, right? It's more um that maybe I have too much time pressure to actually really read the code or I'm getting so frustrated by all these AI um slob that sent my way that I say, "Well, I'm also not reading that anymore."

对吧？所以，你知道，当我们出现不好的行为或奇怪的行为时，可能是有原因的。但如果我们能够理解彼此，也能够互相交流，那么我们就能帮助彼此朝着正确的方向前进。还有一些公司，文化就不太一样，对吧？在那里，大家不太能畅所欲言。你在我的工作坊里肯定能看出来：总是那些人，你很快就能认出来——这些人嘛，可以说就是领导者。比如技术负责人、经理之类的。他们会非常坦率地表达自己的看法，以及事情应该怎么做；而其他人则比较安静，或者不怎么说话，对吧？和他们共事很困难。并非不可能，但要花更多时间，对吧？Right? So the you know there there are when we have you know bad behaviors or strange behaviors there might be reasons for it but if we understand and if we can talk to each other then we can also you know help go in the right direction and then other companies like where it's more a different culture right like where we have less ability to speak our minds to say something you can definitely tell in my workshops right there are always the same people you quickly couldn't tell well these are you know, sort of the leaders. This is like the the technical lead or the manager or something and they they very openly mention their opinions and how things have to go and you know, others are more quiet or not talking, right? It's very hard to work with them. It's not impossible, but it takes much more time, right?

这需要花更多时间，也需要采用不同的方法。所以，我觉得 AI 也是如此，对吧？通过你们的工作坊，我只是有点好奇：你们举办这种工作坊的实际目标是什么？一般来说，工作坊会取得什么样的成果？It takes much more time. It takes different approaches. So, and I I see the same for AI, right? and and through your workshops if I I'm just curious like what is the actual goal like that kind of like you know generally like the success that comes out of that uh the workshop that you run

主持人：嗯，在 AI 出现之前的工作坊，主要讨论的其实是我们在代码审查中遇到的问题，对吧？比如周转时间太长，你知道，有些人给不出好的反馈。一个很常见的问题是，有些工程师会给出非常详细的反馈，而有些人则不会给出那么详细的反馈。也许有些团队在反馈措辞方面确实存在问题，对吧？比如，人们可能会觉得反馈有点让人防备，或者评论听起来更有攻击性。所以，人们面对的问题大多是周转时间，以及如何统一标准，对吧？也就是由此产生的结果差异很大。于是我们着手研究一些实践，也认真思考怎样调整这些实践，让它们适应软件开发生命周期。大体上来说，在 AI 领域，我觉得问题差不多，但它们……Host: well so the workshop before AI right were really about the problems that we had in code reviews right so this would be slow turnaround times you know people not giving good feedback very common problem was that you know some engineers give very detailed feedback some are not giving detailed you know detailed feedback back. Maybe some teams had really issues with how you phrase the feedback, right? Like maybe people felt a little bit more defensive or, you know, felt a little bit more aggressive in in in the comments. So those were sort of the the the problems that people were facing mostly really about turnaround times and this um consolidation of the standard, right? Like the very different results that are that are came came out of that. And so we worked on you know practices and really thought about you know how can we shape the practice so that it fits the software development life cycle and more or less I mean in AI it's I would say it's sort of the same problems but they

常见的评审挑战，因 AI 而加剧Familiar review challenges, amplified by AI

要重得多，对吧，像是……而且我们也有……这不只是说我们遇到的问题更多，我们其实也有更多工具，尤其是 AI，对吧？因为你实际上也可以用 AI 来审查代码。不是说……你知道，我们现在还是原来的处境，只是 PR 更多了；我们其实有很好的工具。我是说，语言模型很擅长代码审查。我不是说……你知道，我不会说“既然它们能审查，那我就不审查了”，因为这也会带来其他问题，比如理解代码、在脑海中建立代码库的整体模型，以及让大家在这些方面达成一致，对吧？所以你会错过这些，但它们确实能解决很多可能不需要人工介入的问题，对吧？所以我们正处在一个新时代，对吧？不过道理还是一样。那我们为什么要这么做呢？are much heavier right like and we also have like it's not only that we have more problems we actually have more tools as well with AI right because you can actually use AI also to review your code it's not that you know we are not in the same place we have more PRs but we actually have very good tools I mean language models are great for reviewing. Not saying that they, you know, I wouldn't go and say, well, they review and I'm not reviewing because this brings other problems also for understanding, you know, building a mental model of your code base alignment on all of that, right? So, you're missing out of that, but they can really get rid of a lot of the problems that maybe don't need human attention, right? So, we're in we're in a new era, right? And uh but it's the same thing. It's like so why are we doing this?

嗯，那么它在哪些地方需要、又该如何应用，对吧？面对这些零散的……场景，我一直努力帮助人们根据自己在 AI 之旅中所处的阶段，理解代码审查如何融入他们的开发生命周期。我们怎样才能以最高效的方式来做，对吧？这样我们就不必花时间争论那些机器其实能处理的事情——我一直觉得这很蠢。我的意思是，在我举办的工作坊里，有多少团队没有使用我们三年前就有的自动化工具？那些工具其实也很强大，比如我们有很好的静态分析工具，你知道的，还有代码检查工具、样式检查工具，但很多团队都没有这些工具，却会有……Um and where is it needed and how is it needed, right? with these fragmented um places, right? I really try to help people understand depending on where they are on their AI journey how code reviews could fit into their development life cycle. How could we, you know, do it in the most efficient way, right? So that we are not spending times at you know arguing things that actually machines could do which I always found stupid right like there were I mean how many teams I had in my workshops that weren't using the automation that we had let's say 3 years ago which was also strong like we had good static analysis you know like uh you could have llinters you could have style checkers and a lot of teams wouldn't have that and would have

AI 可以发挥作用的地方——以及人类判断至关重要的地方Where AI can help—and where human judgment matters

你认识的人会去找那些东西，我就想：你干吗要这么做？把人的注意力用在真正需要的地方啊。现在我们有了不同的工具，但你知道，问题还是那些问题，只是规模更大了，我会这么说。people you know look for those things and I'm like why would you do that like spend your human attention where it's really needed and now we have different tools but you know same problems just bigger I would say

嘉宾：对，有意思。你还在一些文章里提到了一个概念，叫作代码审查中的放手。Guest: right interesting so you also mentioned a concept in some of your writings about code review surrender

主持人：你想不想稍微分享一下这方面的情况？Host: do you want to do you want to share a little bit about that

嘉宾：是的，代码审查投降。我在和团队成员交流、做研究访谈时，看到过两种现象。其中一种是代码审查投降，也就是某种程度上放弃代码审查，对吧？但这并不是有意为之。并不是说我们已经制定了很棒的策略，所以不再需要代码审查了。更像是：嗯，这行不通，对吧？所以它成了一种装点门面的活动。我们只是装作在做代码审查，但你知道，我正费劲地看着这个很大的 PR，或者 Emma，或者你们用的其他工具，对吧？嗯，我努力理解到底发生了什么，也努力保持敏锐。嗯，但事实是，我其实并不知道发生了什么，对吧？这就是所谓的“代码投降”。嗯，这也可能表现为沉默，也就是说，人们不谈论这件事，对吧？Guest: so yeah code review surrender there were two concepts of phenomena that I saw when talking to people working with teams you know doing research interviewing people and um one was code review surrender is sort of giving up on code reviews, right? But it's not a deliberate thing. It's not like we have this great strategy in place, so we don't need code reviews anymore. It's more like, well, this is not working, right? So, it's a window dressing activity. We just pretend to do code reviews, but you know, I'm waiting through this large PR or Emma or whatever you're using, right? Um, and I try to understand what's going on and, you know, be smart. Um but the fact is that I don't really know what's going on, right? And so this would be cod surrender. Um it could be silence so people are not talking about it, right?

就是，你知道，一个接一个看起来都不错。也许我会找出一件事来挑挑毛病，或者说点什么，好让自己显得有参与其中。嗯，也可能是团队真的会说：“好吧，我们不能再这么做了，对吧？”于是他们就绕开这个问题，改做别的事，但是……It's just you know one looks good to me after the other and maybe I find one thing that I can you know nitpick on or say about this so that I seem to be participating. Um or it could be also that teams really say well we we can't do it anymore right and so they they circumvent and and do something else but

代码审查认输：假装在审查Code review surrender: pretending to review

如果没有制定策略，那我们就可以说，好吧，我们之前设定的这些目标……因为你想想代码审查，我的意思是，它们可能也有点负担过重，对吧？我们希望通过代码审查发现 bug、防止意外、进行指导和学习、追踪和跟进、分享知识，对吧？我们希望代码审查能做到这一切——我觉得这简直太疯狂了，我以前就这么觉得，对吧？我的工作坊总是从这个问题开始：你想要所有这些目标始终同时实现，这几乎是不可能的。你得花很多时间才能做到，对吧？所以，我们再深入探讨一点——这不容易，但生活本来就不容易。那么，我们审查这些代码更改时，真正想要达到什么目的呢？without a strategy in place right to say well all these goals that we had because if you think about code reviews I mean they're maybe a little bit overloaded as well right like we have bugf finding we have accident prevention we have mentoring and learning we have like tracing and tracking we have knowledge sharing right all of that we want all of that out of code reviews uh which I thought Like this is crazy even before, right? This is one of one of the things that we always start in my workshop is like, well, you want all of that all the time at the same time, which is, you know, it's almost impossible. You would have to spend so much time doing it, right? So, let's be a little bit more juicy here, which is hard, but you know, life is hard. And what do we want to get really out of this code chains when we look at it, right?

嗯，是的，是的。所谓在代码审查上缴械投降，大概就是你放弃了那些目标，只是说：“好吧，你们不看就发布吧。”或者我们大多数时候假装看了，但其实你并没有真的在看。是的。Um, yeah. Yeah. And code review surrender would be like you're giving up on those goals and just say well you're you're shipping without looking or we pretend to look uh most of the time but you're not really looking. Yeah.

主持人：对。有意思。那么你能想象一个我们不再做代码评审的世界吗？我觉得现在已经有不少 AI 实验室或初创公司声称，他们不再写 Ruby 了。你怎么看？尤其是还有“软件工厂”这样的概念。嗯，人们也会谈到“暗黑软件工厂”。嗯，你有什么看法？或者说，如果你想想不久的将来，会不会出现一个不再进行代码评审的地方？Host: Right. Interesting. So do you imagine a world where we don't do code reviews anymore? I feel like there are already at least many of the AI labs or startups who have sort of like claimed that they don't do rubies anymore. What do you think sort of like you know and especially there's also these concepts of software factories. Uh people also talk about dark software factories. Um what are your opinions or like kind of like you know if you were to think about near future are there a place where there is no code review anymore?

嘉宾：是的，这是个好问题。我现在确实正在深入研究这个问题。我的看法是，如果我们完全放弃代码审查，你知道，我们会错失很多东西，这是行不通的，对吧？我是说，这行不通。我的意思是，我们得想象一个一切都由智能体完成的世界，对吧？但这也意味着需求工程由智能体完成，对吧？产品构想和创建也由智能体完成，对吧？因为你要在哪儿停下来呢？我的意思是，现在我看到的是，我们正在把它往前后两边扩展，所以代码审查，呃，这就是我说它是碎片化的意思，对吧？我们不知怎么地开始得更早了。我其实写过这个，你可以去我的网站上看：website.com/scopeGuest: Yeah it's a good question. I'm really investigating that right now heavily. So my take is that if we let go of code reviews completely you know we would completely miss out a lot and it's not possible right so it's not possible I mean we would have to imagine a world where everything is done by agents right so but also this means you know requirements engineering done by agents right the idea of the product the creation done by agents right because where do you stop I mean now what I see is we're shifting it left and right so code reviews is uh that's what I meant with it's fragmented right so we somehow start earlier I actually wrote about that if you go on my website.com/scope

代码审查会消失吗？Could code reviews disappear?

SCOPE 大概是我正在提出的一种新的代码审查模式。实际上，我把它叫作变更监督，而不是代码监督。所以，SCOPE 代表“分阶段代码监督，并按比例升级”。听起来很高深，但它的意思是：如果我们想想代码审查这件事，我的想法是，我们要做的是代码监督或变更监督，并且在不同阶段进行监督。现在很多阶段都会提前到实施之前，这就很奇怪——它已经不再是代码审查了，因为我们会在某个东西甚至还没在编码阶段被创建出来之前，就开始审视它。所以我觉得，这种做法会向左延伸，也会向右延伸。比如，我觉得规划就是一个很好的起点，可以从这里开始考虑代码，并决定应该对它进行何种监督。然后，“按比例升级”这一部分也很有意思，这意味着我不认为每一段代码……scope is sort of the new codew model that I'm proposing I actually called it change oversight instead of code oversight so scope stands for staged code oversight um with proportional escalation sounds very fancy but what it means what it means is that if we think about code review right um I'm thinking more that we have code oversight or change oversight um and that we have it at different stages and a lot of the stages will now be before implementing right so which is weird it's like not code review anymore it's we start looking at something before it's even you know created in in the coding phase um and so I think it's it's it's going to the left and it's going to the right um so you have I would say planning for example would be a good place um to start thinking about the code right and deciding about the oversight that that should have and then this proportional escalation part is also interesting um which means I don't think that each code

范围：分阶段的代码监督与相称的升级处理方式Scope: staged code oversight with proportional escalation

变更需要同样程度的监督，对吧？有些代码变更风险更高，比如需要更多监督；有些风险较低，需要的监督就少一些。但风险并不是我们决定审查力度时唯一要考虑的因素。我们还要考虑一致性，对吧？也就是需要对这项变更了解多少，或者说它需要达到什么程度的一致性。它可能风险很低，因为影响的用户不多，但对我们的架构影响很大，对吧？所以我们希望有优秀的工程师参与这项决策，了解正在发生什么，并且认可这个决定。这大概就是我对代码审查的设想，也就是今后它们会是什么样子。我认为代码审查本身会减少，我觉得这也没问题，对吧？如果我看过计划并审查过，确认细节足够充分，然后拿到智能体的输出，再让 AI 智能体进行审查，也许我会看看它们的审查结果。这样一来，并不是每次代码变更都需要我逐行检查，对吧？有些简单的变更……change needs the same oversight right so uh some code changes they have more high risk for example they need more oversight and some have lower risk they need less oversight but risk is not the only thing that we should decide on how much review we do um alignment as well right understanding so how much understanding need does this need or you know alignment does this need um it could be that it's low risk because it's not impacting a lot of users uh but for our architecture it has a lot of impact right so we want people engineers good people to be there in the line on this decision understand that this happens and also that they're okay with it and so this is sort of how I how I envision code reviews and that they will get right so the code reviews itself I think it will get less and I think that's also okay right we don't like if I if I know if I looked at the plan um and reviewed the plan and I know that there is enough detail to it right and then I have the output of the agent and I have AI you know agents review that maybe I look at the output of those right and I then it not every code change will you know will need me to go through each line of code probably right some simple things

主持人：我想我们或许可以把同样的东西交给同行评审，对吧？我觉得这多少取决于具体情况，因为很难说这是一种普遍规律，毕竟这取决于人们如何使用 AI，对吧？有些人确实采用了这种工厂模式，会说，嗯……Host: I think we can maybe just hand over the same for peer review, right? Like I think when we it depends a little bit like it's very difficult to say this is a generalization because it depends how people implement their AI usage, right? Some people really have like this factory model where would say well

使审查深度与风险和对齐程度相匹配Matching review depth to risk and alignment

有一个工单，呃，那个工单没人看，就直接往下走，对吧？一个智能体来实现，另一个智能体来审查，然后产出点什么，你知道吧，接着就直接上线了。那这样的话，我们处在什么阶段呢，对吧？这已经非常接近流程末端了，成本也可能会很高。呃，当你在设计……好吧，现在我们得把它回滚。即使有了 AI，我也不会选择这种做法。呃，不过假设你是在采用智能体做出的更改，对吧？这和你在引导智能体做事还是很不一样的，对吧？这样你就有更多控制权。呃，在引导智能体时，对吧？比方说，仍然有开发者仔细审阅了计划，然后把计划交给你选用的大语言模型，对吧？之后可能还会稍微看一下代码。there's a ticket uh the ticket nobody looks at and it goes in right an agent implements it another agent reviews it and out comes you know something and it goes directly to production. Well, where are we there, right? Like we're very at the end could be very expensive as well. Um when you're when you're designing well now, we have to roll that back. Even with AI, I I wouldn't go for that one. Um but let's say if you're adopting changes from an agent, right, it's still very different than if you're steering an agent, right? So there's more control in it. Um when you're steering an agent, right? If you say there's still a developer that maybe looked through the plan, you know, very carefully um and then gave the plan to an large language model of your choice, right? Um and then maybe looked a little bit through the code.

即便如此，你也不必查看每一行代码。可能你知道，对吧？我的意思是，如果它涉及那个，我就知道这、这会行得通。不过你知道，人们越来越多地使用大语言模型，就会了解它们的失败模式，对吧？所以我也认为，代码审查清单会改变，而且也需要改变。Even there you don't have to look at every line of code. Maybe you know, right? Like I mean if it touches that I know this this is going to work out. But you know people know the failure models if they work with large language model more and more, right? So I also think that the checklist of code reviews will change and need to change.

嘉宾：嗯，所以他们查看它时，会有某种审查。我看到这一点，而这也是我在范围内所描绘的，对吧？这就是你知道的荷兰语语言模型和引导它的开发者之间的来回互动。这是审查的一部分，对吧？这跟你花三个星期写代码不一样。嗯，因为这个过程你知道只花了半个小时。所以你得审查代码。你实际上是在审查代码。我认为这一点应该得到认可。所以如果你引入一位新的同行，他们可能不了解这个背景：原本要花一周时间才能完成的东西，现在只花了半个小时就做出来了，但理解它依然很难，对吧？所以他们不应该照搬开发者在这里做的事情。Guest: Um and so when they look through it, there's sort of a review. I I see this and this is also what I um dispict in in scope, right? This back and forth between the you know Dutch language model and the developer that steers it. That's part of a review, right? It's different than you writing code for 3 weeks. Um because this is done, you know, like in in half an hour. So you have to review the code. You're actually reviewing the code. And I think this should be honored. So if you're bringing in a new peer, they probably don't have like the context of that something that was first created for a week now just created in half an hour, but still to comprehend, right? It's very difficult. So they shouldn't replicate what the developer did here.

引导智能体，而非接受其输出Steering an agent versus accepting its output

主持人：有意思。Host: Interesting.

嘉宾：但他们应该带来不同的挑战，对吧？带来独立的挑战，带来他们自己的背景。所以我觉得，我们得稍微调整一下，开始弄清楚在每个阶段应该问哪些问题，以及我们需要做到什么程度。我想，有些改动不需要再找一位开发者，对吧？只要有一位开发者深入了解这里的情况就够了，对吧？这取决于风险和协同程度。然后，我们就不必再让另一位队友来检查这些改动。至于其他一些改动，我觉得这样做会很有价值；如果不这么做，人们就会错失一些东西。我不是说你不能这么做，只是这么做总是有代价的，对吧？你想不想承担这些代价呢？嗯。Guest: But they should bring a different challenge, right? The independent challenge, bring their own background. So I think there we have to rescale a little bit and start understanding you know what are the right questions to ask at each of those stages and how much do we need I think for some changes we don't need another developer right it's enough if one developer intimidly knows what's going on here right depending on risk and alignment um and then we don't have to have another you know teammate for example look over that and for some other changes I think it would be very valuable and would be a that choice not to have that and people would miss out. I mean, not saying that you can't do it. Um, but there are always costs to it, right? Do you want to swallow them or not? Um.

主持人：对。Host: Right.

嘉宾：是的。Guest: Yeah.

主持人：对，有意思。所以，我的意思是，这也和我对代码审查的一些想法有点一致，我刚才也提到了一些相关内容。我很好奇的一点是，为什么这种模式还没有得到广泛采用？Host: Right. Interesting. So, I mean, this also aligns a little bit with like how I am thinking about code reviews like some of the things that I'm talking about as well. The one thing I'm curious about is why hasn't it been like this kind of like model has been adopted widely yet?

嘉宾：嗯。我觉得有一部分确实是这样，对吧？比如说到米这个单位。嗯。Guest: Mhm. I think partly it has, right? Like if you think about meter for example. Mhm.

主持人：嗯，他们至少会关注风险，也会关注其他公司，对吧？所以他们会尝试采用基于风险的方法，至少降低审核工作量之类的。他们会说，嗯，不过这更像是一起事件，对吧？至于范围和我的设想，我确实认为机械信号很重要，我肯定会用这些信号；但除此之外，我认为人的判断也非常重要，对吧？不过这里我们有的是非常机械化的信号。实际上，我们15年前在微软就这么做过。Host: Um they at least look at risk um and other companies as well, right? So they try to at least get the review load and things like that down with risk based approaches where they say well but this is more incident, right? So for scope and how I envisioned it a really I think that mechanical signals are important and I would definitely use that but in addition I think the human judgment is really important right but here we have like very mechanical signals. We did that actually at Microsoft 15 years ago.

嗯，当时我参与了那里的代码审查团队，我们做过一项实验，并且当时也进行了一半的推广，想看看人们会如何反应。这个实验用的是一种基于风险的指标，对吧？它会显示每个拉取请求的风险有多大，或者说是否存在风险。不过在那个时候——那已经是很久以前了——开发者真的很想知道，为什么会有这个信号，它意味着什么，等等。所以，至少当时，仅仅给出一个是或否的判断，或者一个绿色、橙色、红色的信号，对工程师来说还不够。工程师真的希望能掌控局面。我觉得现在也是一样：人们希望保持掌控，想要理解情况，想要做出明智的决定。所以，如果你给他们一些指标来帮助……Um we had like I was part of the code review team there and one of the experiments that we did and half rolled out at at that time as well to see you know like research um how people re react into it was this risk based indicator right so it indicated how much risk or not risk is there for each of the the pull requests but at that point I mean it's a long time ago right developers really wanted to know right why you know why do you have this signal what does it mean and so on right So just having like a like a yes or no decision or you know a green orange um red uh signal at least at that point wasn't enough for engineers right engineers really wanted to you know stay in control and I see that the same I think people want to stay in control they want to understand they want to make their own informed decision so if you give them um some metrics to help

基于风险的审查，并让工程师保持掌控权Risk-based review and keeping engineers in control

判断你知道我们是否应该进行审查，或者应该在哪里审查、重点关注什么。我觉得这类事情以后会出现——其实已经开始出现了，对吧？虽然微软 10 年前就做过这件事，但当时并没有推出；Ma 正在将它排除在外。Google 也在朝这个方向做实验、尝试类似的事情。所以，基于风险来选择审查对象，比如选择测试用例、选择审查对象，我觉得这类做法会逐渐兴起。人们肯定已经在尝试了。嗯，对。judge you know whether or not we should review or where should we review where should we focus I think it's something that will come um and I well it's coming also already right so even though Microsoft did that and didn't roll it out at that time 10 years ago Ma is ruling it out Google is you know doing experiments and doing things like this in in that direction as well so risk based review selection like test case selection review selection is a thing I think that's coming and um people are definitely playing around with it uh yeah

嘉宾：非常棒。我们时间差不多了，所以我想至少请你谈谈看法：对于希望改善团队代码审查实践的工程团队，你有什么更宏观的建议吗？他们有共同的、恰当的激励机制。应该从哪里着手？比如，他们今天或者接下来的几天、几周内能做些什么，来真正改进代码审查流程？是的，代码审查流程和常规的工程流程很不一样，比如编写代码、如今生成代码，甚至编写测试——测试也是如此。这些事情你真的可以独自完成。Guest: very cool so I know we're coming close to time so I would like to at least have your opinions on or do you have more general guidance for engineering teams who are seeking better code review practices as a team? They kind of like have collective right incentives. Where should they start? Like what things they can do today or like in the next few days or weeks to actually improve their code review processes? Yeah. So code review processes are quite different than normal engineering processes like writing code or now generating code or even writing tests right testing as well. You can do that really on your own.

主持人：嗯，某种程度上你可以用代码来做这件事，而这确实是大语言模型带来的新变化，对吧？现在你也可以自己做到这一点，不需要找别人。你只要问你喜欢的大语言模型，比如“你怎么看这个领域的安全问题？”或者“我这样做得够模块化吗？”这样的问题，对吧？所以你确实能得到反馈。但如果回到团队实践上，我的意思是，这正是代码审查与许多其他实践的不同之处：它是一种团队实践，所以很大程度上关乎分享、开放和透明。我认为，尤其是团队负责人和工程经理，他们扮演着非常重要的角色，对吧？他们的角色确实是要展现自己的脆弱，对吧？以身作则，示范良好的行为，让大家看到他们有时也会不知道答案。Host: Um and partly you can do code and this is really new right with with large language model. Partly you can do that also now on your own right you don't need another person you just you know ask your favorite large language model about you know what do you think about you know um security in this you know area or did I you know did I make that very modeler or not right so you get actually feedback there but if you're coming back to your team practice I mean this is what differentiates code reviews from many other practices it's a team practice so it's a lot about sharing being open being transparent And and I think especially team leads, engineering managers, they have a very important role, right? The role is really to be vulnerable themselves, right? Model good behavior, model that they maybe sometimes don't know.

就像我采访过那么多高级工程师、首席工程师和特别聪明的人，可他们也不知道，对吧？他们又没有水晶球。Like I interviewed so many senior engineers, principles, super smart people and people don't know, right? They don't have a crystal

改进团队评审的实用方法Practical ways to improve team review

球。我们不知道代码三个月后、三年后会不会很重要，我们到时候会不会真的读它，对吧？所以我觉得，谁要是告诉你他们知道，那他们就是在撒谎。他们不知道，对吧？我们现在也不知道。我们不知道，当我们不看代码时交付的技术债——而我们肯定会这样交付——以后会不会成为问题。有一些研究支持这一点，对吧？研究称，如果你的代码库里存在技术问题，大语言模型实际上会把这些问题放大，对吧？所以，并不是说不管你的代码库是什么样，它们都能处理得很好；你花的令牌会更多。关于这一点已经有研究了，对吧？虽然研究有限，但我们已经能看到一些证据，说明它会整体加剧这些问题。所以我觉得，是的，我们应该坦诚、透明地承认，我们现在还不知道什么才是正确的做法；同时，也应该邀请其他人分享他们的想法。如果你觉得不够安心，不敢说“你知道，我现在压力很大”，那就……ball. We don't know will code be uh important like three months from now, three years from now, will we really read it, right? So I think whoever tells you they know they're lying. They don't know, right? We don't know right now. We don't know if the technical debt that we, you know, ship when we are not looking at the code and we definitely ship it um if that will be a problem later on. Some um some research is there that backs that up, right? That says, well, if you have technical problems in your codebase, the love language model actually multiply that, right? So it's not that they can wig nicely whatever you know code base you have you're spending more tokens there's research on that right limited research but there is research already on that that we can see it right so that you know that the aggregates problems overall um so I think yeah um being very open and transparent about that that we don't know right now what's the right thing um and you know also inviting others to you know share their thinking If you're not, if you don't feel secure enough to say, you know, now I have so much pressure.

我正在发布自己都不理解的代码。嗯，这就是个问题。我觉得这是个危险信号。问题是，你的团队会这么说吗？我觉得很多人都会遇到这种情况。问题是，他们会不会这么说？你又会如何应对？如果有人这么告诉我，说这不是个危险信号，I'm shipping code that I don't understand. Um, that's a problem. I think that's a red flag. And the question is, is your team saying it? I think it happens to a lot of people. The question is, is are they saying it? And how do you react to it? If somebody tells me that, this is a not a red flag,

为什么领导者应该展现脆弱的一面Why leaders should model vulnerability

这其实是个积极信号，对吧？就像他们敢于说：“你知道，等等。嗯，我们推进的节奏快到让我无法理解，而且我对我们现在做的事情感觉不太好，对吧？”我觉得这对一个团队来说非常非常健康。更让我担心的是那些团队：你知道，他们不停地做、不断地推进、再推进，所有人都信心满满，心想：“天哪，我简直是个英雄，对吧？我做了最好的上下文工程，我有最好的智能体文件之类的，对吧？还有最好的护栏。”嗯，嗯，我反而更担心这些团队，对吧？所以。it's actually a green flag, right? It's like they dare to say, you know, hold on. um we shipping at the pace that I don't understand and I don't feel good about what we're doing here, right? I think this is a very very healthy side for a for a team. It's more the teams that you know they do and they push and they push and they push and everybody is very confident and oh my god I'm such a hero, right? I did the best context engineering and I have the best you know agent files and whatnot, right? The best, you know, guard rails. Um um I think I'm more more worried about those teams, right? So

嘉宾：嗯，Guest: yeah,

主持人：有意思。我是说，是的，今天这确实更多是人的问题和文化问题，而不是工具问题，对吧？我认为一直都会如此，尤其是在做好评审和协作方面。Host: interesting. I mean, yeah, definitely this is more of a people and cultural problem than a tool problem today, right? And I think it always will be, especially when it comes to good reviews and collaboration.

嘉宾：是啊，我的意思是，这肯定也是很好的基础设施，对吧？比如有好的上下文文件。我觉得这些都很有道理。比如说，如果我去帮别人做代码审查，我肯定会考虑一些事情：他们的测试支撑体系怎么样？验证系统怎么样？测试速度怎么样？这些方面做得好不好？嗯，不过这里也要坦诚，对吧？现在借助大语言模型，你可以有很多测试，但这些测试可能毫无意义；你也可以测试更少、覆盖率更低，但你心里有把握，对吧？而且我的意思是，如今很多事情都被激励着去做表面功夫，对吧？尤其是当我们承受越来越大的业务压力时。Guest: Yeah, I mean it's definitely also a good infrastructure, right? Having good context files. I think this is all very valid having good like if I'm going in and helping people with their code reviews, one of the things that definitely think about is you know how how is their harness looking? How is their verification system looking? How is their test speed? Are they good? Are they bad? Right? Um but again here also there is honesty about it, right? You can have a lot of tests now with large language model that mean nothing and you have maybe less test, less less test coverage, but you know you have confidence about it, right? And I mean a lot of things are nowadays incentivized to be window dressing activities, right? Then the more we have pressure from business.

我的意思是，首先我们遇到的问题是，我们没法向业务人员解释什么是技术债，对吧？我是说，这一直都是个没完没了的问题：我们怎么才能确保有时间重构，有时间把事情做好？我们一直在跟业务侧拉锯。现在我觉得就更难了，对吧？比如说，为什么你需要三周时间？我一个下午就能写出代码啊。嗯，不过你知道，这其实还是同一回事。I mean first we just had the problem that we couldn't explain technical debt to business people right I mean this was an an evergoing thing how how do we make sure that we have time to refactor that we have time to do things proper and there was this battle with you know business side and now it's even harder I guess right like why do you need like three weeks if I can wipe code that you know in an afternoon um but you know it's it's sort of the same thing um

主持人：他们确实正经历着一段有趣的时期。Host: they're definitely an interesting times.

客人：是的。嗯。是的。Guest: Yes. Yeah. Yeah.

主持人：太棒了。呃，我知道我们时间到了。Mikuela，非常感谢你抽出时间。这绝对也是一个让我非常感兴趣的话题。也感谢所有收听的朋友。如果你对开发者体验感兴趣，或者在 DevOps 平台团队工作，欢迎加入我们的 hangerdx 社群，网址是 dx.com。我们也会在那里举办线上活动。还有，呃，MichaelaHost: Awesome. Uh I know we are at time. So Mikuela, thank you so much for your time. This was this is definitely a topic which is very close to my heart as well. And thank you everyone who was listening. If you're interested in developer experience or work in DevOps platform teams, join us at hangerdx. It's dx.com community. We also run virtual sessions there. And uh Michaela

验证、测试与诚信的团队实践Verification, testing, and honest team practices

她也加入了我们最近的一次活动。呃，所以她也可以留意一下。再次，非常感谢你，Michaela。感谢你抽出时间。我相信我们还会就代码审查进行交流。joined also one of our recent ones. Uh so she can also watch for that. Again, thank you so much Michaela. Thank you for your time. And I'm sure we'll have conversations about code reviews.

嘉宾：听起来不错。好的。行。非常感谢。Guest: Sounds good. Okay. All right. Thank you so much.

主持人：再见。Host: Bye.