安德鲁·菲列夫（Andrew Filev）是Zencoder的创始人兼首席执行官。他通过创立Wrike（拥有20,000多个客户，出售价格为22.5亿美元）改变了协作工作管理的格局，并被福布斯和纽约时报报道，他对人工智能和创新技术的热情继续塑造着工作的未来。
十倍工程师已经成为硅谷的神话，拥有数十年的历史。独自工作的天才，戴着耳机，以超人的速度生产优雅的代码。我们一直在争论他们是否存在，争论如何聘用他们，并对任何声称自己是十倍工程师的人感到怨恨。但是在通往以人工智能为首的未来途中发生了一件有趣的事情：十倍工程师成为了现实。他们只是与我们想象的完全不同。OpenAI最近分享了一个三人团队如何使用Codex提交1500个拉取请求和大约一百万行代码，而无需手动编写一行代码。三个工程师，零手写代码。一个由数百名内部用户使用的生产产品。这不是十倍的生产力，而是更接近于100倍。使其成为可能的技能不是输入速度更快或知道更多算法，而是构建使人工智能代理高效的系统：工作流程、防护栏、验证循环、代理插入和人类审查的接口。我相信这是工程组织中新出现的关键功能。我称之为人工智能编排工程。三个学科走进站立会议如果你仔细观察人工智能编排工程师实际做什么，你会认识到三个熟悉的学科融合成一个。最明显的成分是DevOps。DevOps集中了部署管道。一个团队配置了每个工程师在提交代码时使用的CI/CD工作流程。人工智能编排工程做同样的事情，但适用于代理工作流程。它定义了如何将任务分配给代理，如何验证输出，如何重试和回退。它是代理运行的共享基础设施。然后是架构，它与DevOps的重叠比你想象的要多。架构师决定哪些接口被锁定，哪些模式被强制执行，哪些边界不能被跨越。在代理优先的世界中，这更为重要。代理需要干净、文档齐全的代码库和清晰的合同。人工智能编排工程师定义这些约束，不仅仅是为了人类的可读性，也是为了代理的理解。一个混乱的仓库不再只是技术债务，它是每个接触它的代理的生产力上限。最不被理解的部分是人工智能特有的层。提示工程、上下文管理、模型选择、代理配置。今天，大多数工程师以分散的、任务为导向的方式执行这些操作。每个人都为自己找到自己的提示风格、代理设置和变通方法。人工智能编排工程师集中了这些工作。他们建立共享的剧本、可重用的配置、跨模型和使用场景的组织知识，关于什么有效、什么无效。单独来看，这三个功能在今天的大多数工程组织中都存在。论点是，将它们集中到一个单一的角色中，会产生质的变化。剧组负责人隐喻电影导演不操作相机、不出演场景、不编辑镜头。但每一帧都反映了他们的决定。他们选择镜头构图、节奏、基调。他们决定何时推进、 何时拉远。他们设置环境（灯光、布景、阻挡），以便每个演员在一个连贯的愿景中发挥出最佳水平。剧组很有才华，但没有协调，他们会陷入混乱，永远无法交付成果。人工智能编排工程按照同样的方式运作。代理是有能力的，模型是强大的。但是，没有人设计一个协调它们的系统，定义约束，建立反馈循环，构建工作流程，你就会得到我们都经历过的结果：不一致的输出、浪费的计算资源、代理工作不一致、工程师花费更多时间修复人工智能生成的代码，而不是自己编写代码。导演让电影变得比其各部分之和更伟大。人工智能编排工程师为代理舰队做同样的事情。为什么大多数组织投资不足我在整个行业中看到的情况是：公司在人工智能工具上投入了大量资金，但在周围的系统上投入的资金还不够。工程师可以使用Copilot、Claude、Codex等工具。他们个人进行实验。有些人成为高级用户。大多数人停留在“花哨的自动补全”阶段。研究报告的20%的生产力提升，这是工具级别的采用，而不是系统级别的思考的症状。那些突破的组织，那些报告2倍或更高的生产力的组织，有一个共同点。他们集中了编排工作。某个人（或某个团队）拥有代理工作流程、仓库准备、验证基础设施、每个代理可以访问的共享上下文的所有权。这个角色实际上是什么样子人工智能编排工程师的日常工作可能包括： 设计代理工作流程：定义如何将功能请求转化为规范、计划、并行代理任务、审查和合并代码。 构建验证基础设施：自动化测试、linting规则、安全扫描和评估框架，代理必须通过这些才能将其工作合并到主分支中。 维护仓库健康状况以供代理使用：文档、清晰的接口、依赖项管理和代码库简化，所有这些都是针对代理理解而优化的，而不仅仅是人类的可读性。 集中提示和上下文策略：共享系统提示、检索管道、模型路由决策和配置模板，整个团队都使用这些。 监控和改进代理性能：跟踪成功率、故障模式、每任务成本和合并时间，整个代理舰队都在使用这些数据来调整系统。 这个人处于平台工程、软件架构和人工智能专业知识的交叉点。他们不编写功能代码。他们构建使功能交付快速、可靠和可扩展的系统。历史模式在云计算的早期，部署是每个工程师的副业。每个团队都有自己的脚本、服务器配置和将代码部署到生产环境的方法。DevOps出现了，以集中这一工作，平台工程演变为将其构建为共享的自助服务基础设施。人工智能正在遵循相同的轨迹。目前，代理的使用是每个工程师的副业。每个人都有自己的提示风格、工具偏好和对人工智能何时有帮助、 何时无帮助的精神模型。集中这一工作的组织，将代理使用视为基础设施，而不是个人实验，将会像拥有成熟的DevOps实践的组织超越那些没有DevOps实践的组织一样领先。区别在于速度。DevOps转型花了十年。人工智能转型可能只需要几个季度，尽管我会承认，这个预测假设组织比平常更快地认识到这种模式。前进之路如果你是一名工程领导者，我建议你这样做，尽管你的里程可能会根据你的团队已经取得的进步而有所不同。 找出谁已经在非正式地做这项工作。每个组织都有人已经弄清楚了代理工作流程，其他工程师会去寻求他们关于提示或工具设置的建议。这个人就是你的原型人工智能编排工程师。 使其正式化。给这个职能一个名称、一个使命和资源。不要让它作为某人的“真正”工作的副业。 从仓库准备开始。确保在投资复杂的代理工作流程之前，代码库是代理可以实际导航的东西。清晰的接口、良好的文档、综合测试和简化的架构。 集中有效的内容。有人发现了一种提示策略或工作流模式，可以显著提高代理输出时，捕获它。将其作为整个团队的默认设置，而不是锁在某个人的脑海中。 在系统级别衡量。不要仅仅跟踪个别工具的使用情况。跟踪代理完成的任务数量、审查和重做率、瓶颈所在的位置。 新的10倍十倍工程师的神话一直是关于个人英雄主义的。一个人，通过纯粹的天才和咖啡因，超越了所有人。人工智能时代十倍工程师的现实是关于系统思维的。那个让每个其他工程师（和每个代理）更高效的人，通过构建正确的基础设施、正确的工作流程、正确的约束。他们不编写十倍的代码。他们构建能够编写代码的系统。我不确定这个角色会不会完全按照我在这里描述的方式成型。但我相当确定，弄清楚编排层（无论他们最终如何称呼它）的组织，将会真正实现其他人只是谈论的生产力提升。
我最近写了一篇关于 AI 疲劳的文章，认为工程师们正在经历的不是慢性病，而是训练后的疼痛。突破它，适应它，变得更强壮。这是一个很好的想法，但故事还没有结束，而且它很快变得更加明显。工程团队现在面临的真正风险不是倦怠，而是停滞不前。新的分歧几乎每个高级工程师现在都在使用 AI。Copilot、Claude、Cursor、Codex，你可以随便说出它们的名字。这个部分已经确定。如果你是工程组织的领导者，你可能会看到广泛的采用率，并且对此感到满意。但是你不应该这样觉得。采用率是无意义的。重要的是在其下面发生的分歧。你的团队正在悄悄地分裂成两个群体。有一些工程师获得了生产力提升并稳定下来，还有一些工程师每周都在不断推进。新的工作流程、新代理配置、新方法来分解问题让 AI 处理。这两组人都出现在你的仪表板上，显示为“AI 采用者”。但是其中一个处于进步的训练计划中。另一个在第一次感觉舒适的重量后就停止了。六个月前，这两个群体之间的差距几乎看不出来。现在，对于任何注意到的人来说，这是显而易见的。在另六个月内，这将成为结构性的。什么是高原停滞不前的工程师在传统意义上没有做错任何事情。他们是有能力的。他们交付工作。他们使用代理来完成简单的任务，并在之后进行清理。他们可能获得了 20-30% 的生产力提升，并认为这是足够的。问题在于，旁边的工程师没有停止在那里。那个工程师现在正在运行多代理工作流程，改进验证循环，将整个功能分解为 AI 可执行的块，在架构级别进行审查，而不是逐行审查，并以 2-3 倍于之前的速度交付工作。这不是因为他们更有才华，而是因为他们继续训练，而其他人则休息了一个季度。这不是关于 AI 的热情或成为早期采用者。这是关于持续适应与一次性调整。两种方法之间的差异正在变得无法忽视。竞争压力是真实的，并且正在加速如果你的团队有足够的时间来适应自己的节奏，高原问题将是一个绩效管理问题。令人讨厌，但可以管理。但是，如果你看看软件行业的更广泛情况，很可能你没有这种奢侈的条件。软件行业在很大程度上是为了帮助人类完成数字工作而创建的：帮助支持代理看到传入的案例，跟踪对客户的回应，管理工作流程。现在，AI 代理正在取代整个工作流程，并随之破坏了底层的 SaaS 平台。此外，随着 AI变得更加强大，你的客户开始问一个问题：“我们还需要购买这个，还是可以自己构建？”AI已经开始缩小“购买”和“构建”之间的壁垒，适用范围正在扩大。保护你收入的粘性每个季度都在削弱。你的停滞不前的工程师正在以一个竞争环境为基准来运作，这个环境已经不复存在。那句话改变了一切我已经多次听到这个说法，从产品经理那里，他们卷起袖子并使用了特定的功能，从工程领导者那里，他们重新设计了失败的架构，在不同的公司，在不同的背景下：“使用我的代理来迭代这个功能比使用那个工程师更容易。”第一次听到时，我以为这是夸张的说法。第三次，我意识到这是一个领先指标。在我看来，有些工程师将在这个新世界中茁壮成长，并成为 AI 能力的“倍增器”。要做到这一点，他们需要在两个领域都很强大，两者都可以通过足够的内在动机和智力好奇心来自我发展： 他们与利益相关者（产品经理、工程经理等）“保持同步”。他们知道什么是好的样子，所以你不需要向他们详细解释。如果他们产生的误解数量与你的编码代理一样多，代理将永远赢得这场战斗。它始终可用，24/7，不疲劳。 他们不断改进自己的 AI 设置，所以当你把事情交给他们时，你知道它不仅会做得好（见上面的要点），还会足够快地跟上新的市场节奏。 这是一个领导力问题，而不是个人问题将其框定为个人工程师的责任很诱人。“跟上或被甩在后面。”但是，如果你领导一个工程组织，这种框定让你摆脱了责任。你的停滞不前的工程师并不是在真空中停滞的。他们是因为没有什么东西在他们的环境中推动他们超越最初的调整。他们获得了看似合理的生产力提升，没有人挑战他们去更进一步，惯性做了其余的事情。那些继续推进的工程师？大多数是自我激励的。他们无论如何都会推进。但是，你不能只用自我激励的先驱者来组建一个工程组织。领导者的问题是：如何移动中间的人？这是一个变革管理问题，我最喜欢的一个框架来自希斯兄弟的书...
目前有一种正在形成的叙事，引起了很多关注：人工智能正在耗尽我们的精力。工程师们正在比以往任何时候都更频繁地提交代码，并且感觉比以往任何时候都更糟糕。”人工智能疲劳”的术语正在流行，各种观点也在不断增加。一位软件工程师在 Business Insider 上写道，最近一个季度是他最富有成效和最疲惫的季度。Steve Yegge，这位著名的编码专家，在 The Pragmatic Engineer 中表示，他白天会小睡一会儿，并将人工智能增强的工作时间限制在三小时内。创业公司的创始人在下午 2 点就会感到精疲力尽。这个月最广泛分享的帖子警告说，人工智能对那些使用它的人有着”吸血鬼般的影响”。但是，没有人似乎注意到：报告最多疲劳的人并不是怀疑论者。他们是真正的信徒。那些停留在 Yegge 采用曲线第一级的工程师，完全忽略人工智能的人，感觉还可以。有点焦虑，也许，但不感到疲惫。真正感到疲惫的是那些已经全身心投入的人工智能的人，运行多个代理，编排复杂的工作流程，以前所未有的速度交付工作的人，他们回家后已经筋疲力尽了。这种模式应该告诉我们一些事情。我认为它告诉我们的就是所谓的”人工智能疲劳”根本不是正确的诊断。你没有疲劳问题，你有一个训练问题。想想你第一次硬拉的经历。不是特别重的重量。只是动作本身。你第二天早上醒来，整个身体感觉像被拆卸然后重新组装了一样。你的腿很酸。你的背很酸。以前不知道存在的肌肉以最不愉快的方式让你知道它们的存在。如果有人在那天测量你的产出，它看起来会很糟糕。你几乎无法坐下而不皱眉。你可能会合理地得出结论，硬拉是不可持续的，人类的身体不是为此而设计的，成本大于收益。但是，当然，六个月后，你将会举起两倍的重量，并且在之后感觉良好。你的身体已经建立了新的通路。它已经适应了。曾经需要全部意识努力的动作已经变得自动化。酸痛并不意味着你已经坏了。它意味着你正在建立一些新的东西。这正是人工智能增强工作发生的事情。没人谈论的认知负荷当你传统地编写代码时，你的大脑正在运行一个磨练过的程序。你已经做过这件事数千次。你知道按键，模式，调试节奏。就像开车去上班一样：技术上复杂，但由于你已经做过很多次，所以你可以边做边想着晚餐。人工智能增强的工作是一个根本不同的认知任务。你不再编写代码。你正在指挥，评估，决定，在多个代理之间切换上下文，审查你没有编写的输出，同时在大脑中保持架构意图，同时人工智能做出你需要实时验证的实现选择。这不是同一份工作做得更快。这是一份完全不同的工作。而你的大脑还没有为此建立高效的通路。每个决定仍然是有意识的。每次审查都需要积极的努力。你正在监控质量，在平行工作流中保持上下文，持续对人工智能输出做出判断。这就是为什么三小时的工作会让你比八小时的传统编码更疲惫。这是认知上的等同于你的第一个星期在健身房。采用曲线实际上是疲劳曲线Yegge 的八级人工智能采用框架几乎完美地映射到一个疲劳曲线上，尽管我不认为这是他的本意。在第一级和第二级，你几乎没有使用人工智能。自动完成这里，问一个问题那里。认知负荷不大。疲劳也不大。在第三级到第六级，你处于深水区。你已经给代理更多的自主权，你正在更全面地审查，而不是逐行审查，你正在运行多个代理，你正在不断地导航一个 18 个月前不存在的工作流程。这就是疲劳的所在地。这就是重度硬拉。在第七级和第八级，会发生一些有趣的事情。你已经建立了编排系统。人工智能更自主地工作。你已经学会了什么可以信任，什么需要检查。Matt Shumer 描述了这件事：告诉人工智能要构建什么，离开四个小时，然后回来发现工作已经完成。适应开始发挥作用。疲劳并不均匀分布。在中间，它达到峰值，就在大多数早期采用者目前所处的位置。正是因为这样，疲劳似乎是普遍的：最多谈论人工智能的人不成比例地处于学习曲线最困难的部分。没有人写过关于”驾驶疲劳”的文章记得你第一次学习驾驶吗？第一次你合并到高速公路上，你可能会像你的生命依赖于它一样紧握方向盘（说实话，它确实依赖于此）。你开了 30 分钟的车后回到家完全筋疲力尽。你的大脑一直处于最大容量：检查后视镜，管理速度，预测其他司机，处理道路标志，所有这些同时进行，全部有意识地进行。现在你可以开一个小时的车，同时半听着播客，吃着三明治。任务没有改变。你改变了。你的大脑为驾驶建立了高效的神经通路，将曾经需要全部意识努力的东西压缩成背景过程。没有人写过关于”驾驶疲劳”的文章，将其作为存在主义危机。没有人建议汽车对其操作员有”吸血鬼般的影响”。我们直观地理解，疲劳是暂时的。这是学习新东西的成本。这就是当前话语缺乏的部分。”人工智能疲劳”被视为一种永久的状况，技术的基本特征，而实际上它是一种转换成本。这是训练疼痛，而不是慢性疾病。为什么这比舒适更重要这种区分不仅仅是语义学上的。如何诊断问题决定了你如何处理它。如果人工智能疲劳是技术的永久特征，那么 Yegge 的三小时限制就是永远的天花板。公司应该计划让工程师只在一天中的一小部分时间内保持高效。”吸血鬼般的影响”是进入的代价，我们只能接受它。但是，如果它是训练疼痛，那么剧本就完全不同了。你管理负荷。你逐渐建立。你不会因为酸痛而停止去健身房。并且，关键是，你不会假设今天的疲劳水平就是明天的。那些推动这一阶段的工程师，建立了人工智能工作的认知通路，审查的正确高度，以及在平行工作流中保持架构意图，将最终像开车一样自然地做这些事情。三小时的限制将会移动到五个小时，然后七个小时。不因为他们工作得更辛苦，而是因为工作不再以同样的方式需要努力。与此同时，那些阅读关于”人工智能疲劳”的文章并决定保持在第二级的工程师，舒适，熟悉，不会感到疲惫，将会发现自己处于更糟糕的位置。不是因为他们跟不上趋势，而是因为他们从未开始过其他人已经完成的训练。真正的风险：混淆酸痛和受伤我想澄清一件事。训练酸痛和实际受伤之间有区别，这也适用于这里。如果你每天 14 小时都在”氛围编码”，睡眠 4 小时，靠肾上腺素支撑，因为新鲜感很令人陶醉，那不是训练。那是过度训练。而且，就像在健身房一样，过度训练不会建立任何东西。它会把你拆解掉。Yegge...
那是一个美丽的夏日，我正在度假。我的家人正在等我去海滩。我告诉他们我会在“五分钟”后加入他们——那已经是两个小时前了。“几乎完成了，”我低声说。“再试一次。”代码几乎正确（过去两个小时）。那时我突然意识到：我不是在调试，我是在赌博。IDE 中的老虎机如果你花时间“vibe coding”——那美丽、混乱的 AI 提示舞蹈，你已经感受到了。那种吸引力。那声音说：“再输入一个提示，宝贝。”当 AI 限制实际上是来拯救你的，让你获得应得的睡眠。这不是偶然的。Vibe coding 具有与老虎机、视频游戏和滚动浏览相同的心理结构，使它们如此上瘾。让我来分析一下机制：可变奖励计划：有时 AI 第一次尝试就成功。有时需要十五个提示。有时它会给你一些你甚至没有要求的东西。你永远不知道会得到什么，那种不可预测性——心理学家称之为可变比率强化计划——是我们知道的最上瘾的奖励模式。它与老虎机和战利品箱背后的原理相同。近似错过效应：代码几乎完成了。它运行但有一个 bug。逻辑正确但语法不对。这些近似错过会触发与几乎赢得老虎机相同的神经通路。你的大脑将“几乎完成”解释为“再试一次肯定会成功。”为什么专业工程师（部分）免疫这里有一个有趣的现象：专业软件工程师实际上不容易上瘾于 vibe coding。起初，这似乎是反常的。那些最了解代码的人应该最兴奋于编写代码的 AI 吧？但想想实际发生了什么。对于专业工程师来说，变量奖励是：“AI 会像我一样编写代码，还是会失败？”这不是特别令人兴奋的。他们知道自己可以编写代码。AI 是一种生产力工具，而不是魔术。对于那些不能编写代码的人来说？天啊。每次 AI 成功时，都是一种奇迹。你从零能力变成突然可以构建东西。这不是优化——这是转变。这是我在早期工程师生涯中感受到的那种激动，当我意识到我可以编写一些代码并使角色在屏幕上移动时，软件感觉像真正的魔法。现在，这种创造的时刻正在被民主化到数百万人。多巴胺的冲击不仅仅是关于变量奖励——它是关于能力的无限跳跃。从“我做不到”到“我刚刚构建了东西”。这太令人陶醉了。此外，大多数专业工程师都经过长时间的调试会话的训练，所以这对他们来说不是新鲜事。100 小时工作周并非你想象的那样关于创始人现在工作时间过长的讨论已经很多——在 WeWork 办公室睡觉，100 小时工作周，完全精疲力竭。通常的说法是关于来自 AI 热潮、竞争和被甩在后面的恐惧的压力。但是事情是这样的：创始人的压力一直存在。这就是为什么大多数初创公司会失败的原因。在...
随着工程组织的规模扩大，它们不可避免地会积累起层层繁复的流程，这些流程会减慢开发速度。任何一个曾经让组织规模超过一定大小的工程领导者都知道这种模式：首先是基本的Scrum，接着跨团队依赖需要协调会议，最后，你会发现自己在考虑像SAFe这样的框架来管理所有这些。我曾经管理过一个工程组织，拥有一个三维的组织矩阵（不包括单独的产品组织）。结果是什么？副总裁们因为速度变慢而感到沮丧，工程师们抱怨“流程负担”导致延迟，创新也在官僚主义的重压下停滞不前。对于那些经历过的人来说，流程对创新的税收是真实且昂贵的。现在，AI提供了一条逃脱路——不仅仅是通过使工程师编码更快的明显第一阶效应，还通过对工程组织运作方式的深刻第二阶效应，这可能从根本上改变工程组织的运作方式。超越生产力：组织影响虽然很多关注点都集中在AI加速个体编码任务的能力，但更具变革性的潜力在于它如何减少组织复杂性的需求。通过增强个体能力，AI系统地消除了许多流程最初旨在解决的协调问题。考虑“全栈工程师”的理想。历史上，在扩大的组织中，这往往更多是一种愿望，而不是现实，经常会创建与Scrum团队平行的组织结构。今天，AI戏剧性地改变了这种情况。工程师可以有效地在不熟悉的代码库或技术栈部分工作，AI实时弥补知识差距。结果是什么？团队需要的交接次数更少，减少了大型组织中常见的协调负担。这种能力扩展也适用于架构。与其等待正式的架构审查会议，工程师可以使用AI作为初始“陪练”来开发和完善想法。工程师可以与AI进行交互，以挑战假设，找出潜在问题，并加强提案，然后再将其提交给人类审查员。在许多情况下，这些AI辅助提案可以异步共享，经常消除了对正式会议的需求。架构仍然会得到适当的审查，但没有日历延迟和协调头痛。质量保证呈现了另一个流程简化的机会。传统的开发周期涉及开发和QA之间的多次交接，错误会触发新的审查和改进周期。AI通过帮助开发人员将全面测试（包括单元测试、集成测试和端到端测试）纳入日常工作流程来压缩这个周期。通过更早、更可靠地发现问题，AI减少了传统上减慢发布速度的来回往复。团队可以在减少往返的情况下保持高质量标准。也许最重要的是，这些个体能力的增强使得组织简化成为可能。以前依赖于多个团队之间复杂协调的团队现在可以更加独立地运作。曾经需要多个专门团队的项目现在可以由规模较小、更自给自足的团队处理。许多大型组织采用的大规模框架——通常是勉强接受的——在团队拥有AI能力时可能不再必要。15分钟规则：重新构想敏捷流程这些转变为传统的Scrum流程带来了简化的机会。考虑为AI增强的团队采用个人生产力“2分钟规则”：如果正确提示AI代理执行某项任务需要的时间少于15分钟，那么立即执行，而不是将该任务纳入整个待办事项/规划流程中。”这种方法大大提高了效率。AI工作时，工程师可以专注于其他优先事项。如果AI解决方案不够完善，他们可以为待办事项创建一个适当的用户故事。有了正确的集成，小的改进可以在没有仪式的情况下持续进行，而较大的努力仍然可以从适当的规划中受益。我们看到的模式表明，一个新的、更精简的软件开发模型的出现——它保留了敏捷的以人为本的原则，同时消除了多年来积累的许多流程负担。在AI增强工程时代领导对于工程领导者来说，这种转变需要对组织设计进行根本性的重新思考。随着团队的增长，添加流程、专业化和协调机制的反应可能不再是正确的方法。相反，领导者应该考虑： 大量投资于能够扩展个体工程师有效技能范围的AI能力 挑战关于必要的团队规模和专业化的假设 尝试使用AI的协调减少效果的简化流程模型 测量和优化“流程时间”以及传统的开发指标 那些能够识别AI不仅仅是一种生产力工具，而是能够使组织结构变得根本更简单的组织，将会在未来蓬勃发展。通过扁平化等级制度，减少交接，并消除协调负担，AI提供了将初创公司的创新速度与大型工程组织的解决问题能力相结合的潜力。在软件开发中经历了二十年的流程复杂性增加后，AI可能终于使我们能够回到敏捷宣言的原始精神：重视个体和交互而不是流程和工具。工程的未来不仅仅是更快——它将会变得更加简单。
