title: "教育工程师，信任 AI：教育如何赋能自主代码审查"

source_url: "https://www.infoq.com/presentations/duolingo-ai-literacy-code-review/"

author: "InfoQ"

excerpt: "公共早报 Duolingo 的 DevEx AI 团队打造了 AI 素养培养项目，将工具采用率提升至 100%，并让基于 LLM 的 PR 风险评分系统能够自动批准低风险代码变更，从而缩短了合并时间中位数。"

文字记录 {#presentationNotes}

Sarah Deitke： 我是 Duolingo 的一名软件工程师。我在那里工作了大约两年。大部分时间都致力于我所在的团队，叫做 DevEx AI。您可能熟悉传统的 DevEx 团队，从事合并队列、CI/CD 等工作。我的团队从不同的角度看待这些。我们专注于如何让我们的工程师在他们的工作流程中有效地使用 AI。这就是我今天演讲的主要内容。我将涵盖我们看到的行业在 AI 采用方面的文化变化趋势。我们的内部 AI 素养编程如何通过教育帮助我们的工程师。这如何能够 enables 你们公司的自主系统和 AI agents，并附有重新设计代码审查流程的案例研究。然后，你们如何在你们的组织中扩展这一点。

AI 采用是一种文化变革

让我们谈谈我们在行业中今天看到的情况。大多数组织确实有相当好的工具访问。你们中有多少人在组织中使用了 Cursor 或 Claude Code？你们中有多少人的组织有一个专门的团队来帮助你们有效地使用那些？也许在这次演讲结束时，你们会在你们的组织中倡导你们可能想要一个像我们这样的团队。此外，我们看到 AI 在工作场所越来越普遍。也许去年我们看到 copilots 蓬勃发展，但现在 agents 是大事。随着这一点，AI 有了更多责任。AI 采用在你们的组织中哪里变得困难？我认为第一个是工程师可能是持怀疑态度的。这是对人们习惯的东西、他们上学时学的东西的一个重大变化。这可能是像我们这样的团队的障碍。核心系统（如代码审查）被视为神圣的。

它们是经过多年磨练的最佳实践，现在可能正受到 AI 能够更快编写代码带来的瓶颈的挑战。AI 也挑战并改变问责制。这是我团队经常进行的一个对话。有了像代码审查这样的东西，也许我们看到工程师和审查者都有责任。当其中一个是 AI 时，谁负责？最后，信任是不同的，与问责制相同。建立缓慢，消失迅速。有了 AI，我认为很多人在将越来越多的流程信任给 AI 时会感到害怕和怀疑。

通过教育建立 AI 素养

我现在要转换一下话题，详细谈谈我的团队做的一些事情，使我们的工程组织在使用 AI 进行工作流程时感觉更舒服。我们做的第一件事是结构化的、实验室风格的研讨会。这些是相当实践性的，有大纲的东西。人们可以按照自己的节奏完成。我在这个截图中看到的主题包括学习如何使用 MCP 服务器、学习如何使用 Cursor 规则、学习如何向 LLM 发出批量请求，以及进行评估。我们真正发现的使用实验室风格研讨会的一件事是，工程师们信任他们的工程组织 pre-vetted 内容远比 say bringing in a vendor 并做更通用的解决方案。这是我们去年在公司全员会议上运行的一个截图，95% 的工程组织报告学到了新东西并且他们会推荐这种风格的培训。

如果你们正在关注一些你们想训练组织更有效地使用的新功能，我强烈建议你们尝试一下。真正帮助你们弄清楚 workshop 中应该放什么的一件事实际上是构建 AI 可观察性仪表板。这是我的团队去年运行的一个小 initiative，我们看到了很多投资回报方面的成功，并且今天继续构建。我们从一个vendor 和一两个内部工具的每日活跃用户图表开始。然后，随着时间的推移，我们扩展到包括查看哪些功能（如工程、设计、财务）正在使用不同的 AI 工具。我们添加了更多 AI 工具。我们有图表关于组织中的什么开发者社区，例如 iOS、Android 和后端，但在你们的组织中肯定可以不同。

然后我们还通过 IDE 和编程语言等查看 AI 消耗的更多 breakdown、token 使用、成本、模型家族，许多不同的分组。然后，最后，任何可能对你们的组织有趣或有用的其他东西。我确实想 call out 的一件事是我们确实从一个 vibe coded 项目开始，并且它一直是 vibe coded。我们可以直接去我们的 AI 工具仪表板并说，ok，给我添加一个看起来像这个的图表。这对于与我们的领导层很好地沟通人们在组织中在做什么真的非常有效，并真正帮助我们从那里成长。

我的团队做的另一件事是为 AI 支持提供实时办公时间。这只是一个不同的人可以在我们的组织中预订的 15 分钟时间段。这为他们提供了很多支持，比如：我想在我的工作流程中使用 AI，但不知道怎么做或者什么是最佳实践。我发现办公时间真正有趣的一件事是，它不一定被工程师使用，但它被这些可能稍微触及工程的人使用，现在需要更多支持。我认为像我们的学习设计师这样的人可能需要知道现在如何使用 GitHub，因为他们正在 vibe coding 更多项目，或者像我们的 QA 支持团队越来越多的人在他们 workflow 中使用 AI 并弄清楚如何将他们已经在电脑上做的事情实际扩展。

这对于影响可以超出你们的工程组织范围来说真的非常酷。看到那些人有了那些 Eureka 时刻并将它们带回到他们的团队并让他们更多地使用 AI，真的非常棒。我们做的另一件事是鼓励 shared learnings。我们有一个 Slack 频道用于 AI 工程构建，然后我们有一个并行的每两周一次的 AI 工程构建 meetup。在那些中，我们 nudging 人们在我们的组织中分享他们每天在 AI 工作中正在做什么，并保持低风险。学习文化，即使分享失败或成功，真的非常共享和鼓励。这使人们在工作中更舒服地使用 AI。

最后，我 put 了这个幻灯片来谈论投资你们的 AI vendor 关系，因为这是为我们组织启用 AI 的一个非常重要部分。第一点是围绕它通过 beta 程序加速你们获得新 AI 工具的 access。我们有一个这方面的例子，我们与 Cursor 的关系 nudges 我们在某些东西可用之前了解新事物。他们去年的一个新功能是 around 添加团队规则，那是他们引入这个功能之前我们在组织中遇到的痛点。像让 AI agents 知道我们使用什么 CI/CD 平台、我们在编写 Python 代码方面的最佳实践是什么、我们有什么内部库以及如何使用它们这些东西。当这个 AI vendor 来找我们说，我们有这个新功能，你们有兴趣尝试吗？

我们说，是的，让我们看看它是否能解决我们的这个痛点。这已经非常成功。我们与许多不同的公司这样做。我们非常幸运有一个非常活跃的 partnership 与我们的法律和安全团队，我们可以 say，我们正在尝试让这些新 beta 开启。你们认为这些怎么样？这符合我们的安全和法律边界吗？相当多的时候答案是肯定的，我们可以测试这些工具，为 vendors 提供反馈，并通过那个为我们的组织倡导。这里的第三个要点也是我们的 vendor partnerships 帮助我们为组织倡导。当我们与许多不同的 AI vendors 进行这些长期对话时，我们可以告诉他们，我们在这里看到痛点。Vibe coding for design 是其中一个很好的例子，我们已经沟通了好几次。

我们可以真正 nudging 他们开发帮助我们的组织的产品，使那个成为双向 communication。最后，我们 AI vendor 关系的另一个很棒部分也可以帮助我们识别我们可能在哪些方面可能落后于行业最佳实践。我有一个这方面的例子，围绕 evals。当我们将更多 AI agents 上线时，我们意识到这些 vendors 中的许多人实际上正在他们的组织中使用 evals 并看到成功。也许我们可以与他们谈论他们是如何做那个的，然后复制那个并做同样的事情。这也是一个真的帮助我们找出我们可以向他们学习的差距在哪里的非常好的 partnership。

Duolingo 为他们的组织投入了大量 AI 教育和素养，结果是什么？在过去的一年里，我们达到了工程组织中 AI 工具使用采用率 100% 的 tail end。在那之前，它是 80%，这仍然相当高。我认为我们现在绝对可以说整个组织比一年前在这方面更加素养。工程师了解在他们的工程系统中使用 AI 的优势和劣势，这我将在我们的案例研究中更多地谈到。它减少了对在日常工作中使用 AI 的恐惧、不确定性和怀疑。最后，工程师们更准备好将 AI agents 采用到我们现有的工程工作流程中，如代码审查，这我将在下一节中谈论。

案例研究：为自主系统重新设计代码审查

这是我在过去一年所做工作的案例研究，around 我们如何改善我们在代码审查方面看到的瓶颈，因为我们看到代码审查减慢从 AI 能够更快生成 PRs 中 shipping 代码。这里的用户体验现在是我们 Duolingo 代码审查的样子。我们有一个叫做 PR 风险评估的系统。它本质上将代码更改按低、中和高风险分类，或者如果你的代码审查太大，则为不确定，因为它超过了 token limit。然后如果它落入低风险桶并且满足其他一些标准，它将被我们友好的自动批准 bot 这里自动批准。这意味着我们允许你在这些情况下在没有人工审查者的情况下合并你的代码。

为什么以代码审查作为在你们的组织中运行的有效的 AI agent 为目标？在我的看来，在代码审查方面有很多优缺点。优点显然是可以 catch bugs 并从你的同行那里获得关于最佳实践的反馈。另一个优点是 mentorship，特别是对于初级工程师。然后，最后，回到 earlier，author 和 reviewer 之间的 shared accountability。在缺点方面，有很多缺点 all of your code changes 由人类审查。在很多代码更改部分效率低下。我们在 Duolingo 经常 switch teams，所以移动 around 什么 team 拥有一个代码库，这是相当可预测的，但它不一定需要有一个实际的代码 sign-off。它经常打断开发者。你可能知道 Duolingo 著名的通知系统。我们试图在我们的公司内部实践中复制我们的一些游戏化。

然后你会得到很多通知。我们看到那很多。它也是一种不一致的开发者体验。你们中有多少人在某个时候 send 你们的代码给一个真的 喜欢挑剔的人，你们有多轮需要 turnaround？vs 有时你真的只是想让那个代码更改 in，所以你把它 send 给你的工作朋友，他们 sign it off 而没有真正看它。这不是一致的。然后，最后，就像我已经提到的，现在更容易 make PRs，所以我们看到瓶颈转移到代码审查以快速 shipping。

我们的 AI 自动批准 bot 是如何工作的？它与你可能熟悉的其他 CI checks pretty similar。在 pull request push 上，它触发我们的风险评分 pipeline，然后更新 pull request CI check 和 bot approval status。我们的 PR 风险评分是如何工作的？它接收一堆参数，PR title、验证步骤、实际的 diff、一个用户提示，主要由你正在根据其风险级别对这段代码更改进行评分组成，然后是一个实际的风险提示，它将什么样的代码更改分类为低、中和高风险。将其发送给 LLM，然后我们得到一个风险层和一个风险解释。然后我确实想 call out，Meta 用他们的 diff risk score 开创了这个工作。我们的系统更加精简，因为我们的工程组织只有 300 人而不是 300,000 人。

核心原则仍然相同。我想谈谈我们的风险评估中涵盖了什么。在高级层面，低风险更改看起来像对 Markdown 文件的更改、直接和小的代码更改，所以这些是 repos 中的实际功能差异。然后是已批准的元数据和配置更改，工程师们已经 sign off 说，这是一个我进行的常规更新，我只是想要这个自动批准。在中等风险方面，我们看到像为我们学习 app 更新 API 版本这样的东西。虽然这可能是一个直接的更改，但反馈是，如果 API 版本映射由于某种原因出错，对于我们来说将其作为自动批准更改 shipping 来说风险太高了。我们希望有两个人对该情况负责。更新基础组件，如 auth、logging，即使代码更改很小，但具有更大的 blast radius 的东西。

最后，大型功能代码更改，所以添加一个新功能，但它仍然是直接的。然后是高风险更改。有很多进入高风险代码更改。我在这里提炼的三个是更改用户权限。我们总是希望获得 review。更改大规模基础设施，然后更改 Duolingo app 的特定和核心功能。还有很多我没有包括在这个幻灯片中的非常 Duolingo 特有的东西。如果你要为你的组织做这样的事情，你会看到很多事情出现并从组织中学到很多。例如，我在这些幻灯片中不包括的一件事，因为它与每个人都不相关，但你会在你的组织中看到这样的事情，我们有这些资产动画，更改那些可能有相当广泛的影响。想一想 Duo 在课程结束时弹出并向你挥手。这些类型的东西我们有 bucket 在这里，但它会因组织而异。

你可能在这一点上在想，Sarah，不让人对所有代码更改进行人工 review 是完全疯狂的，我会对那个说我们在 place 有大量 guardrails 来降低风险。第一组 guardrails 包括在你们的 repos 中为自动批准 bot 提供配置选项。我真正想到的两个是，一，将自动批准 bot 锁定为仅代码所有者更改。对于我们的 repos，我们通常有 5 或 6 个人拥有一个代码库，也许 20 或 30 人 overall 为该代码库做出贡献，但只有那 5 或 6 人有选项 turn this on，只有他们可以有自动批准。那个 repo 中 80% 的代码更改已经来自那一小群人，所以它 effectively 是一样的，但这只是那一群人拥有的那种 nice sense of security。

我们为 configs 提供的另一个限制选项是在 repo 中包含和排除目录。你们可能有 repos 的某些部分对于自动批准系统非常安全，有些可能不安全。我认为像我们的 CI/CD repos 这样的东西，我们有 like 财务 CI/CD，绝对没有自动批准，但我们可能有 scratch CI/CD，完全没问题。各种各样的东西可以不时地存在于 repos 中。我们完全禁用了 for 更改任何 AWS 资源的那个。这只是我们大多数工程组织的 preference。由于合规或资源更改原因，对于有更高审计要求的 repos（如 SOX 或 ISO 用于我们的 Duolingo 英语测试），这是法律禁止的，所以没有自动批准在该区域和 domain 运行。然后，我们还将其限制为新工程师在其入职期间。

我们已经 shift 那个 around 一点，但我们发现对于人们的入职期间，他们不知道组织的最佳实践，所以只是在启用自动批准之前有一个 block 的时间窗口只是稍微更安全。然后最后一个 guardrail 只是 around 每天的选择性通知。行业某些部分已经倡导 move towards a ship, show, ask framework，你们 shipping 大部分代码更改，你们在 shipping 前 show 人们，然后在 show 或 ask 之前请求代码审查的许可。选择性通知是一种非常好的方式，可以拥有自动批准 bot，但仍然有那种 visibility in terms of moving fast 并 once a day 看到已经 shipped 的东西，而不是每次你被通知有人希望你 review 代码更改时看到已经 shipped 的东西。

PR 风险评分的反馈循环部分我认为真的很有趣，并 ties in to 我们看到我们的 AI 素养编程的好处真正 hold 的地方。我有一个 Slack channel，proj-pr-risk-score，在其中人们报告他们看到的我们风险评分的 bucket 方面的 inaccuracies 到目前为止。我们拥有的第一个是，这个 PR 可能应该被标记为高风险，因为它更改了一些服务，或者这个 PR 应该被自动批准但不是。然后，我正在更改我们连接每个端点的方式，这可能应该是中等风险而不是高风险或低风险。诸如此类的事情，我可能在 Slack channel 中每周收到几条消息。我认为真正 powerful 的是，自从我们真正投资于 AI 教育以来，我们看到人们相当 indifferent 并且愿意接受这个系统，而之前人们一直 like，我可能根本不想 turn on 自动批准 bot。

现在我们看到人们 like，我真的很喜欢在我的系统中启用自动批准，但我只是认为这里有一个我希望你修复的 inaccuracies。我们获取这些报告并将它们基本上放入一个 eval 列表中 say，这个 PR 应该是低风险、中风险、高风险，然后挑选出我们只是想要评估和验证风险评分的解释中的关键词。然后，从那里，一旦我们有了这个 eval 数据集，我们可以根据新的开发者反馈微调风险提示。风险提示随着时间和变化，但与所有这些我从我们工程组织中的人们那里收到的关于我希望事物如何的低、中和高风险的报告是向后兼容的。这是一个 really cool flywheel 和 feedback loop 系统。我认为这真的是通过在你们的组织中拥有出色的 AI 培训和支持 enables 的。

我还想谈谈我们的自动批准 bot 系统的结果，因为它们已经相当显著和相当 awesome。我们在这里拥有的顶线是我们组织中所有 pull requests 的合并时间中位数（以小时计）。这是在过去一年多的时间里，我们看到它稳定在每个 pull request 约 18 小时。然后这条底线是通过我们的自动批准 bot 合并的所有 pull requests 的百分比。它在过去的 6 个月左右从约 0% 上升到约 10%，我们看到随着那个 climbing，我们的中位数合并时间从每个 pull request 约 18 小时下降到约 12 小时。这有一些关于这个的真正 exceptional 的事情，通过我们的自动批准 bot 合并的这 10% 的 PR，包括所有我们由于合规或资源更改原因无法为其做自动批准 bot 的代码更改。这就像一切。它不只是 what is eligible for 自动批准。然后，这也不仅仅是低风险更改。它表明当你加速低风险更改时，存在那种级联效应，即中位数风险和高风险代码更改也帮助它们，它使一切更快地合并。

从教育到安全自主

重申一下，实际上在文化中改变什么以 enables 我们代码审查系统中的 AI agent，我主要会说，我们工程师的教育培训帮助我们为我们的 AI 系统构建理解，使 AI agents 能够在你们的组织中更多地工作。这个基础，它降低了怀疑，降低了围绕在你们的组织中采用 AI 的不确定性和恐惧，并帮助人们更有效地使用 AI。就像我说的，pull request 自动批准是可能的，因为我们的组织通过我们的教育计划为 AI 工作流程做好了准备。我确实想强调我们的自动批准 bot 并不特殊，我们的工程师正在创建和扩展他们自己的 AI 工作流程，主要通过我们对 AI 素养和培训的支持使他们能够扩展。我立即想到的其他一些例子，我们有我们组织的支持 bot just to do question and answers。

这真的非常有效地帮助人们更快地 unblocked。我们有一个 AI agent 致力于修复我们 app 的一些 bug，特别是简单直接的事情。我们正在大量使用 AI in terms of 为 app 生成一些内容。这些不都是 just me，这些都是组织不同部分的人在他们的工作中有效地使用 AI。在你们 org 中扩展 AI 方面，branching out，它从 access 开始。就像我们在这里看到的，你们中约 50% 的人在他们的组织中使用某种 agentic 编码。然后我们 move towards，如果你们想扩展那个，looking at 通过 hackathons 和 learning sharings 启用 experimentation，做像 workshops 这样的素养，通过像你们的工具仪表板这样的东西创建可观察性，以便能够理解 AI 正在你们组织的哪里使用。

有时工具实际上可以帮助你们 say，我注意到我们 Android org 中有人本周比上周更多地使用 AI。他们是否学到了什么，我们可以让他们做 sharing 并扩展他们的知识？实际上我经常这样做。我看到人们在新的方式中使用，在我们的可观察性仪表板中出现尖峰，并 nudging them to share 他们的学习。这对我们的组织也非常 positive。有些人只是需要那个 nudging to share 他们一直在做的事情。此外，guardrails。我做了案例研究并谈论了我们如何 guardrail 自动批准 bot。我的团队与安全、审计、法律合作很多，以 identify 我们希望在我们的组织中有什么 guardrails 以帮助我们更有效地使用 AI。我认为这是一个每个组织肯定正在处理的故事。然后，最后，一旦你们有了所有这些 building blocks in place，你们可以 look at 自主和扩展在你们的组织中发生的位置。那是 pretty cool。

在添加 AI agents 和自动化之前，我想让你们问问自己几个问题。首先，我们是否已经在我们的组织中建立了 AI 素养，而不仅仅是 AI access？工程师们是否对我们组织中 place 的 AI 系统感到赋能？学习是否被鼓励和 visible？AI 系统在你们的组织中会感到赋能而不是仅仅被强加吗？如果 AI 要参与你们的工作流程，你们需要首先赋能你们的组织。

问答环节

参与者 1： 我是一个与我的公司非常相似的团队的成员。我想知道你们是否在循环关于代码审查的实际结果，meaning 当他们选择手动完成代码审查时，他们是否真的进行代码审查。你们是否在循环关于哪些手动代码审查实际上导致 pull request 的更改？哪些手动代码审查真的涉及更改并获得团队 feedback loop to say 也许这种代码审查你应该让它自动进行。

Sarah Deitke： 你的问题是关于代码审查更改，我们是否在验证我们为使代码审查自动进行而 bucket 到低风险桶中的那一套是正确的？

参与者 1： 更像是当他们选择手动进行时，这段代码审查是否导致代码更改？因为有时候他们手动 review，但最后你看到像十几轮 exchanges 没有导致 pull request 的任何更改，而且它仍然被 validated，这公平地说花费了我们的开发者很多时间。

Sarah Deitke： 你是在问 around 当人们做 manual reviews 时，他们实际上是在留下导致另一次更改的 feedback 的频率吗？

我认为我的答案是 two-fold。在那里，进行风险 bucket 准确性的研究的一部分实际上是 looking at 人们实际上已经在 rubber stamping 的代码更改是什么？我发现我们实际上可以相当好地 bucket 什么代码更改是低风险的，并将 that 与什么代码更改已经 just getting a sign-off with no comments 相关联。那是让我真的感到舒服 say 实际上我们应该在我们组织中扩展这个的事情之一。我们有约 30% 的代码更改没有 feedback，所以如果人们不需要 give feedback 的话引入人员有什么意义，就像一个单行更改一样。那是 part of it。然后另一部分是我们的自动批准 bot 是可选的。有时人们仍然想要 manual review just in case there is，就像他们确实想要那个 feedback 或那个 mentorship on a code change。

我会说也许 20% 到 30% 是自动批准 bot 仍然只是 reject 并 say 的粗略数字，I still want a code review anyways。那没关系。我们将其设为可选是有原因的，这样人们可以有那个 mentorship。我们没有看到太多关于自动批准 bot 太激进的投诉，以至于我们会错过可能导致流失的那种 feedback。根据我所知，这从未参与过 side incident。它确实有保守程度 level where 它真的没有导致你可能担心的那种流失和中断。

参与者 2： 我认为你提到你现在的工程师已经 100% 使用 AI 并有效地使用 AI。你们如何衡量实际效率，或者换句话说，对你们的组织来说真正的价值是什么？当然，你有这种 speed-up，例如 review 数量或 review 时间的加速。显然，这是由于你的 AI 素养，但不一定是因为开发者使用 AI。你的收益是什么，从这个 AI 采用中获得的价值？

Sarah Deitke： 我认为这是整个行业现在的黄金问题 overall around，我们现在看到 100% 的开发者在他们的工作流程中使用 AI，但它对组织有什么影响？我可能会说对我们来说可能是 two-fold。它可能对你们的组织来说是不同的。第一个是人们确实感到更有能力使用 AI 来 build，像 integrate 在他们的系统中。甚至在我们的产品中，我们有一个 called Video Call with Lily 的功能，你可以用你的其他语言进行视频通话。让我们的工程师熟悉 AI 为我们的产品添加很酷的 AI 功能是有价值的。然后除此之外，它 also empowers 我们的工程师在工作 slightly more ambitious in their work，也许 to take on projects 比他们可能甚至一年前都会做的稍微大一点的事情。这是我的团队经常谈论的事情。

就像我们现在面临所有这些新问题，比如我正在努力做一个我不是主题专家的新项目。如果我没有使用 AI 和帮助我加快自己的支持，我永远不会 never 被分配这样的工作。我们在整个组织中也看到了这一点。

参与者 3： 你非常 nice 地展示了减少 pull request 批准平均时间的 effect。在自动批准与手动批准方面，你是否注意到或能够辨别缺陷率有任何变化？数据中是否有任何信号？

Sarah Deitke： 在大多数情况下，没有。我们每天大约有 200 个 pull requests，如果我的数学正确的话，我想说其中也许一两个是自动批准 bot 请求的 revert。这也是难以确定的 like 其中多少 revert 是因为我们需要一个 human reviewer vs just like a human reviewer 会有的。我会说工程师们做了很多事情 like，我要去测试 CPU 上升并看看会发生什么。"那很糟糕，让我们 revert it。"他们知道他们在做什么。有多少是那些情况 vs like，我们可能应该首先使用 reviewer。我几乎认为如果我们已经看到那样的显著缺陷率，这个项目可能几乎立即被 shut down。

参与者 4： 当你真正经历这个旅程时，你为你自己 set 的目标是什么成功指标？总的来说你认为你在目标方面处于什么位置？

Sarah Deitke： 我认为当我第一次着手做这个项目时，Meta，他们称之为 diff risk score，但它本质上是相同的概念。他们实际上主要以一种完全不同的方式使用它，即 gatekeeping 高风险代码更改在更安全的时间通过。我认为这也是一个真正棒的想法，有很多优点。当我第一次介绍那个想法时，Duolingo 是一个喜欢实验和喜欢快速 shipping 的公司，添加摩擦是不可接受的。从那里，我们可以 pivot 并 say 实际上这是一个对于低风险更改仍然很棒的系统，我们如何 enable 我们的工程师更快地 shipping？在我们的开发者调查和指标中，我们看到的东西 is like，人们真的喜欢在他们的组织中有这样的东西。我们最近的工程调查中最多的反馈之一是 like，"Love the 自动批准 bot，你们应该 keep it up。"一种pivot，不完全是 original intention，但拥有一个支持 pivot 的组织也总是很棒的。

查看更多带文字记录的演讲