Braze的CTO如何重新思考工程以适应代理领域

布莱泽首席技术官如何重新思考工程领域

URL来源：https://stackoverflow.blog/2026/05/13/rethinking-engineering-for-the-agentic-area/

Markdown内容： 布莱泽的联合创始人兼首席技术官乔恩·海曼（Jon Hyman）在《代码领袖》节目中与Stack Overflow的首席产品和技术官乔迪·贝利（Jody Bailey）一起分享了他在近15年的公司成长过程中如何领导公司的工程团队——以及他们如何在短短几个月内转型为以AI为核心的团队。

乔恩解释了一些关键时刻，这些时刻改变了他的思维方式（看到他的团队提前六周交付MCP服务器会让人有这样的想法！），并坦率地讨论了在300人的工程组织中推动采用的文化和实际挑战。他解释说，模型质量而非强制性措施是赢得怀疑者的关键因素，并且超过60%的布莱泽承诺代码现在是由AI生成的。

乔恩还回答了更棘手的问题：如何衡量AI的真实商业价值，大规模推理的惊人成本，为什么“通过氛围编码来扩展”是愚蠢的，以及随着自主代理开始一夜之间构建功能时接下来会发生什么。

你可以通过LinkedIn与乔恩联系。

脚本

Eira May：

大家好，欢迎来到《代码领袖》。如果你是第一次加入我们，这是一个在The Stack Overflow Podcast中的环节，我们会聚集高级工程领导者，谈论他们的工作、团队建设以及目前面临的最大挑战。我是Eira May，是Stack Overflow的B2B编辑，我在这里和Jody Bailey在一起，他是Stack的首席产品和技术官。

Jody Bailey：

哦，我很高兴能再次加入你们。很高兴能和乔恩交谈，了解他正在做的事情。

Eira May：

是的，我也很期待。今天我们邀请到了乔恩·海曼（Jon Hyman）。他是布莱泽的联合创始人兼首席技术官，这是一家客户参与平台，不得不说的是，我们的营销团队非常喜欢它。

乔恩，欢迎来到节目。

Jonathan Hyman：

你好。非常感谢你让我参加这个播客。

Eira May：

乔恩，我想问一下，你在布莱泽已经十多年了。从初创公司到全球领导者，你经历了这一切。当你考虑什么是好的工程领导力及其包含的内容时，你的理解是如何随着时间变化的？

Jonathan Hyman：

你说得没错。我们差不多15年前创立了这家公司，在技术领域这几乎是一生的时间。能够从移动技术的诞生到其增长，建立一家由世界向移动化转变而催化的业务，现在又处于被AI催化和改变的世界中，看到我们的业务在这两个方向上的转型，真是太令人兴奋了。从移动方面来看，一个主要的驱动因素就是工程方面需要多大的规模和速度才能在移动世界中运作。当企业决定进入移动领域时，它们获得了全球受众的访问权，用户希望能够在任何时候与他们互动，他们对实时互动提出了很高的期望。

我一直告诉人们，“你现在责任重大。你有一个设备在我的口袋里，可以通过它与我交流。当我与朋友、家人或妻子在一起时，你需要说出一些真正重要的事情。”因此，从工程的角度来看，我认为工程师和工程经理必须非常清楚如何扩展以及他们的产品是如何工作的这一点至关重要。

对我来说，自从第一天起就参与产品的技术基础和技术架构，让我能够作为领导者非常有效。我经常自称为‘一线将军’。我不是在五角大楼等着的人，而是实际上与部队在一起，能够理解我们面临的运营挑战，新功能或新产品领域的复杂性和困难，或者只是帮助最终实现扩展。我认为这一方面对于我的有效性以及激励团队来说非常重要。

即使现在看AI方面，我认为情况也是如此。我深入研究AI，推出了各种各样的代理。我相信我们稍后会在播客上讨论这个问题。我对自己的观点和看法有很多，能够与一些最好的建造者平起平坐，他们正在构建很棒的管道，设置出色的自动化，并使用AI改变他们的工作流程。我的熟练程度和理解能力使我能够在对话中继续有效，并且正如我所说，激励他人。

Jody Bailey：

你们在过去15年里发展了很多，对吧？我认为领导风格和所需做的事情已经随着这种发展而演变。你是如何以不同的方式领导领导者而不是IC，并且保持平衡，可以说，能够与之平起平坐？

Jonathan Hyman：

当然，我们肯定不得不随着每个人都能在同一房间内理解彼此的工作而不断调整我们的组织。专业化是一个很大的部分。当我们最初考虑如何组织自己时，就像许多初创公司一样，你有一池工程师，然后将其分成前端或后端工程师。

但在公司早期，工程师可以从事任何工作，产品经理也可以负责任何项目。我们把构建新事物时面临的优先级挑战比作数独问题，需要前端工程师、后端工程师、产品经理和设计师协调时间表，共同合作才能完成项目。很快我们就遇到了问题，这促使我们组建了团队，并最终形成了部门结构。现在我们有工程经理向产品空间的总监汇报，而这些总监又向部门的副总裁汇报，最终向我以及我们的工程高级副总裁和首席产品官汇报。这种演变意味着，随着层级的上升，工程经理们需要管理越来越复杂的事务，领导超越日常运营的工作流。

当我们谈到部门领导时，我们会每周与所有部门负责人会面。他们需要设定目标、审查架构和设计，并为业务的大板块制定愿景。一方面，我会与部门负责人讨论他们应该建设什么，如何思考他们的产品领域。他们是否需要改善某个产品领域的健康状况？是否需要推动功能采用？还是需要驱动这些功能的货币化？最终，我们在做什么？我们的产品在市场上有多具竞争力？

另一方面，就像你在工程方面所经历的那样，有时候你需要深入细节，才能知道团队是否有效率。作为领导者，我也发现，在与工程师讨论估算或解决问题时，这样做也很有效。很多时候，人们可能会定的目标过高，或者对问题考虑得过于宽泛，看不到森林中的树木。

你可以提出疑问：“等等，这对我来说没有意义，为什么我们不能这样做？” 能够自己进行原型设计也能帮助打破问题的瓶颈，展示给团队前进的道路，然后让他们的领导者接手并推进。

乔迪·贝利：

我假设你们正在利用人工智能来帮助快速原型设计，这样的假设合理吗？

乔纳森·海曼：

是的。人工智能的爆炸性发展在Braze的发展过程中非常酷。从AI帮助我们自动补全代码到AI成为可以接受指导和方向的初级软件工程师，再到如今成为不需要太多指导的高级软件工程师，这一切发生的如此之快。我们现在正在思考如何使用AI自动响应触发器来构建东西。如果收到错误报告，AI能否自动提交拉取请求以修复它？如果有测试失败的拉取请求，AI能否自动修复，这样工程师就不用做这些事情？我们刚刚开始实现很多自动化，虽然还处于早期阶段，但在过去的三个月里，我们已经彻底改变了Braze的工程方法，将AI应用于每个项目的处理方式。

乔迪·贝利：

三个月内完成，尤其是在一家15年的公司中，这是怎么做到的？你们是如何从代码完成过渡到自主代理的？

乔纳森·海曼：

回顾我们的人工智能历程，长期以来，人工智能的前沿状态主要是代码补全。我们很早就采用了JetBrains IDE进行代码补全，后来又引入了GitHub Copilot，它不仅能补全代码还能回答一些关于代码的问题。当Claude Code在2025年2月底推出时，对我来说是一个重大转折点。我记得在它发布后大约六七天，晚上和妻子吃饭时，我一直在谈论它，非常兴奋。我给联合创始人和CEO发送了截图，表示“我无法相信AI能做到这些，太令人震惊了。”

当时我的目标是启用整个组织。因此，在接下来的两个月，从二月到四月底五月初，我尝试为团队提供不同的编码工具。我们购买了Cursor许可证，加倍投入GitHub Copilot，并开始进行自动化代码审查。通过AWS Bedrock，我让任何想要使用的人可以访问Claude Code。我们还举办了AI午餐学习活动，以赋能团队。同时，我也在努力推动AI在整个公司的应用。

在第一阶段，我称之为赋能与指导，确保人们了解这些工具的存在，知道如何访问它们，并开始向他们展示一些示例。因为就在八个月前，我们还有很多员工不知道该怎么做。我曾与Braze的高管交谈过，他们问：“我应该用Gemini做什么？你能给我一个例子吗？”因为我们都是老手了，在软件或非软件领域工作了20年甚至30年。现在有了新技术，我们必须建立这种能力。

我们继续进行实验，模型也在不断改进。对我们来说，2025年8月标志着这一重大转型的开始，因为在8月份，我们计划在即将到来的重大客户会议之前发布一系列AI功能，其中第一个就是MCP服务器。整个夏天，我们看到了对MCP服务器的需求。我们决定：“你知道吗？MCP服务器是一个低风险项目，是一片绿地。让我们尝试完全使用AI来构建它。让两名工程师来做。”结果，他们在大约六周内提前完成了MCP服务器的开发。这对我来说是一个令人兴奋的时刻，因为我意识到，这将是团队效率逐步提高的一个重要步骤。

我在推特上看到有人说，“它的效率提高了30%到40%。”但在我的日常工作中，我并没有看到这样的效果。有些模型表现不佳，我花了大量时间进行修正。我对工程组织进行了调查，发现很多人也觉得模型有时会增加更多的工作量而不是节省时间。因此，人们对使用AI持谨慎态度，因为他们不确定是否值得投入时间。但当我们看到8月份的项目进展顺利时，情况发生了变化。我们开始说，我们需要将AI融入更多的工作流程中，并推动更多人采用它。

当然，当Opus 4.5在11月推出时，那是一个游戏规则改变者。因为我们从需要给用户提供一些方向的模型，转变为一个几乎不需要太多指导就能快速正确地构建有意义功能的模型。随着我们推广这个模型的输出，我们的团队采用了它，就像野火一样迅速传播。上周，我查看了统计数据，超过60%提交到我们主要仓库的代码是由AI编写的。这个飞轮效应一直在持续，因为团队中的其他人也开始使用它并看到同事们的成果。

所以对于我们来说，这是一个令人兴奋的时刻，因为我们正处于起步阶段。如果我们把AI的发展比作一天，我们现在就像是午夜刚过，已经取得了如此多的成就。

乔迪·贝利：

我认为所有这一切的最大挑战之一在于文化。首先，刚开始时，我相信你的工程团队里有不少怀疑者，不仅仅是怀疑，而是完全不相信。你是怎么真正说服他们的，还是所有人都被说服了吗？

乔纳森·海曼：

我认为说服他们的是模型质量在短时间内大幅提高，以及这些工具确实有效的证明。因为根据我的调查，我们定期向团队发送问卷，也会在部门员工满意度调查中询问他们关于AI的使用情况、有效性以及所需工具等问题。有些人认为非常好，而有些人则表示：“你知道吗？我不怎么使用它，因为我的体验都很糟糕。”

我们在工程中做了通常会做的事情。举办午餐学习会，进行演示，提供帮助以让他们快速上手，并推广那些效果很好的工具。我们试图通过自下而上的方式来推动这种变革，因为工程师喜欢动手实践，喜欢听别人的经验。当他们看到一些酷的东西时，他们会说：“哇，我也想要那个，因为它都是代码，你应该能将其整合到自己的工作流程中。”

我们尝试了这些方法，但最终，我认为采用率的提升主要归功于模型变得更好，以至于让我们作为领导者能够提高团队对AI可能实现的目标的期望。六个月前，人们还在讨论这些事情，但我自己都没有看到实际效果。但现在我自己看到了，我们开始期待其他人也能使用它。当有bug报告时，我会在Slack上私信工程经理，说：“嘿，这个能不能让Claude来处理一下？”或者客户提出请求……我们有超过2500个客户，他们总是提出各种各样的功能需求，我们会考虑这些需求并纳入我们的路线图，但就像每家公司一样，我们不可能满足所有客户需求。

接下来的一些功能中，有一个是针对我们的客户DraftKings的，我当时就在想，“哦，我们只需在提示中写一下，AI就能构建出来。” 现在我作为领导者看到了这些可能性后，我可以对团队提出更高的标准，要求他们产出更好的成果并提高速度。这也会促使更多的人采用这些技术。当然，这一切都是自我强化的，当越来越多的人看到它带来的好处时，他们就越想使用它。

乔迪·贝利：

你们去年进行了收购，对吧？

乔纳森·海曼：

没错。我们收购了一家公司叫OfferFit。他们是一家非常优秀的营销软件强化学习引擎公司。自那以后，这次整合非常成功，我对他们的团队和产品印象非常深刻。

乔迪·贝利：

我很想知道，将两个背景不同、工程哲学不同的组织合并在一起，你是如何应对的？这对你的AI之旅有何影响？

乔纳森·海曼：

首先我要说的是，我们的文化非常契合。这也是我们在与他们的整个团队交谈时非常喜欢的一点，他们的运作方式非常适合我们的方式，开放、直接、创新，而且我们的领导风格也是互补的。

当然也有一些挑战。例如，他们是完全远程办公的公司，而Braze则更倾向于混合办公模式。我们在全球有15个办公室，喜欢在办公室附近招聘员工，这样他们可以参加我们举办的活动，并且可以在一周内进行面对面的合作。因此，在这种疫情后的情况中，我们需要在这方面达成一致。但最终，我们还是尝试将两者融合在一起。

例如，他们是一家规模较小的公司，明显比我们小得多。收购时我们有大约1800名员工，而他们只有150到170人左右。由于他们规模较小，不是上市公司，所以行动更快。他们在实验和运行新事物方面比我们这样的上市公司更容易。但我们逐渐尝试将他们的好做法融入进来。我们将他们的线性系统迁移到了我们的Jira系统上，他们使用Graphite来进行拉取请求和堆栈拉取请求管理。我们现在也在整个组织中试用Graphite，这是从他们那里借鉴过来的以及一些实践。

总的来说，我认为我们一直在以一种谨慎的方式思考如何将他们的工作方式带给我们，以便让我们更快地前进，同时也尽量让他们尽快适应我们的工作方式，这样我们就可以展示我们是一个团队。我之前提到过，我们采用的是事业部制，所以我们把他们的工程团队纳入了一个事业部。它的运作方式与其他事业部一样，有着相同的汇报、结构和流程。这使我们能够快速整合产品，并让客户迅速看到其价值，并继续增加这一价值。

乔迪·贝利：

对不起，你说他们是作为一个独立的事业部运营，还是分散在多个事业部？

乔纳森·海曼：

非常好的问题。在工程方面，我们是基于事业部的。例如，我们有一个负责渠道的事业部，比如发送电子邮件、WhatsApp、短信等的事业部。还有一个负责编排和数据的事业部，还有一个负责DevOps工程的事业部。现在他们又新增了一个机器学习和强化学习的事业部。这个结构与其他事业部平行。因此，我们能够迅速将其与我们的流程对齐。在整个业务层面，我们也面临着其他整合挑战。刚才我只谈到了工程，当然他们还有销售人员、市场人员、产品经理和支持工程师等。我们正在努力将他们安排到最合适的岗位，以确保流程和一切保持一致。

乔迪·贝利：

当然，工程进展得最好，对吧？

乔纳森·海曼：

没错。工程的一个好处就是很容易衡量。销售你可以看到你关闭了多少交易，工程你可以看到集成的速度和状态。所以很高兴它是客观的，因为我们可以真正地审视它，并为我们所取得的成就感到自豪。同时，我们也可以回顾并指出哪些做得好，哪些做得不好，因为这些工程流程在引入一家新公司时同样有效，就像引入一个新特性一样。

乔迪·贝利：

你提到了衡量，这让我想起或好奇，你们是如何衡量AI的成功呢？根据你的说法，听起来你们已经取得了结果，对吧？我是说，东西已经上线了。但在你们开始这段旅程时，你们是如何考虑衡量采用率或成功的？以及AI的价值呢？

这是一个很好的问题，我们甚至现在还在努力定义它。那么，我将简要介绍一下 Braze 的整体 AI 进化历程以及我对它的看法，然后用工程部门作为例子来说明。作为首席技术官，我不仅仅关注工程方面，还试图思考 Braze 的整体技术工作。我审视了 AI，并认为有三条主要的发展路径。

第一条路径是我之前提到的赋能和意识。让我们让公司内部的每个人熟悉这些工具，让他们能够使用这些工具，并展示一些优秀的用例以鼓励他们的采用。从这一点来看，我们发现人们会说：“天哪，你知道吗？我现在效率高多了，因为我有了 AI 工具。”无论是编写功能还是客户成功经理总结会议并撰写邮件，或者听取 Gong 的通话记录，我们都能提高一些效率。这种自下而上的方法，我认为不足以真正改变公司。你可以帮助每个人的个人生产力，但即使我让每个人都提高了 20% 的生产力，也不清楚这如何转化为 Braze 增长速度加快 20% 或利润增加 20%。

因此，我们必须进入下一个工作流，即让各部门开始考虑他们正在做的任务，并转向 AI，不仅仅是作为顾问或指南，而是更像一个同事。这就是代理空间，你开始思考，与其建立一个像 Gemini Gem 那样的东西，我可以上传一个文件并请求反馈，不如让 AI 生成的输出与同事的无异，我可以带着一份文件去它那里，它给我返回更新后的文件或准备好发送的内容，或者为我创建一个演示文稿。

这是我们正在努力的下一个阶段，也在某些领域取得了一些进展。这涉及到我们在工程方面的努力，尝试思考如何自动生成 ProQuest 中的错误报告，如何处理 Jira 项目和史诗，让 AI 自动编写所有这些内容。我们在这个领域还处于非常早期的阶段，因为大家都在努力构建这些自动化工具，我们需要把这些工具真正设置好并使其运行良好。

然后是第三条支柱，即如何实际改变影响公司上下线业务指标的方式。从市场到客户的方面来看，比如如果我们能减少账户执行官达到熟练程度所需的时间，这实际上会被用于财务预测，并将带来更多的收入和利润。因此，我们可以开始着手优化这一点，看看是否可以使用 AI 来减少账户执行官的上手时间。显然，客户服务支持也是关键，当人们在想如何减少客户服务支出并确保其有效性时，或者我们如何构建产品以避免支持工单的产生？这些都是很好的优化指标。

在工程方面，我们还没有完全定义这些指标，但我必须告诉你，我们在工程中面临的一个重大挑战是我们意识到 AI 推理的成本非常高。最终，这些模型现在非常好，但它们很贵，尤其是当人们每天将其作为工作的一部分使用时。我们曾经在 Braze 开玩笑说，最好的投资之一就是让我坐飞机，因为每次我在飞机上都会编写很多代码，我们会飞往另一个办公室，当我下飞机时，我会提交一个 ProQuest 并说：“我完成了这个功能，效果很好。”

最后一次长途飞行时，我从东京回来，我想：“我不再想独自编码了，我需要互联网连接以便使用代理。”因为我工作的整个方式都在围绕着对工作中 AI 的需求而变化。我们也看到工程师们也在改变自己，有些人每天都使用模型。他们每天工作八小时，可能有六个小时是在我们的模型上工作，会议间隙或者其他时间也可能一直在使用，甚至更多。这很昂贵。

我们很快需要解决的问题是如何最有效地利用大型语言模型推理，以及如何开始衡量人们对大型语言模型的使用情况。今天我刚刚查看了一下按需支出，这是三月的第一个工作日，我们有一位工程师已经花了 150 美元在推理上。如果这样计算下去，仅这位工程师每月的代币成本就将达到 4,500 美元，按工作日计算可能少一些。但要考虑到我有 300 名工程师，突然的成本增加确实很难应对。

还有一个工程师可能花费更少，但能产出更多的成果。也许他们在上下文理解上做得更好，也许沟通更顺畅，也许他们使用的是更适合任务的模型，而不是最新的最伟大的模型。现在，工程领域需要迅速关注如何以最少的推理成本获得最多的输出。目前我认为，在工程领域，成本是一个非常重要的指标。但我还没有完全想清楚，因为我们刚刚开始探索这个问题。然后是如何将这一点与速度联系起来，并且如何以持久和可衡量的方式提高团队的期望，将是我们在这一领域首先关注的两个重点。

乔迪·贝利：

是的，这对我来说很有道理。这与我的一些观察相符。我觉得有趣的是，我们如何衡量代理的生产力？就像我们从未弄清楚如何衡量开发者的生产力一样，为什么我们认为可以衡量代理的生产力呢？而且，这其实是一样的问题，对吧？

乔纳森·海曼：

因为你是在按消费付费，所以你总是会问自己，“我们是否以最优的方式完成了这个任务，是否可以更便宜地完成？” 商业人士一直在问自己这样的问题，工程经理和产品经理也一直在问，“我们如何以最快的速度、最低的成本推出产品？” 而且由于人工智能，每次任务完成后都会给出一个美元数字。我认为我们现在开始问自己，“天哪，这真的值得吗？” 如果有人今天花了150美元，他们的产出是否值得这150美元，再加上我们为个人支付的其他费用？

这将是一个挑战，因为这是一个预算冲击。这些东西对于生产力来说太好了，太有价值了，以至于我们在几个月前的预算周期中并没有意识到会有这么高的推理成本。现在我们看到了这些成本，不得不进行调整。顺便说一下，我认为高昂的推理成本将会逐渐侵蚀人们的假设，即人们会在内部编写自己的软件。最终，如果Citroni说推理成本会像电力一样便宜或像水一样免费，那当然是可行的，但我们都知道实际情况并非如此。OpenAI 需要花1000亿美元来建造数据中心，这并不便宜。当你看到账单时，你会说，“我的团队每天花费150美元，你是想让资源被占用去做这个，还是购买软件？” 我认为一旦我们将成本纳入讨论，这将改变对话。

乔迪·贝利：

是的，这很有道理。我也认为这仍然需要有人来设置并开展工作，企业有其核心业务要处理。他们真的想为所有业务部分构建所有的解决方案吗？他们也有有限的预算和时间成本。他们会专注于什么？

乔纳森·海曼：

当然。我觉得这甚至更大一点，因为你看，全球范围内所有人都立即获得了生产力的阶梯式提升。如果你有100名工程师，突然间你有了相当于180名工程师的产出，那么你做的第一件事是不是去构建Salesforce？因为你的所有竞争对手也从100名工程师的产出增加到了180名工程师的产出，他们正在推进自己的路线图，而你也必须跑得更快。明天当人工智能变得更大、更好、更快时，你必须跑得更快。

所以，如果你认为人工智能是免费且无限的，我称之为“奇点事件”，大家都会在明天去构建他们的路线图。但实际上你没有看到这种情况。你看到的是速度的提升，但这种提升无处不在，这使得竞争越来越难。我认为，当人们真正开始意识到这一点时，他们会发现，“哦，我们尝试构建这个软件，”等到我们终于建成了，他们会说，“哦，用Vibe Code两周就能搞定。” 到了两周后，你刚用Vibe Code完成的软件，他们已经构建了更多东西，你又得继续追赶。

这是一种非常天真看法。我认为公共讨论中缺乏的是权衡意识、竞争意识以及人工智能的次级效应、成本和未来维护的所有问题。这是我们作为工程师在组织中面临的真正难题，这是一个非常困难的问题。我们面临着许多关于在使用AI生成代码构建路线图和服务需求时的次级效应的艰难挑战。

乔迪·贝利：

嗯，我认为关于路线图的评论非常重要，因为归根结底，你可以快速构建各种东西，但如果没有用，不是客户需要的，没有增加价值，那么你应该构建吗？还有成本问题。你怎么看待这个问题？你的产品管理和路线图迭代的关系以及思考方式是否在演变？它改变了什么？

当然，这已经发生了。我来简单介绍一下它是如何运作的，并且说一下我们公司目前的情况——我们大约有2000名员工。我们上市已经有四年了。我们有很多知名的客户。我与不同行业的许多企业合作，规模也各不相同。当我们开发产品时，我们处于一个有利的位置，这些产品经过了充分的研究和精心设计。我们有很多客户提供反馈。我们有一支优秀的用户体验研究人员团队，还有一支出色的产品经理团队，他们会去与客户交谈，了解我们的工作进展，然后我们会进入早期访问阶段。到了通用可用性阶段，我们非常确定我们所做的一切正是客户想要的，并且具有非常易于理解且对客户非常有效的用户体验。我们推出的产品是我们知道客户市场会非常喜欢的。

现在，AI为我们带来的两个即时影响主要体现在市场产品经理这一方面。一个是它使产品经理和设计师能够自助解决一些需求并修复一些小问题变得更加可能。这可能是设计师需要调整某个页面的固定间距或以某种方式调整页面布局。我们将这些称为用户体验债务。最终，这些会让客户感到困惑的事情，可能会导致支持工单，或者需要额外的步骤。有一个很好的例子是在我们的邮件编辑器中，如果你没有退订链接，我们会弹出一个验证提示，要求你必须添加一个退订链接。这里的用户体验设置是，我们不会告诉人们如何去做，所以你应该点击这里添加一个链接或链接到文档，或者从错误消息中提供一些帮助，使其更容易理解。

每个团队都有一个永不过时的目标（OKR），每季度他们必须完成五个用户体验债务项目。这是我们的产品健康计划的一部分，旨在让我们的产品更易于客户使用，减少支持工单负担，并更好地服务于客户。设计师现在可以独立完成这些事情，这真是太酷了，因为人们在构建东西时不再需要工程师的帮助。

第二点是，我们看到产品经理正在使用Vercel和Cursor进行快速原型制作，以便创建交互式草图，我们可以快速讨论这些草图。我们已经从Figma草图中走了很远，那些草图已经非常令人印象深刻了，比如我可以点击下拉菜单并点击下一页，所有功能都正常工作。而现在，我们甚至更快地可以在Vercel中构建v0版本，并将其展示出来供我们讨论、向客户展示并与之对齐，确保我们在正确的方向上前进。

也许我可以再补充一点，即我们的建设现在可以稍微领先于设计。我的意思是，历史上，很多设计和开发都是在我们已经有了产品规格和设计草图之后才进行的。显然，它们可以交给工程团队按照规格进行开发。但由于我们改变用户界面并将其应用于设计草图变得如此容易，设计师们还在与用户体验团队和产品经理一起确定最佳流程时，我们就可以开始开发了。这也让我们能够加快速度，为愿意接受不太完美的用户体验以获得最前沿功能的测试客户提供产品。

这真的很酷，因为我们过去从未这样做过，因为返工会花费很多成本。但在返工成本较低且工程师可以自己创建UI的世界里，这成为可能。因此，看到这一切如何让我们比以前更快地完成更多工作真是太棒了。

乔迪·贝利：

太棒了。从你说的来看，你们做得更好、更快，并且学会了如何做更多的事情。相比之下，很多人最近公开表示，“由于AI，我可以削减70%的工程团队。” 我认为，我们应该思考如何利用现有资源为用户提供更多价值，这才是正确的思维方式。

乔纳森·海曼：

没错。作为一家成长型科技公司的技术领导者，我不理解“我们不需要那么多工程师”的说法。我知道有很多公司本来打算招聘四五个工程师，但后来发现不需要。我有个朋友正在创业，他说他们节省了很多钱，因为他们能够自己开发iOS应用，而不需要雇佣别人。这对他们来说真是太好了。

但我所在的领域竞争激烈，路线图庞大。我有很多好主意，但人手不足。在过去，我有100个好主意，只能实现其中20个。现在，我有100个好主意，可以说让团队实现其中40个。但这并不改变我仍然有100个好主意的事实，而且我希望尽可能快地实现它们。我认为，工程师们能够继续做更多的事情，这一点对我来说非常吸引人。我认为，由于AI，我们可以继续快速增长。

我认为有很多讨论和共识，即人工智能实际上正在催生对更多软件的需求。人们想要构建更多的东西。我们有更多的路线图需要实现，或者正如你所说，任何人都可以创造的内容更多了。现在就像是你可以实现更多的路线图。我们绝对看到了这一点。因此，在 Braze，我们的工程团队规模还远未达到峰值，我们还有很多想继续做的事情，而且我们对此充满渴望。

乔迪·贝利：

没错。在我的职业生涯中，创意从来不会短缺。总是有比你能完成的更多的事情要做。所以看来这种情况并没有改变。

乔纳森·海曼：

没错。确实如此。我想指出的一点是，你不能简单地扩展代码规模。真正重要的是扩展能力。你可以编写很多代码，但最终能够在高复杂性、大规模和高负载用例下运行这些代码，这需要对你要做的事情、你解决的业务问题以及所有系统如何协同工作的深刻理解。

目前，即使有百万令牌的上下文，我的大脑对整个系统的了解也远远超过模型的理解范围，不仅仅是代码，还包括业务流程、业务系统、客户挑战、客户用例以及所有这些领域的知识，即人们试图做什么，他们是如何使用我们的产品的？这样当我们去构建某些东西时，我们可以确保它很好地符合他们的需求。

乔迪·贝利：

没错。要把所有这些知识都塞进一个上下文窗口是不可能的，对吧？

乔纳森·海曼：

没错。至少目前是这样的。

乔迪·贝利：

对。确实提出了一个好问题。我意思是，那些散布在你大脑中的知识，然后组织内所有人的知识，如何将其转化为代理等可以使用的有用信息？如何平衡这些知识随着人员离职而带走的风险？你们是否以某种方式捕获这些知识，或者你们是怎么考虑的？

乔纳森·海曼：

我可以告诉你我们现在正在做些什么以及我预期会发生什么。目前，我们正在尝试将我们的工作方式和最佳实践规范化。最简单的例子之一是在编码方面，我们制定了前端的 React 标准，规定了我们期望如何编写前端测试，以及我们期望使用哪些框架。我们试图把这些写下来，因为我们看到前端端点创建的脚手架非常糟糕，因为它更像是那种现成的、不符合我们应用构建方式的东西。

我们的前端团队看到这种情况时会说：“天哪，它使用了很多反模式。” 如果我们能够规范脚手架的编写方法、我们期望如何编写测试，以及我们在 Cypress 端到端测试、单元测试和其他前端单元测试中希望涵盖的内容类型，这对模型来说是非常有帮助的。所以我们现在正在尝试这样做，这实际上是在逐步建立技能，并让模型在聊天会话中学到新技能后将其写回来。

但我必须说，我认为这会导致一种混乱的技能和工作方式的组合，我们将面临这样一个挑战，我认为我们已经遇到了这个问题，只是还没有公开谈论过。人们使用不同的工具，拥有每个工具的不同技能集，可能有不同的标准，有些东西没有标准，人们不得不忍受。这种非标准化带来的低效性，我们将在重新工作、速度变慢和成本增加上付出代价。因此，我预计最终我们需要写下更多关于如何做事的规范，让人类能够从大脑中提取这些知识并将其转化为标准的工作流程。

我认为在某个时候，我们还没有做到这一点，但在某个时候，我们将希望标准化人们在 Braze 内部使用 AI 的方式。现在，我对实验非常关注，为了使实验成功，你必须让人们自由发挥，不拘泥于标准。但我认为我们会看到这种做法的局限性，当有人抱怨“你的前端测试总是需要重建，你应该使用这个技能”或有人说“我不愿意知道如何做这十件事，模型应该为我做”。

我们将会有专注于代理工作流的团队，就像我们现在有专注于构建 CI 管道、测试环境、本地平台和开发环境的团队一样。我们需要同样的代理基础设施来支持编码。因此，我认为在 2026 年，我们将看到新的团队形成，新的责任分工，以及更多的标准化。

乔迪·贝利：

这次谈话对我来说非常有趣，我很享受这次对话，还可以继续聊下去。在我们结束之前，你还有什么想分享的吗？

乔纳森·海曼：

再说一次，我认为亲自参与其中是非常值得的，这有助于你理解工具集的变化，并能够适应软件开发生命周期和期望进入现代人工智能时代。回顾过去，我们回到去年年初到中期，我当时的想法是，“我们应该要求编写更多的测试，因为AI可以为你编写测试。” 或者如果你正在撰写产品需求文档 (PRD)，你应该包含竞争研究，因为使用Gemini深度研究查看市场上的竞争对手非常容易。我们可以这样说，你可以停止因时间和资源权衡而不得不削减的一些捷径。

这就是我过去的想法，但随着AI能为我们做什么以及我们如何改变流程的可能性，这一切已经发生了变化。从对个人的期望转向对整个团队的期望。我认为未来我们的团队都将拥有全天候工作的代理，处理错误报告，回答产品问题，帮助制定路线图。人们会入睡时，醒来时发现新功能是由AI构建的。对此我感到兴奋。要实现这样的业务转型，你需要在这个领域的知识。

所以，如果你还没有并行启动多个代理来处理不同的特性，我建议你这样做。如果你的手机主屏幕上没有AI应用程序，那就把它放上去。这样，你的第一反应就是打开它而不是去谷歌搜索，真正开始与AI互动。

总之，就是要动手尝试这些工具。我即将迎来第三个孩子，接下来几天我们将休产假，我计划开始玩OpenClaw。这是我想要在我的个人生活中更多地实验一下AI的可能性，以便我能参与其中并思考我能为公司带来什么。

乔迪·贝利：

太棒了，非常有用的建议。感谢你分享这些内容，感谢你参加我们的节目。

乔纳森·海曼：

同样感谢你们邀请我上播客。

对于正在收听的听众们，你们可以在领英上关注我。我会发布一些我们在Braze的AI项目的信息，以及关于规模和技术领域内令人兴奋的挑战的统计数据。欢迎在领英上关注我，我很乐意与你们交流。

乔迪·贝利：

乔迪·贝利，领英，Stack Overflow。

埃拉·梅：

感谢大家的参与，这一期就到这里。我是埃拉·梅，我是Stack Overflow的B2B编辑。如果你喜欢这次谈话，或者有希望我们讨论的话题或嘉宾，请随时通过[email protected]给我发邮件。感谢您的收听，我们下一期见。