Presentation: The Reinvention of the Dev Team

Dev团队的重构 - InfoQ

InfoQ 首页 演讲 Dev团队的重构

文化与方法

InfoQ 认证的AI辅助工程计划（在线，10月19日）：构建支撑AI的框架。

Dev团队的重构

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

53:09

概要

Hannah Foxwell分享了智能代理编码的兴起如何迫使工程领导者重新思考团队协作模式。她讨论了应对AI驱动速度的三个关键原则：构建值得开发的软件、以自动化安全优先于速度、通过通才"破碎梳子"技能组合和可持续的值班实践保留人文要素。

个人简介

拥有十年平台工程经验的Hannah Foxwell倡导技术演进中的人文价值。她对提升软件团队生活质量的工具、流程和实践充满探索精神，致力于打造高效工程组织。目前，她作为平台工程、安全和智能代理AI战略交叉点的独立顾问工作。

关于会议

软件正在改变世界。QCon伦敦通过促进开发者社区知识和创新的传播，赋能软件开发。作为以实践为导向的会议，QCon专为技术团队负责人、架构师、工程总监和项目经理设计，这些人群在各自团队中影响着创新进程。

INFOQ 事件

• 2026年10月8日，美国东部时间下午12点 当AI加速开发时，您的CI流水线能跟上吗？演讲者：Eric Metaj - Datadog软件交付产品市场经理，Rohin Chandra - Datadog CI/CD优化产品经理

• 2026年10月29日，美国东部时间下午1点 从Token到功能：为AI辅助工程构建成本归因架构 演讲者：Martin Reynolds - Harness现场首席技术官

演讲稿

Hannah Foxwell：我叫Hannah Foxwell。我今天要谈的是Dev团队的重构。让我们先从速度说起，因为作为职业群体，我们一直痴迷于速度。对于很多组织来说，建立可靠、响应迅速、高性能的工程团队是目标，但这类团队非常稀缺，我们总觉得自己落后。我们总觉得自己太慢，总是落后，速度很难获得。这些年我们有所进步。我参与的第一个软件开发团队，每年只发布两次。那是一个主机团队，情况有些不同，但确实是每年两次。后来我进入更现代的电商运营，如果每年能发布四次就算不错了。在我的职业生涯中，我们在速度这件事上确实进步了。

敏捷方法出现后，对很多人来说，我们甚至尝试每两周交付一次迭代的想法是颠覆性的。随后我们经历了云转型，基础设施按需提供，我们可以部署到按需环境，这又提升了速度层次。接着通过DevOps和持续交付，我们做得更好了。现在每天多次向产品和平台发布代码在业界并不罕见，我相信在座各位中很多人已经实现了这一目标。

然而，就在几年前，如果你参加这样的会议，人们会讨论开发者生产力，讨论开发者体验，讨论平台工程作为一种释放更多速度的方式。我觉得这种速度可能已经到来了。我们还不确定该如何应对它。这是 Steve Yegge 在宣布 Gastown（一个智能体编程编排平台）时提出的智能体编程的八个阶段。HelixML（他们正在构建一个智能体编排平台）公开了这种格式。对我来说，看到这些团队与他们的智能体舰队协同工作简直令人难以置信。我不知道你们是否已经以这种方式工作了。如果你们尝试过 Gastown 或尝试过与智能体舰队协作，请举手示意。对于大多数人来说，这仍然是理论。

这是一种令人不安的新现实：我不会再进入 IDE 通过提示来生成代码，而是通过规格说明和工单来驱动开发。智能体会分解任务的重量，智能体会交付软件，智能体会编写测试，智能体会部署到生产环境，智能体会进行监控。这为我们所有人描绘了一幅未来可能的景象。它可能比我们想象的来得更快。今年早些时候，流行的智能体编程平台 Cursor（最早的一批平台之一）出现了一个拐点。他们称之为编码的第三个时代，因为在 Cursor 本身中，智能体请求的数量已经超过了标签接受的数量。智能体驱动的开发已经成为 Cursor 中大部分工作内容。你可以从这张图表中看到这一变化发生得非常迅速。这是因为这些智能体的能力和可靠性持续提升。

我认为我们大多数人应该认真考虑尝试使用这项技术，因为为公司解锁软件价值的机会是巨大的。从高层到基层都会存在推动尝试这些技术的压力。通过实践探索，了解哪些方法有效、哪些无效，这确实是个非常好的想法。今天我将围绕三个核心观点展开讨论，这三个原则我认为无论使用何种技术或发展速度如何，都将始终成立。第一，我们必须构建真正有价值的东西。我们交付的软件必须能创造实际价值。第二，速度必须建立在安全性之上。第三，我希望这个观点显而易见——人员至关重要。

核心原则一：构建真正有价值的东西

构建有价值的东西究竟意味着什么？代码是实现方式，而不是目标本身。我们为解决问题提供方案，而这些方案需要软件来实现。要实现这一点，我们需要编写代码。代码是实现方式，而不是目标本身。我们交付的是解决问题的方案。我将反馈循环简化为这样一个过程：用户面临问题，通常会有产品经理负责深入理解这些问题。开发团队（通常在正常组织架构中由6到8人组成）随后设计解决方案并将其作为软件产品交付。用户使用后会反馈"是"或"否"，或者会说"等等，我要付款"。这个反馈循环持续进行。用户有需求，产品经理会筛选这些需求，开发人员则通过软件为这些问题提供解决方案。

对于很多开发团队来说，他们很少直接与用户沟通，因为产品经理会代表他们处理这些事务。开发团队的反馈循环通常集中在系统运行方式上，而不是用户表达的痛点。我认为这在很多我合作过的团队中是很常见的现象——开发人员并未直接参与用户沟通，没有与用户讨论他们的痛点。用户代理的替代者是界面，这个代理就是产品经理。在典型组织中，存在大量用户需求，需要进行筛选和优先级排序。我在产品管理领域工作过，始终非常重视工程团队。我不会用太多想法压垮他们，而是会过滤掉不成熟的想法，判断哪些是好主意、哪些是坏主意。我会严格优先排序，明确告诉他们应该专注的方向，因为开发人员的生产力需要专注。我相信这一点，并据此组织我的团队。专注于单一目标，杜绝干扰。

智能编码会带来怎样的变化？如果我们能将开发速度提升十倍？如果我们能显著增加产品推送的变更量和新功能数量？目前许多团队正在经历这样的情况。我看到的现象是产品端出现了压力。对于一些团队来说，产品路线图中没有足够的高质量工作来让那些释放了新速度的工程师保持忙碌。几年前我在播客中提到过："我有三年的产品路线图，我的团队永远不会遇到需求枯竭的问题。"但事实上，我如今在现实中看到了这种情况：由于开发团队释放了速度，他们缺乏足够高质量的工作来保持忙碌。这是我职业生涯中从未遇到过的新问题。你该怎么办？

你是否会对所有想法都说"是"？是否会对所有可能砸向产品的美好构想都接受？不，这通常不是好的产品策略。功能膨胀（Enshitification）是一种现象，这个词用来描述平台因功能过多而变得臃肿。它不再专注于单一功能，而是做很多事，甚至可能每件事都做得不好。这也不是正确的答案。我们不会仅仅构建所有能想到的微小功能，而从未与用户验证过这些想法。

这里有一个积极的一面：测试想法的成本大幅降低。过去制定产品路线图时，我们存在确认偏误。我们总是认为："这就是我们的路线图，这将为我们的业务带来成功，这将帮助我们的用户。"我们没有足够的工程能力去真正尝试和实验。我们只是说："我们先构建出来，如果构建出来了，用户自然会来。"而我认为更健康的产品交付方式是：先尝试，构建原型，与用户测试，迭代优化，然后再决定是否将其作为产品功能。因为一旦你决定将其作为产品功能，就必须永远支持它，直到你将其停用。我们看到的是"氛围编码产品经理"（vibe coding PM）的出现。

有谁和氛围编码产品经理合作过？有谁是氛围编码产品经理？如果你们是氛围编码产品经理，请举手示意。因为这是一种新型的产品经理。我非常喜欢这个角色。这不是那种会直接发布生产代码的产品经理，而是那种在将想法提交到产品之前，必须先进行测试的产品经理。这有多重要？这有多强大？这是我看到的令人兴奋的新实践：在将想法提交到产品之前先进行测试。如果原型超出氛围编码的范围，你可能需要让开发人员与产品经理配对构建这些原型。这样你就能在用户、产品和开发之间建立反馈循环，确保进入开发团队的所有工作都是经过验证和充分理解的。

你已经与用户进行了测试，而不仅仅是将产品推出后寄希望于最好的结果。最终这将帮助你打造出更好的产品。在现实世界中，我看到的另一个模式是前部署工程师（FDE）。谁听说过这个角色？前部署工程师是被嵌入到客户团队中的工程师，被授权解决客户的问题。这并不一定是指实施工程师或专业服务工程师。这是一种被授权的工程师，他们致力于尽可能缩短反馈循环。例如，这里有一个我们之前没有考虑到的现实场景，现在可以将其构建到产品中。最终你会得到一个长期功能路线图，以及一个非常短的反馈循环，通过小而战术性的改进来取悦客户。我非常喜欢这种模式，也很期待看到围绕这种模式组织如何演变。

另一个我看到的模式是产品工程师。产品工程师在为开发者提供软件工具的公司中表现得非常出色。基本上，所有在赞助领域之外的人都应该考虑产品工程师，因为产品工程师是被授权改进产品的工程师，因为他们本身就是用户。作为用户，他们知道自己需要什么，也知道自己不需要什么。我曾与incident.io团队交流，他们非常重视招聘产品工程师，而不仅仅是软件工程师。因为他们正在为自己构建产品，所以他们被授权做出决策。他们还有另一个优势，就是可以直接接触用户。他们不需要请求许可去询问用户对新功能的看法，他们与用户之间有非常开放的沟通渠道。

在座的人中，有些人可能会想：“不，我不希望与客户交流。请其他人来做这件事。”而另一些人则会说：“太棒了，让我来。”我想你们都会知道自己更倾向于哪一类，也会知道你的同事属于哪一类。如果你正在为像你这样的人构建产品，产品工程师确实是一个非常强大的模式，它能显著缩短反馈循环。我们真正讨论的是最终打造一个有价值的产品。我们希望为真实用户解决现实世界中的问题。

代理编码释放出的高速度所带来的反向压力，促使一些团队重新思考产品工程师与开发人员的比例可能是什么样子。过去我们行业标准的“两个披萨团队”（即六到八名开发人员加一名产品经理），现在一些团队正在尝试用两名开发人员配一名产品经理的微型团队结构。NBIM目前正在进行这项实验，我非常期待看到结果。在我们的一些AI项目中，开发速度现在比业务部门能够跟上的速度还要快。问题不在于开发能力，而在于缺乏清晰的规格说明、快速决策和紧密的反馈循环。他们正在通过这种实验将团队压缩到最基本的人数，因为产品经理无法让六到八名开发人员保持忙碌。我认为这是一项非常有趣的实验。

Andrew Ng 是一位企业家，也是人工智能领域颇具影响力的专家。他提出一个观点，认为实际情况恰恰相反，产品经理与开发者的比例应该是 2:1。你能想象吗？因为那位开发者，你假设他拥有大量代理，能够同时协调多个产品线的开发。这正是公司可能正在尝试的领域。在软件开发领域工作，确实是一个令人着迷的疯狂时期，这是一个真正的变革时期。我并不想为任何一种观点辩护，而是想向你展示其他人正在尝试的实验，这样当你看到这种解锁速度时，你将有一些想法和灵感，知道接下来可以尝试什么。我曾与一家咨询公司聊过，因为这是一个非常有趣的领域，可以讨论智能代理编码。

他们向客户出售开发人员的时间。这种变化如何影响他们的世界？有趣的是，他们为所有合作公司提供服务，目前涉及 200 家公司。我认为他们向这些公司部署了大约 3000 名开发人员。到目前为止，他们只看到两到三家公司减少了团队规模，其余公司都期待更高的产出。我认为，如果将这种对更高产出的期望再进一步推演，也许你会开始思考，团队负责的领域可能需要扩大，因为当前领域内合格的工作机会可能不足以让他们保持忙碌。我认为这将非常令人着迷。

我也想为设计和用户体验（UX）发声。在软件开发快速且高效的世界中，进行用户研究、以数据驱动和以用户为中心，将成为一种差异化优势。你是否会用你构建的产品让用户体验到惊喜？我认为用户体验设计的技艺远未消亡，事实上，它比以往任何时候都更加重要。挑战在于将设计流程加速到软件开发的速度。挑战在于确保我们有经过深思熟虑的好设计，为用户研究和可用性测试留出时间。我看到一些组织采取的做法并不奏效，这些做法可能随着时间推移逐渐被淘汰，其中一种我称之为“上线即切换”（ship and switch）。所谓“上线即切换”，基本上就是我们有太多待办事项，以至于产品或功能的第一个迭代版本就成为最终版本。

我们从不回头改进它，也从不向用户征求意见。就像这样：一个框被勾选了，我们就继续处理下一件事。我们发布它，切换上下文，去解决另一个问题。实际上，最好的产品和最好的产品经理都知道，在发布产品后，你必须继续与用户合作。这是正确的选择吗？它对你来说是否更有价值？它的可用性如何？你不会发布产品后就切换上下文。我认识很多团队已经持续多年以这种方式运作。这种习惯非常难以戒除。另外两个问题显而易见，但对每一个客户请求和每一个想法都说“是”，也不会让你的产品取得巨大成功。然后是 HIPPO（最高薪酬者的意见），这种以最高薪酬者意见为优先的决策方式早就应该被淘汰了，但目前在很多组织中仍然普遍存在。让我们停止这种 HIPPO 优先级决策方式。让我们真正以数据驱动和用户为中心，确保我们正在构建值得构建的东西。

我保留什么？我摒弃什么？在代理软件开发的新世界中，我正在尝试什么？我保留的是能够自主决策、无需请示即可帮助用户的赋能产品团队。我保留的是与真实用户、真实人类建立的快速反馈循环，我正在开展可用性研究和用户体验研究，因为这些因素将使我的产品区别于其他所有基于情绪编码的平台。我摒弃的是六到八人的两人披萨团队，我多次观察到这种比例在许多企业中并不一定是成功的关键。我们在酒吧讨论时提出，这种团队更像是西班牙小食团队（tapas team），可能更像是几道小菜的组合。是的，西班牙小食团队或许会成为一种趋势。我同时摒弃的是为期六个月的产品路线图，不是因为规划没有价值，而是因为在六个月后确定要构建什么已经不再是一个有意义的练习。

如果你想构建这样的东西，我们现在就要想办法实现。如何并行处理？如何快速完成？如果这件事足够重要，就以你能实现的速度尽快完成。我想要尝试的新事物包括：部署在前线的工程师，这种工程师被赋权并与客户并肩解决问题。我绝对希望将反馈循环缩短到几乎为零。让我们去解决现实世界中的问题，让我们高度关注客户。产品工程师绝对不可或缺，一个对产品中应包含和不应包含的内容有明确主张的工程师将是非常宝贵的资产。你并不希望被那些只想从待办事项列表中挑选任务的队友包围，因为如果工程师能从待办事项列表中挑选任务，那么在未来的世界里，代理系统同样也能做到这一点。我肯定要在产品开发前进行原型设计。我肯定希望尝试比我们目前习惯的更小的团队规模。更小的团队规模或更广泛的团队责任领域，这样可以避免产生反向压力，避免最终构建出不值得构建的东西。

锚点 2 - 速度需要安全性

现在我将进入我的第二个锚点，这个锚点是：速度需要安全性。在通往生产环境的道路上，我们需要验证所构建的软件确实能实现预期功能，且没有破坏任何关键部分。这些都是基本要求。在许多组织中，通往生产环境的流程可能包含手动步骤，测试覆盖率可能存在缺口，这使得在提高发布速度时变得非常危险，因为如果你无法以这种速度发布，最终会在通往生产环境的道路上堆积大量未处理的工作。如果代码生成速度超过了你的流水线处理能力和将代码交付给用户的能力，那么最终会在某个环节堆积，这将在其他地方产生反向压力。最终，我们得到的结论是：开发者能够产出的代码远超下游流程的处理能力。

高置信度需要测试，而我认为高速度需要自动化。这两者缺一不可。你需要通过自动化测试实现极快的速度和良好的覆盖率。我认为，当人们开始适应我们当前解锁的这种速度时，组织中最早暴露出来的痛点可能就是这些。请思考一下，你现在可以做些什么来逐步弥补这些差距，让通往生产的路径尽可能顺畅、自动化且快速。我非常喜欢这篇文章，它来自AWS，讲述了他们通过采用智能编码实践，使开发团队的吞吐量提升了10倍。总结来说，他们不得不彻底重新思考测试、部署和协作的实践方式。他们无法仅仅将AI的速度附加到当前的工作流程上，而是必须重新设计通往生产的路径以实现速度的提升。

当我们可能发现自己拥有一个已经耗尽产品负责人提供的待办事项和功能工作的开发团队时，我会想：我们该如何利用这额外的容量呢？让我们去解决这个问题吧。让我们去解决吞吐量的问题。确保在需要的时候，我们能够释放出这种速度。

另一个引起我注意的是摩根大通如何利用AI代理驱动其持续组件测试。同样，我会认为这真是一个巧合。我一直在强调持续测试的必要性，它必须足够快。现在我们拥有了可以为你编写测试的工具。我认为他们将这个问题作为首要任务来处理非常有趣，但其实这非常以人为本。Michele Willis表示，几乎没有任何开发人员喜欢测试。测试是工作中令人厌烦的部分。开发人员希望花时间解决问题和理解代码。测试是一项繁琐的工作。很好，让我们把它交给代理去做吧。这是人类并不喜欢的工作，为什么不交给AI代理去做呢？通过这样做，可以提升你所需的质量门禁自动化水平，从而实现你想要的生产路径速度。

我相信另一个真实的观点是，第2天实际运行软件的成本，永远会比第1天构建它的成本更高。你可以构建某样东西，但长期来看，维护、支持、修补和改进它所需的时间总是更多。我也坚信，尽管用户大多数时候不会明确要求，但他们其实非常关心安全性和可靠性。目前，这些话题正频繁出现在主流新闻中。亚马逊的可靠性问题曾登上新闻，我认为这在许多其他会议中也讨论过。当网站宕机时，这已成为主流新闻话题。上周Claude也发生了宕机事件。目前GitHub的可靠性数据表现尤其糟糕。可靠性是值得新闻报道的话题，它会损害你的产品声誉，因此投入其中至关重要。

我认为这是根本性的。你不能以牺牲可靠性为代价来追求速度，也不能以牺牲安全性为代价来追求速度，尽管显然，如果你是Moltbook用户，或者已经将OpenClaw连接到Moltbook，你可能并不在意这些。良好的安全性通常是隐形的，直到它失效的那一刻才会被注意到，因此投资于一个安全的基础架构至关重要。你的用户永远不会明确告诉你这些要求，他们只是会一直期望你做到这些。他们期望你保护他们的数据。在我们想要释放的这种速度之下，我们不能以牺牲可靠性和安全性为代价来实现它。

我们也不希望新功能或未完成的工作过多地打扰用户。渐进式交付，例如功能标志、A/B测试、蓝绿部署，是我们在快速进行大量变更时，依然能够营造出可靠服务感知的另一种方式。我们已经有一些实践方法可以帮助我们理解这些问题。《SRE书》向我们介绍了SLI（服务级别指标）、以用户为中心的服务级别指标等概念。SLO（服务等级目标）是我们对用户可靠性做出的承诺，而错误预算（error budgets）则定义了可接受的失败程度。我特别想和大家讨论一个工具，那就是错误预算政策（error budget policy）。错误预算政策比以往任何时候都更加重要，因为错误预算政策会告诉你，当组织未能履行承诺时，应该采取什么行动，以及当未达到SLO时会发生什么。

如果未能实现可靠性承诺，你们会采取哪些不同的措施？我认为，人们很容易认为速度是唯一的目标。如果产品不可靠，如果产品不安全，你们将因此在商业上受到损害。其他人会接手并做得更好，为你的客户提供更优质的服务。错误预算政策会明确写出SLO是什么，以及在违反SLO时应该采取什么行动。也许你们会减缓发布节奏，也许需要在可靠性上进行投资，也许需要在系统弹性上进行投资，但这是一个书面文件，它明确表示：这是我们对用户做出的承诺，我们绝不会违背这个承诺。如果目前你们还没有错误预算政策，现在可能是制定一个的时候了。

因为推动更多发布、更多代码和更多变更进入生产环境的一个意想不到的后果，可能是可靠性下降。测量它，并与团队达成一致，如果发生这种情况，你们将采取什么行动。如果你们以过快的速度推动了过多的变更，导致可靠性下降到用户无法容忍的程度，那么必须采取应对措施。

我认为一些模式将比以往任何时候都更加重要和具有影响力，例如构建内部开发平台和站点可靠性工程（SRE），正如我刚才所说。平台工程师提供的是一种“铺设好的道路”，他们可以帮助你更顺畅地将产品推向生产环境。他们可以按需提供开发环境，确保默认情况下一切都是安全的，让安全成为最简单的选择，这样开发团队就无需再为此操心。SRE团队也是如此。当谷歌发布《SRE书》时，那已经是多年前的事了，我当时认为将站点可靠性工程单独设为一个独立组织的做法略显反模式。现在我重新思考这个问题，认为实际上如果有一个内部咨询职能，由专家负责构建弹性系统，这可能会为很多团队带来巨大价值，尤其是那些因变更速度加快而导致可靠性下降的团队。

我正在重新审视这个想法。我并不是要固执己见地声称这就是正确的方式，而是希望重新思考这个想法，我认为随着团队开始加速前进，这可能成为一个非常有趣的模式。一个内部咨询组织，一个能够提供专业建议的SRE组织，帮助确保你的可靠性不会受到影响。我认为SRE团队可能会迎来复兴。

这里一个有趣的问题是，比例是多少？我们的团队构成是怎样的？因为目前我们看到的情况是，即使你有SRE团队，他们的人数也远远少于开发人员。如果你有一个平台团队，他们的人数同样远远少于开发人员。如果有安全团队，情况更糟，人数更少。实际上，我认为这些职能能够释放开发人员的速度。我们可能会发现，为了取得成功，需要不同的比例。我准备挑战这个现状。我准备提出，实际上，一个平台组织能够通过大量AI代理的协作，让开发人员安全且高效地将大量变更快速部署到生产环境，这将为组织带来巨大价值。这正是一个巨大的优势，就在那里被释放出来。我们目前在组织中习惯的比例很可能会发生变化。

我认为这是件好事。另一个可能导致生产路径上产生摩擦的因素是技术债务。再次强调，正如我之前所说，使用代理工具来提升测试覆盖率，就能解决这个问题。代理工具在迁移方面也非常出色，能够帮助你摆脱老旧的、过时的平台，淘汰已到生命周期末期的平台，重构代码库。这些问题今天就存在，但如果能利用这些代理工具和流程的速度与迭代能力，它们就不必成为明天的问题。我还要说，如果你最终陷入这样的处境：产品经理无法为那些高素质的团队争取到足够的工作量，那么请记住，你们过去那个工程积压的待办事项清单，那个需要你不断争取时间和关注的技术债务清单，现在是时候彻底清空它了。因为现在正是关键时刻，尤其是这些智能代理编码平台成本如此低廉。这种状况可能不会永远持续下去。现在正是解决所有这些工程积压和技术债务的绝佳时机，这些你一直难以优先处理的问题。

我的第二个核心原则是速度需要安全，我保留什么？我淘汰什么？我在尝试什么？我保留错误预算政策，因为我在乎可靠性，也因为我深知用户同样在乎可靠性。我坚决保留渐进式交付，如果目前尚未实施，那我正在投入其中。我正在逐步发布新功能，通过在生产环境进行测试，确保功能完善后再面向所有用户。我坚决保留内部平台，这些平台帮助构建一条明确、安全通往生产的道路。我淘汰所有手动操作，任何涉及手动测试、手动发布阶段或任何手动操作的生产路径环节。在新世界中，这些没有容身之地，因为它们太慢了。这就是积压发生的地方。如果你审视自己的生产路径，发现其中存在手动步骤，请立即着手解决，否则这些将成为未来的瓶颈。我正在尝试的事情包括：我希望利用AI提升测试覆盖率，我希望利用AI解决技术债务积压问题。我确实考虑重新引入SRE团队作为内部咨询职能，帮助团队提升可靠性。

核心原则3 - 人员至关重要

现在我们来到第三个核心原则，人员至关重要。这其实显而易见，我们希望从事有成就感的工作，希望去解决有趣的问题。不幸的是，审查AI代理生成的代码并不有趣。当我们思考未来以及我们希望未来角色如何演变时，如何调和这种矛盾？审查AI生成的代码本质上并不有趣，尤其是当这些代码以惊人的速度大量产生时。我非常认同Joseph Ruscio关于“只写不读代码”的文章。他的假设是，并非所有代码最终都会被人类阅读。目前，大多数代码确实被人类阅读，几乎所有代码都是如此。除非你是那种“氛围编码”的人，几乎所有代码最终都会被人类阅读。他的观点是，这种现状即将发生转变。

未来大多数代码将直接运行，而从未被人类阅读。如果我们明确将此设为开发目标，那么我们的软件开发生命周期需要如何设计，才能确保这不会变成灾难？我认为这是一个非常有趣的思维实验。另一个让我感兴趣的是同行评审的左移趋势。许多团队目前采用的系统是：某人编写代码后，由另一人评审其拉取请求，再将其合并到产品中。这种同行评审是一种质量门禁，曾发挥重要作用。我看到一些团队的做法是将评审环节左移到代码编写之前。同行评审，对构建内容和构建方式提供第二视角依然至关重要。他们所做的改变是将评审环节提前到代码编写之前。

这种提前体现在对需求文档的评审、对测试用例的评审、对测试策略的评审、对架构设计的评审。依然是两个头脑的碰撞，共同判断：我们正在做正确的事吗？我们以正确的方式在做事吗？这不再是审查拉取请求中的代码行数。我认为这也是一个非常有趣的新兴模式。

另一个我们都知道的事实是，当你拿着 pager（值班电话）时，支持一个脆弱的服务绝对不是一件愉快的事情。要支持一个生产环境中的服务，必须有最低限度的人数，因为没有人愿意整天、每天都要拿着 pager。你不可能全天候、每天都在值班。当你把这视为一个限制条件时，支持一个服务所需的最小可行团队规模是多少？假设你有一个人是主要值班人员，另一个人是次要值班人员作为后备。如果你们说，也许每四周中有一周作为主要值班，另一周作为次要值班，这基本上意味着你仍然有 50% 的时间处于值班状态，而对很多人来说，这种状态仍然难以持续。

在考虑减少团队规模之前，我们必须认真思考如何支持生产环境中的服务。一个团队只有一名开发者一直拿着 pager 是完全不现实且不可持续的。这也是为什么我认为 SRE（站点可靠性工程）团队作为独立组织可能会重新回归，因为在 Google 最初的 SRE 团队形式中，他们愿意为那些符合他们设定的标准和可靠性期望的服务持有 pager。在服务达到他们的标准之前，他们不会支持该服务。我认为这可能是重新引入 SRE 团队的另一个潜在优势。正如我之前所说，支持一个生产环境中的服务所需的最小可行人力是多少？去年我在演讲中展示过一张关于“最小可行人力”的幻灯片，当时我正在谈论代理（agents）。

我一直在反复强调这一点。我们不能把团队规模减少到极端，以至于工作变得完全不可持续，变成单点故障，以至于无法休假。这显然不可行。要让工作变得可持续，所需的最小可行人力是多少？我认为这是一个非常重要的问题，值得我们自问。

当我们讨论团队和协作方式时，我认为很多人会默认我们熟悉的敏捷仪式，比如每日站会、冲刺计划、需求梳理。我不确定这些方法是否仍然适用。我首先感受到的是，目前两周的冲刺周期太长了，大多数团队迭代速度更快，处理待办事项的速度也更快。如果我们从这一点出发，假设我认为两周的冲刺周期确实太长了，那么正确的迭代周期应该是什么？是一周？还是一天？我们希望多频繁地进行这样的决策？需要哪些人参与其中？我们如何通过实验来调整团队协作的实践方式，以避免无意中引入过于繁重的流程，这些流程远比实际需要的更复杂？

因为不再需要进行规划和重新规划。我想再谈另一个话题，即我们在这个职业中需要掌握的技能。如果我们假设代理将变得如此擅长编码，以至于它们会为我们编写大部分代码，而这种“只写不读”的代码（从不被人类阅读）可能对某些团队来说会成为现实，那么作为软件开发人员的我们，需要哪些技能呢？去年在QCon大会上，Sophie Weston分享了她成为首席工程师的旅程，并提出了“破损的梳子”这一概念。“破损的梳子”意味着，我们不再需要像T型或Pi型人才那样，只专注于一两个领域，而是需要在软件开发的许多不同领域中发展广泛的知识。

然后，我们需要在少数几个领域深入钻研。我非常喜欢“破损的梳子”这个比喻，因为我认为，未来在我们这个职业中，专注于单一领域的专家可能不会带来太大优势。我认为，发展更广泛的技能，能够解决不同范围的问题，将为我们带来成功。我非常认同“破损的梳子”这一理念。如果在座的各位中有管理者，当你们回到团队时，值得思考如何通过让团队成员接触不同领域的专长、挑战他们学习新事物来培养团队的广度。正如我在这次演讲中提到的，许多组织都需要愿意与客户并肩工作的工程师，以及具备产品管理技能和产品思维能力的工程师。

这是你可以让团队深入探索的一个领域。同时，发布工程领域对可靠性专业知识的需求也将增加。这些都是曾经只是开发者、现在需要从交付编码任务的待办事项清单中扩展技能的工程师可能开始多样化发展的领域。我希望每个人都思考这一点，无论是对自己还是对身边的人，通过多样化技能，让自己在代理编码时代成为更具杀伤力的“武器”。

围绕我的第三个锚点，我保留什么？我丢弃什么？我在尝试什么？我绝对会保留可持续的值班实践。我不会让一个人全天候或甚至50%的时间处于值班状态。我会找到一种方法，让团队在不这样做也能取得成功。我之前提到过这一点，现在再次强调。错误预算政策明确了当服务可用性受到影响时应该采取的行动。我会进行职业规划，因为我们已经在做了，对吧？我会进行职业规划，但针对当下的现实，而不是过去的现实。我会重新思考所有职业框架。我会鼓励每个人成为“破损的梳子”——一个拥有某些深度专长的通才。我绝对会摒弃繁重的规划流程，因为它们几乎没有价值。

待办事项的整理、优化，所有这些工作。你可能会对所有事项都说“是”，但此时待办事项清单上的内容重要性反而会超过你对某些事项说“是”或“否”的决策。两周冲刺周期，我觉得现在时间太长了。我认为这种标准应该被摒弃。我也反对强制代码审查。同行评审很重要，但我认为对每一行代码都进行强制审查并不是可持续的实践，这在软件开发领域对人类来说并不愉快。这可能是个有争议的说法，但我认为这种方式不可持续，而且让人感到痛苦。没人会想做这样的工作。我正在尝试将同行评审提前到代码编写之前，通过讨论你对解决方案的思考方式、设计思路，以及如果你正在进行基于规格的开发，讨论你的规格说明。

我肯定会采用基于规格的开发方法。决定你希望系统如何运作，能为你的代理（agent）带来更大的成功机会。我会鼓励每个人成为“破损的梳子”（broken comb）。我可能不会停止谈论这个概念，因为我认为我们所有人都希望为在这个新时代中与这些代理式编码平台合作的职业生涯做好准备。作为人类，我们如何才能取得成功？我们需要更多专业领域的深耕。我们需要多样化技能，并且现在就要开始。

我将回到第一个核心原则：构建值得构建的东西。我想讲述我最近构建的一款产品的经历，因为现在构建产品比以往任何时候都更容易。这就是BIMP的故事。BIMP代表基础镜像管理平台（Base Image Management Platform），因为它是一个为你管理容器镜像的平台。这是一个我非常了解的问题，源于我在平台工程和安全领域的背景。我注意到，目前还没有人尝试构建一个完整的基础镜像管理解决方案。我们决定这么做。两个人花了两周时间构建一个平台来解决用户需求。是的，我们很快就完成了所有工作。我们给自己设定了两周时间，第一天早上我们就坐下来，问自己：“今天的目标是什么？”到中午时分，我们已经超额完成了目标。

我们决定在午餐时间召开另一次规划会议，讨论晚上要做什么。这种模式持续下去，直到我们摒弃了“无情优先级排序”的做法，对自身提出了更高的要求。我们不再试图每天构建一两个功能，而是在早上进行非常密集的规划会议，规划四到五个功能，然后立即投入开发。即使这样，我们通常在当天结束前就能完成所有任务。这与两周冲刺周期完全不同，那时我们经常熬夜工作。现在我们不断问自己：“接下来要构建什么？”“接下来要构建什么？”“哪些是锦上添花的功能？”“用户真正需要什么？”在之前担任产品经理的工作中，我绝不会在第一周就决定开发一些管理仪表板。

绝不。我们当时之所以这么做，是因为平台在功能上已经能够运行，而我们想要获得更高级别的可见性。我们非常迅速地感受到了这种反向压力带来的所有痛苦。我成功在两周内将产品上线。通过Cursor的智能代理模式重构这段代码花费了数小时。文档是通过AI自动生成的，构建文档仅用了几分钟。你可以扫描这个二维码，去我们的官网看看。我想说的是，当前的开发过程非常有趣。如果你去官网看看，会发现有一个3D飞艇在页面上空翱翔。在MVP阶段绝不应该出现3D飞艇，但我们的产品却包含了它，因为开发本身是件有趣的事。我们没有停止开发，而是持续前进。

这对你来说是个独家消息，因为我们尚未正式发布产品。当这段内容在线上直播时，我们就会发布。以AI速度构建产品的体验令人收获颇丰。我经历了所有这些问题，甚至更多，但这让我对未来可能构建的项目更加雄心勃勃。还有一点我想强调：我们都在一条探索之路上。并非每个人都能达到第八级，指挥自主代理舰队的水平。我们中的许多人仍会通过提示来寻找解决方案。即使如此，这也将释放速度。我认为我们都在探索之路上。我认为这不一定是终点。我认为针对当前的问题领域和具体任务，存在正确的解决方法论。

关于三个锚点的最后思考

最后送给大家一个思考。开发从未如此简单或如此有趣。我们正在经历巨大的变革。今天我不想就未来会呈现怎样的图景给出明确观点。但希望我能让大家对解锁这种速度后可能尝试的方向，以及当这种速度开始为团队带来新问题时的应对方式，产生一些启发。最重要的是，我希望我们都能对未来自己的角色充满信心。我希望我们都能感受到，在这个代理世界中，我们拥有自己的位置。我希望我们都能准备好拥抱这种变化。

查看更多带字幕的演讲

录制时间：

2026年10月7日

演讲者：

• Hannah Foxwell

#### 相关赞助商

• AI的物理限制：AI如何重塑数据中心

#### 相关赞助商

PostgreSQL面向时序数据的扩展：无需牺牲性能即可处理海量时序数据。了解Tiger Data如何实现高速数据摄入、快速查询和可扩展存储。了解更多。

#### 本内容属于“文化与方法”主题

##### 相关主题：

• 开发

• 架构与设计

• 文化与方法

• QCon伦敦2026

• 平台工程

• 产品管理

• QCon软件开发大会

• 开发者体验

• 字幕

• 人工智能

• DevOps

• 网站可靠性工程

• 敏捷开发

• 架构

• InfoQ

• 相关编辑

• InfoQ热门文章 Uber Eats重建搜索管道将端到端延迟降低50% 从可复用到可再生：重新思考共享UI组件库 人工智能时代如何培养软件工程技能 未来网络安全：硬件内存安全、自动化治理与后量子密码学 Pizza Bot：面向后台AI代理的开源收件箱 高通在Snapdragon X2上推出Linux预览版以加速上游ARM笔记本电脑开发