AI 编码助手和自主代理正在改变软件开发。这些工具能以前所未有的速度生成代码、实现功能，处理过去需要开发者数天甚至数周才能完成的任务。但这种加速也带来了新的挑战：人类团队成员往往成为瓶颈——理解更大的架构全貌、审查代码质量、权衡设计取舍，这些都是 AI 无法独立完成的。简而言之，AI 可以大幅提升编码速度，但确保软件正确、可维护、符合用户需求，仍然严重依赖人类洞察力。要有效利用 AI，开发方法论必须演进。
AI 编码助手能快速产出代码，但并未消除软件开发中较慢的环节——事实上，它们常常将瓶颈转移到人类监督上。团队遇到的第一个痛点是代码审查。
随着 AI 生成"越来越多的代码"，开发者难以跟上审查节奏，检查这些变更的 bug、一致性和质量。这种困境因 AI 对大型复杂代码库的理解有限而加剧——当前模型往往缺乏对项目数百万行代码完整上下文的深入洞察，容易建议与系统其他部分冲突的修改。结果是人类专家必须花费大量时间指导 AI 并检查其输出，捕捉狭窄上下文的 AI 可能遗漏的问题。
虽然 AI 加速了代码编写，但无法以同样方式加速验证流程。行业观察者指出，仅仅让 Agile 开发步骤（借助 AI）跑得更快可能导致混乱而非进步。实践中，反馈和审查循环仍受人类认知速度制约。正如一位产品教练所说："AI 不会加速人类审查流程。如果你的路线图中遗漏了'中间的人'，就会制造问题。"换句话说，团队仍需时间理解需求、审查 AI 生成的输出、提供反馈——这些步骤不能安全跳过或完全自动化。将代码推向生产的速度快于人类有效审查的速度，是脆弱软件的配方。
为什么人类监督如此耗时？传统代码审查是劳动密集型的手动过程。审查者花费数小时仔细检查 pull request，发现 bug、执行编码标准、确保安全和性能最佳实践。在快节奏环境中，这可能成为瓶颈——PR 审批缓慢而截止日期迫近。即使最优秀的人类审查者也有局限：疲劳和人为错误意味着细微问题或架构不一致可能漏网。当 AI 快速生成大量变更时，风险在于未审查代码队列增长，或审查变得肤浅。最终效果可能是技术债务悄然累积或缺陷被忽视。因此，AI 开发的速度往往受限于人类审查和完善其输出的能力。
现代软件系统极其复杂,常常超出单个人能完全理解的范围。人脑管理复杂性的能力有限——工作记忆一次只能容纳有限信息。在大型代码库中,细节很容易被遗忘或忽视；开发者经常报告,如果文档不完善,仅几周后就会忘记系统架构。在理解系统如何组合方面的一个小疏忽可能导致灾难性后果,从引入难以发现的 bug 到使软件无法维护。这种固有的认知限制意味着随着代码库增长,维护整个系统的连贯心智模型对任何个人都是严峻挑战。这不是技能或智力问题——是生物学问题。我们通过团队协作、文档和工具来缓解,但风险依然存在:复杂性可能压垮人类理解。
AI 对复杂性的双重影响：
将 AI 引入这个混合体可能帮助也可能伤害局面。一方面,AI 可以快速编写代码实现新功能。另一方面,如果缺乏指导,AI 可能做出以隐蔽方式增加复杂性的设计决策。AI 代理对代码库健康没有长期责任——它们不会感受到维护混乱代码的痛苦。
因此,它们可能产出技术上能用于即时任务但创造纠缠架构或到处重复逻辑的代码。有观察指出,当前 AI 模型"在独立做出正确设计和架构决策方面相当糟糕",即使它们产生语法正确的代码。如果让 AI 代码生成器在没有架构指导下运作,它会快速累积技术债务——编写大量通过测试但结构糟糕的代码。数万行之后,这样的代码库基本上无法维护。实际中,这可能表现为高度耦合的组件、不一致的数据模型、或重复且脆弱的逻辑,使整个系统变得脆弱。在这种失控系统中,小小的配置更改或库更新可能触发级联故障,因为底层设计不稳固。这就是为什么开发者常常害怕重构或更改 AI 编写的代码——他们感觉系统是纸牌屋,可能在没有大量细致重新工程的情况下崩溃。
关键挑战是确保凝聚的架构,即使 AI 在贡献代码。软件架构是支撑复杂系统的骨架;它定义模块如何交互、数据如何流动、基本设计原则是什么。人类通常通过经验和有意识的设计工作来发展这种架构。相比之下,AI 本质上不理解"可维护性"或"优雅设计"等概念,除非我们明确编程或提示它遵循某些模式。因此,没有人类架构师参与,AI 可能以看似最简单的方式解决每个局部问题,潜在违反架构约定或引入人类团队通常会避免的不一致。随着时间推移,这些失误成为瓶颈——代码能用,但没人真正完全理解它,任何新变更都变得危险。总之,如果我们不对 AI 的输出施加结构和设计纪律,AI 会放大复杂性。
管理任何大型软件项目(AI 辅助与否)的基本策略之一是分而治之。这意味着将系统分解为更小、更易管理的组件,并以清晰的层次结构分层。分层架构将复杂系统划分为具有明确定义职责的不同层次。例如,一个常见分层是:展示层 → 业务逻辑 → 数据存储。每层以有组织的方式与紧邻的上层或下层通信,各自承担特定角色。这种模块化方法在成功的软件项目中极其常见,正是因为它驯服了复杂性。通过分割功能,团队可以处理 UI 而无需担心数据库内部,或替换数据存储层而无需重写业务规则。层次创造了自然的"知识桶"——只要各部分之间有清晰的契约,没有单个人需要知道一切。
对 AI 团队的重要性：对于包含 AI 开发者的团队,分层和模块化变得至关重要。为什么？因为处理代码的 AI 代理需要约束才能有效运作。如果我们能告诉 AI,"这部分代码只处理网络,所有 HTTP 调用都使用模块 X",我们就给了它一个框架来保持在范围内。
如果项目架构是没有边界的自由放任,AI 很容易调用错误的部分或重复本该在别处的功能。清晰的关注点分离引导人类和 AI 贡献者将代码放在正确的位置。
此外,分工延伸到人类方面的所有权。在人类团队中,你可能有前端负责人、后端/数据库负责人、DevOps 专家等。类似地,与 AI 协作时,人类可能监督某些领域或层,同时在指南内将范围明确的任务委托给 AI。例如,人类可以概述高层方法(API 设计、数据模型、服务间交互),然后要求 AI 在指南内实现特定函数或类。通过划分任务,如果 AI 犯错,错误是局部的,不会破坏整个代码库。
至关重要的是,团队必须建立规则和边界,使 AI 贡献不违反预期架构。一些前瞻性团队甚至为 AI 结对编程会话定义工作协议。例如,一个协议可能是:"尊重现有架构——遵循已建立的模式,除非明确要求,否则不引入根本不同的方法。"这意味着如果 AI 开始以不符合当前设计的方式编码(也许它试图添加新微服务而团队同意单体,或使用不兼容的库),人类会介入并重定向它。另一个协议可以强制 AI 一次专注于一个小变更——确保它不试图一次性彻底改造系统的多个部分,这可能破坏东西。通过编纂这些约束,我们本质上将"责任"构建到 AI 的流程中。AI 本身可能不会感到负责,但它被负责任的人类设定的指南框住了。
总之,应用可靠的架构分层和明确的责任分工是控制复杂性的基础方法。它允许 AI 代理在明确定义的护栏内工作,并允许人类更有效地监督(因为每个人可以一次专注于系统的一部分)。分层系统的有组织结构使其随时间更容易理解和维护——每个部分都有清晰的目的,就像组织中的部门。这样,即使软件范围增长,我们也能防止它变成无法管理的混乱。AI 与否,这个原则都成立,但当 AI 可能在没有全局理解的情况下生成代码时,这尤其至关重要。
单个人一周后无法记住系统架构的一个原因往往是文档不足。在快节奏开发中,团队有时忽视记录——当 AI 高速生成代码时,未记录知识的风险更高。然而,如果我们想让人类和 AI 朝着相同目标对齐,记录软件架构不是可选的。良好的文档实践对于扩展知识、对齐团队成员、赋能每个人(包括 AI 助手)做出正确决策至关重要。
有几种经过验证的技术来保存和共享架构知识:
ADR 是记录单个关键决策及其上下文和后果的简短文档。当团队决定"我们将为此服务使用数据库 X"或"出于这些原因我们将采用微服务架构而非单体"时,他们写一个 ADR。这创建了一个按时间顺序记录事物为何如此的日志。未来,如果新开发者(或 AI)想知道"为什么这样做?",ADR 提供答案。它防止团队失去决策背后的理由,这在复杂性增长时至关重要。ADR 还帮助避免原地打转——未来贡献者可以看到考虑和拒绝了哪些替代方案,因此不会重复辩论。简而言之,ADR 维护决策制定的连续性和透明度。
从互联网工程实践借鉴,RFC 流程意味着为重大变更或功能写下提案,然后向团队(甚至社区)征求反馈。这是在承诺方向之前收集多样化视角的强大工具。在复杂系统中,没有一个人看到问题的所有角度;RFC 确保想法经过多位专家审查。RFC 文档可能概述问题、提出解决方案、列出问题或顾虑。团队成员审查它、添加评论、建议修改或提出异议。这种协作讨论导致更稳健的设计,也记录了为什么选择某种方法(以及为什么没选择其他)。它本质上是以书面形式进行设计讨论,创建集体智慧的纸质轨迹。对于 AI 相关工作,RFC 甚至可用于决定如何以及在哪里使用 AI 代理(例如,"我们应该使用 AI 重构模块 Y 吗？这是计划…"),邀请审查以确保安全和合理。
复杂架构受益于可视化。例如,C4 model 提供系统的多个视图——上下文、容器、组件和代码——每个都处于不同抽象层次。上下文图可能显示系统整体如何与用户和外部系统交互。容器图显示高层构建块(如服务、数据库、消息队列)。组件图放大到其中一个容器以显示内部结构。这些分层视图帮助人类和 AI 掌握系统。例如,如果你向 AI 提供基于 C4 的文档或描述,它可以理解"模块 A"不应该"直接调用数据库 B",而只能"通过服务 C"等。好处是双重的:它使新团队成员入职更快(人们可以快速获得系统的心智地图),并作为做变更时的参考,检查变更是否符合架构。
像 Jira(用于跟踪任务/问题)或 Confluence/Wiki(用于文档)这样的工具在复杂项目中扮演关键角色。它们通过将需求链接到设计工件到实现任务来施加结构。例如,一个 Jira ticket 可能有子任务、到 ADR 或设计文档的链接、以及测试用例引用。这种可追溯性帮助管理不确定性,因为它创建了上下文网络:如果某些东西改变(比如需求),你可以找到所有可能受影响的相关任务、设计笔记和代码部分。当 AI 是工作流的一部分时,将它与这些工具集成是明智的。例如,AI 代理可以被给予用户故事或 Jira ticket 的文本作为提示的一部分,这样它就有编写代码的上下文。类似地,当 AI 建议代码变更时,将该建议链接回问题或文档页面帮助人类验证它是正确的。底线是强大的知识管理——无论通过 ADR、RFC、图表还是跟踪工具——是人类解决复杂性问题的方式。它外化知识,所以我们不纯粹依赖记忆,并创建人类和 AI 协作者都可以参考的共享理解。
通过投资这些实践,团队降低了"只有 Bob 知道那个子系统如何工作"的风险——或者因为它由 AI 生成且从未解释而没人知道。相反,架构知识成为项目资产的一部分。这在与 AI 代理合作时尤其关键:如果 AI 基于提示构建了某些东西,我们理想情况下应该在 ADR 或设计文档等工件中捕获推理(提示和它遵循的设计)。这样,如果我们稍后重新访问该组件,我们不会对 AI 的神秘逻辑感到困惑;我们有它被要求做什么以及给了什么约束的上下文。
本质上,工具和文档充当人类记忆的扩展和团队成员与 AI 之间的通信桥梁。它们确保随着项目期间结构的出现(特别是敏捷的、自下而上的项目,其中并非所有东西都是预先已知的),沿途形成的决策和架构被记录和同意。这大大降低了复杂性失控或知识孤岛导致瓶颈的可能性。
无论 AI 开发者变得多么先进,人类监督对于确保软件项目的质量和正确性仍然至关重要。AI 代理不具备真正的理解或问责——如果它们引入使生产崩溃的 bug,它们不会感到难过,它们也无法直觉未明说的需求或伦理考虑。因此,团队必须保持人类"在回路中"作为最终检查和指导。实践中,这意味着调整角色和流程,使人类专注于 AI 无法(或不应该)独立完成的事情。
角色转变：一个新兴范式是人类角色从编码者转变为架构师和监督者。开发者不再自己编写每一行,而是监督 AI 生成的代码,确保它符合预期设计并满足验收标准。
人类设定方向("我们需要在这些约束下做 X 的功能"),然后监控 AI 的输出,在 AI 偏离轨道时介入。重要的是,在任何 AI 编写的代码合并或发布之前,人会在上下文中评估它。这类似于高级工程师审查初级开发者的工作——除了这种情况下的"初级开发者"是除非给定否则上下文为零的 AI。人类审查者不仅看代码差异,还考虑此变更是否会在其他地方产生连锁反应,是否遵循项目的风格和架构,是否真正解决问题而不引入新问题。
AI 代码审查工具可以通过提供自动化的第一遍来协助:例如,专门的代理可以分析代码变更并突出显示整个代码库中的潜在问题或不一致。这样的 AI 审查代理可能捕获简单的基于差异的检查会错过的东西,比如"这个新函数绕过了其他类似函数使用的重要安全检查"——因为它能够扫描整个仓库寻找类似模式。这对增强人类审查者的能力极其有用。
然而,最终判断仍由人类做出。软件开发生命周期的外环——代码审查、测试、事件分类、决定优先级等任务——需要人类洞察。AI 可以帮助其中每一项(我们已经看到 AI 建议测试用例或诊断构建失败),但人类应该验证结论。例如,如果 AI 建议修复失败的单元测试,人类需要确保该修复不会破坏需求或引入细微 bug。如果 AI 将一段代码标记为安全风险,人类安全专家需要确认并决定如何处理。让人类在回路中提供了针对 AI 错误或幻觉的安全网。这类似于航空中的自动驾驶:自动驾驶可以在常规条件下飞行飞机,但当情况棘手或发生意外时,人类飞行员必须准备好接管控制。
此外,人类必须在设计决策上指导 AI。如前所述,AI 通常缺乏预见实现选择长期影响的能力。例如,AI 可能选择对 100 个用户有效的快速算法,但人类架构师应该预见到对于 100,000 个用户,该方法无法扩展。除非被指示,AI 本质上不做那种前瞻性分析。一位 AI 辅助开发专家观察到,如果你让代理在没有指导的情况下编码,"它们会编写正确的代码但会非常快速地累积大量技术债务",在某个点之后你最终得到无法维护的系统。人类监督者的工作是引导 AI 朝向良好的长期决策。这可能涉及告诉 AI 不仅构建什么,还如何构造它——例如,"通过在这里添加新类来实现此功能,不要只是往现有的 1000 行函数中塞更多逻辑。"它也可能涉及偶尔说"不,停——这种方法在架构上走错了方向,让我们重新思考",类似于团队负责人如何重定向开始编写过度复杂解决方案的初级开发者。
传统敏捷方法论被创建来应对软件项目中的不确定性和快速变化。它们青睐短周期(sprint)、来自利益相关者的持续反馈、以及适应新信息的灵活性。在 AI 可以在几秒或几分钟内生成代码的世界中,一个自然问题出现:Agile 如何变化？当 AI 理论上可能一次性构建整个功能时,我们还需要迭代吗？有趣的是,许多专家认为 Agile 没有死亡,但确实需要在 AI 时代演进。敏捷的原则——迭代改进、客户协作、对变化的响应性——仍然极其相关,但当 AI 是团队一部分时,机制可能看起来不同。
迭代速度的转变：Agile 被设计用来对抗瀑布的长周期,通过在几周而非几月内交付可用的东西。现在 AI 可以在几天或几小时内交付,这进一步压缩了周期。但有一个问题:人类(用户、产品经理、设计师等)仍需要时间提供反馈并决定变更。
如前所述,在没有适当反馈的情况下加速开发只是更快地创造垃圾。因此,一个适应是维护健康的反馈循环节奏。人类反馈周期成为限制因素——也许团队可以做 1 周或 3 天 sprint 而不是 2 周 sprint,因为代码编写更快,但你不太可能做比那更快的有意义的反馈周期,因为用户/客户需要实际使用软件并响应。本质上,sprint 长度可能缩短,但不能缩短到零。你仍需要计划、审查和回顾阶段,即使编码现在是时间线中较小的部分。
另一个有趣的发展是结合 Agile 和 Waterfall 元素的混合方法想法。一些行业声音建议 AI 对清晰指令的需求在某种程度上带回了前期计划的风味。回想一下,敏捷出现是因为需求经常变化,在新项目开始时详细计划一切是低效的。但 AI,就其目前状态而言,不擅长模糊指令。如果你只是告诉 AI,"给我做个漂亮的仪表板",它可能产生通用或不对齐的东西。然而,如果你给它非常详细的规范,它通常可以快速构建一个令人惊讶稳健的系统。这种动态导致团队考虑花更多时间前期定义他们想要什么——有效地编写更详细的设计文档或用户故事——因为 AI 然后可以以惊人的速度执行该计划。换句话说,类似 Waterfall 风格的计划(在编码前指定很多事情)可能变得值得,因为 Waterfall 的通常风险"花太长时间,等你构建时世界已经变了"被 AI 的快速执行缓解了。一位评论者将此称为"Waterfall 2.0",你投资于清晰规范,然后让 AI 构建它,它完成得如此之快以至于你可以负担得起详细计划而不失去敏捷性。
这是否意味着我们放弃 Agile？完全不是。混合模型通过将这些前期计划作为仍需验证的假设来保持 Agile 的优势。Agile 对于处理未知仍然至关重要——例如,验证功能是否实际解决客户问题,或在市场转变时转向。AI 可能减少使功能技术上正确所需的迭代次数,但不保证功能是构建正确的东西。Agile 对持续检查用户需求并调整方向的强调仍然重要。
当开发加速时,风险是错误也发生得更快并可能在任何人注意到之前累积。为了对抗这一点,团队将质量控制步骤嵌入到每个 AI 驱动的开发周期中,通常受精益制造和持续改进技术的启发。一种获得关注的方法是在编码会话的微观层面应用 Plan-Do-Check-Act (PDCA) 循环。
以下是 PDCA 循环在 AI 编码会话(可能短至一两个小时)背景下的样子:
在 AI 开始编码之前,人类开发者和 AI 花一些时间(比如 10 分钟)详细计划任务。这涉及分析问题、审查代码库的相关部分、制定精确方法。AI 扫描大型代码库的优势可以在这里被利用——例如,你可以提示 AI 从仓库中组装关于功能的上下文,以避免重复代码或偏离现有模式。计划应包括明确的检查点:将工作分解为步骤,决定将编写什么测试,澄清完成的定义。本质上,这一步是在任何代码变更发生之前通过获得清晰策略来减少歧义并防止"架构漂移"。人类将确保此计划与整体架构和范围对齐(尽早捕获任何误解)。
现在 AI 根据计划生成代码。这可能持续几分钟到几个小时,取决于复杂性。至关重要的是,人类在此编码阶段保持积极参与——这不是发射后不管。开发者监控 AI 的工作(许多 AI 工具允许你看到正在编写的内容或它正在思考的步骤)并提供主动监督。如果 AI 开始偏离轨道——也许它尝试过度复杂的解决方案,或偏离计划——人类立即介入纠正或引导它回来。这与我们讨论的"工作协议"一致:例如,如果 AI 突然试图一次修改两个不相关的模块,人类会阻止它(因为协议是一次一个集中的变更)。通过早期且经常地介入,人类防止浪费努力并阻止 AI 生成需要返工的大块错误或低质量代码。实际上,编码是合作之舞:AI 写,人类实时监督和纠正方向。
一旦 AI 认为它完成了(或编码会话时间到了),就是验证输出的时候了。这是一个简短步骤,也许几分钟,代码针对计划中建立的明确完成定义运行。完成定义可能包括:所有新代码都有相应的通过测试,功能行为满足验收标准,没有主要 lint 或静态分析问题等。团队可能运行自动化测试、检查代码风格、并在这里使用 AI 代码分析。重点是在继续之前快速验证完整性和质量。如果某些东西不对——测试失败或未满足需求——它被反馈到重做部分代码(另一个 Do 循环)或调整计划中。本质上,"检查"确保 AI 编码会话的输出实际解决了问题并遵守质量标准,而不是在很久以后才发现某些东西偏了。这是一个紧密的反馈循环。
最后,发生简短的回顾或调整阶段。即使在 1-2 小时周期中,也值得花 5 分钟反思:这次使用 AI 什么进展顺利？任何特定提示或策略产生了好结果吗？是否有误沟通或错误下次可以避免？人类(如果 AI 保留一些记忆或日志,可能还有 AI)记下未来协作的改进。例如,也许团队注意到 AI 反复在代码库的某个部分挣扎——这可能表明他们下次需要给它更好的上下文,或者也许那部分代码需要重构以提高清晰度。Act 阶段是关于持续改进人类-AI 交互的流程。它也可以基于学到的更新"工作协议"或提示。
这种 PDCA 方法基本上将 Agile 的迭代和反馈思想带入小时级工作流。不是只在 2 周 sprint 结束时做回顾,你在编码会话结束时做迷你回顾。通过用计划和检查结构化每个 AI 编码会话,你大大减少了 AI 失控并向团队倾倒一堆有问题代码的可能性。它也在整个过程中保持人类参与,正如我们强调的,这至关重要。
软件工程一直是团队运动。引入 AI 参与者不会降低这一事实——如果有什么的话,它加剧了对有效协作和清晰角色的需求。AI 代理,尽管强大,不具备软技能:它们不能举行设计辩论,不能在利益相关者之间协商冲突需求,当然也不能直觉办公室政治或客户情绪。人类仍然是必须参与创造性头脑风暴、解决冲突观点、确保技术工作与业务战略对齐的人。因此,团队的结构和文化仍然至关重要。
AI 的一个直接影响是团队成员可能需要调整他们的角色,但不是消除它们。以软件架构师或技术负责人的角色为例:以前,他们可能花大量时间自己编写关键系统代码。现在,他们可能花更多时间定义架构、为 AI 编写详细设计文档或提示、审查 AI 正在做的更大设计决策。他们变得更像教练和协调员,确保 AI 和人类贡献者都和谐工作并遵循架构愿景。类似地,考虑 QA 工程师或测试人员。他们可能从编写大量手动测试用例转向策划测试场景和基于属性的测试,确保 AI 的输出被彻底审查。他们也可能训练或配置基于 AI 的测试工具。他们的目标保持不变——保证质量——但他们使用的工具和运作的速度会改变。
新角色：AI Wrangler - 团队中专门理解 AI 如何行为、如何从中获得最佳结果、以及当 AI 输出胡言乱语时如何排错的人。这可能是开发者或负责人角色的新方面。它涉及提示措辞的实验、维护团队做的任何自定义模型或微调、并跟上 AI 的能力和限制。
团队流程如每日站会、sprint 计划和回顾将包括 AI 考虑。例如,在站会中,除了听每个人做了什么,团队可能讨论什么任务被交给了 AI、返回了什么结果、遇到了什么问题。如果 AI 在某些东西上挣扎(比如它产生了五个版本的函数但没有一个令人满意),那是值得分享和学习的重要信息。计划会议将不仅决定做什么,还决定谁或什么应该做——这个任务最好由人类完成,还是 AI,还是两者配对？也许 AI 擅长编写样板代码,而人类应该做与怪异遗留系统的集成,因为对 AI 来说太特定于上下文。这些决策成为项目管理的一部分。
协作也意味着人类一起工作来监督 AI。例如,结对编程可能变成三人编程:一个人类驾驶,另一个人类审查,AI 建议。这可以更快地捕获问题——一个人类可以盯着 AI 建议,而另一个人提前思考设计。或者,AI 可以与初级开发者配对,通过建议代码有效地指导他们,而开发者学习指导或纠正 AI。在所有情况下,沟通是关键。
将 AI "员工"引入软件开发是一把双刃剑。一方面,我们有生产力的惊人提升——AI 代理可以以人类无法匹敌的速度生成代码甚至设计建议,潜在地处理大量繁重工作并解放人类进行更多创造性任务。另一方面,这种速度和输出量本身可能使我们确保项目质量和连贯性的传统方式紧张。瓶颈转移到人类层面:我们监督、理解和指导这些 AI 贡献者的能力成为项目成功的决定因素。
关键要点：
最终,人类因素仍是复杂项目中的决定性要素。AI 可以承担大量工作负载,但人类提供方向、智慧和问责。通过更新我们的方法论——分层架构、记录一切、平衡前期计划与敏捷迭代、构建质量反馈循环——我们可以利用 AI 的优势同时缓解其弱点。回报是巨大的:在不牺牲(理想情况下改进)质量的情况下更快交付的软件项目。人类监督的瓶颈可以通过更好的工具和流程拓宽,但不会消失;相反,我们的目标是使该监督更有效和可持续。
通过这些适应,关于"有了 AI 员工,我们如何解决复杂、不确定的软件项目?"的问题可以自信地回答:通过将人类战略指导与 AI 的战术速度配对,持续完善我们的方法。瓶颈——我们——可以变成放大 AI 能做什么的支点,产生比以往更快构建的可靠、创新软件,但没有混乱。这是一个令人兴奋的前沿,通过学习和调整,我们将成功导航它。这里概述的方法是那个旅程中的第一步,确保即使在 AI 开发时代,项目团队仍保持控制并能在复杂性和不确定性中交付高质量结果。