技术报告：软件工程的未来 - 研讨会结论与战略洞见

译者注

君以此始，必以此终

译者最近一个月才开始接触氛围编程，使用 Claude Opus 模型完善去年开发的一个试验项目 (mcv-workflow)，大受震撼，感觉大模型在 ecFlow 这类领域特定工具的编程能力上都已经碾压我了。

由 thoughtworks 公司撰写的这篇研讨会总结报告正是对软件工程正在发生变革的一个写照。 没有人能说清未来会最终变成什么样，但所有人都认为未来一定不是现在这个样子。 推荐各位程序员朋友阅读。

The future of software engineering - Retreat findings and strategic insights

原文链接： https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf

以下正文内容使用 ChatGPT 和 Grok 翻译自原文，并根据译者理解有所修改。

正文

感谢各位参与本次研讨，共同探讨在 AI 重塑软件构建方式的背景下最关键的问题。 以下内容是对各分组讨论成果的综合提炼与总结。

本次研讨遵循查塔姆宫守则 (Chatham House Rule)，因此本文不披露任何参与者姓名或机构信息。

2026 年 2 月

执行摘要

来自多家大型科技公司的资深工程实践者齐聚一堂，参加为期数日的研讨，直面 AI 正在改变软件开发所带来的核心问题。 讨论涵盖二十多个主题，但最重要的洞见并非来源于某一场单独的会议，而是出现在不同议题的交汇处。 我们发现，同样的关切在不同的人、不同的场景中反复出现。

本报告提炼了这些跨领域的主题，并围绕当前管理者亟需理解与应对的模式进行组织。 本次研讨会并未形成一个统一的未来蓝图，但产出了更具价值的成果：一张“断层图”，标示出当前实践正在失效之处，以及新范式正在形成之地。

”我们在每个房间都反复问同一个问题：如果 AI 负责写代码，那工程到底去哪儿了？没有人给出相同的答案，但所有人都认同这个问题已经迫在眉睫。“

主题一览

每个主题的详细发现如下。

1. 严谨性将走向何处？

这是本次研讨中最重要的问题，在几乎每一场讨论中都出现。

如果 AI 接管代码生产，那么原本存在于编写和审查代码中的工程纪律 (engineering discipline) 并不会消失，而是转移到其他地方。 本次研讨会在这一问题上投入的时间超过任何其他议题，并从多个视角进行了探讨，包括代码审查、测试、语言设计、自愈系统以及组织设计。

小组识别出严谨性正在迁移的五个主要方向：

向上游迁移：进入规格说明审查

一些实践者报告称，他们正在将审查工作从代码转移到代码之前的规划阶段。 一位参与者描述说，他们更关注“预审查计划 (pre-reviewing the plans)，后审查工程 (post-reviewing engineering)”，而不是审查代码本身。 逻辑很简单：如果 AI 根据规格 (spec) 生成代码，那么规格就成为捕捉错误的最高杠杆点。 不良的规格会大规模产生不良代码。

这带来了实际影响。 正在尝试以规格驱动开发 (spec-driven development) 的组织发现，规格本身需要新的表达形式。 传统的用户故事过于模糊。 一些团队正在采用更结构化的方法，例如 EARS (Easy Approach to Requirements Syntax)、状态机和决策表。 这些并非新技术，但之所以被重新发掘，是因为它们能够为 AI agent 提供足够的精确性，从而生成正确的实现。

向测试迁移：测试套件成为一等公民

本次研讨中一个最具传播价值的洞见是：测试驱动开发 (test-driven development, TDD) 可以显著提升 AI 编码 agent 的结果质量。 其机制是明确的：TDD 能阻止 agent 写出验证错误行为的测试。 当测试先于代码存在时，agent 就无法”作弊“，无法写一个只是确认自己错误实现的测试。

这将 TDD 重新定义为一种提示工程 (prompt engineering)。 测试成为非确定性生成的确定性验证工具。 多位实践者描述，他们已将全部审查工作转移到测试套件上，并将生成的代码视为可抛弃品。 如果测试是正确的，且代码通过测试，那么无论代码的具体形式如何，都可以接受。

实践者观点

“我从 TDD 和 agent 编码中获得的效果，比我以往任何地方都要好，因为它能够阻止一种特定的思维错误：agent 编写测试来验证其错误行为。”

向类型系统与约束迁移

与会者强烈关注利用编程语言特性来约束 AI 生成的代码。 与其在生成后审查代码，不如让错误代码根本无法表达。 这一思路源自形式化方法和强类型系统，但其应用不再是学术性的，而是作为 agent 输出的实际防护措施。

一个关键洞见是区分“规格 (specifications) ”和“约束 (constraints)”。 规格描述应该发生什么变化；约束定义允许变化发生的边界，包括哪些内容不得被修改。 这些约束限制了影响范围，使 agent 能够在不同领域边界之间安全工作。 当必须突破某个约束时，这就表明需要引入新的系统边界，并触发重构。

向风险映射迁移

并非所有代码具有相同的风险。 与会者讨论了根据业务影响范围对代码进行分级，将内部工具、对外服务以及安全关键系统 (safety-critical systems) 区分开来。 这种风险映射决定了哪些地方必须进行人工审查，哪些地方可以依赖自动化验证。

一位实践者将其描述为新的核心工程纪律：组织不应再问“这段代码是否经过审查”，而应问“如果这段代码出错，其影响范围有多大？我们的验证手段是否与风险相匹配？” 这使工程从一种工艺模型 (每一行代码都由人工审查) 转向一种风险管理模型 (验证投入与风险暴露相匹配)。

向持续理解迁移

如果代码变更速度超过人类审查能力，那么通过代码审查建立心智模型的传统方式将失效。 与会者讨论了一些替代方案：

• 每周架构复盘
• 多人协作编程 (多个工程师同时处理同一段代码)
• 能够按需生成系统概览的 AI 辅助代码理解工具

这一问题背后的担忧是真实存在的。 一位实践者指出，代码审查在历史上不仅是质量控制手段，也是学习机制。 导师指导、共享理解以及对代码库的熟悉都通过审查实现。 如果失去这一渠道而没有替代机制，将会形成随时间累积的理解缺口。

“结对编程可以解决这一切。如果理解系统是重要的，那就应该始终进行，而不是分阶段地通过代码审查来理解。应持续不断地尝试理解代码在做什么。”

2. 中间循环：一类全新的工作

这是本次研讨会中最强有力的“先行者”概念。业界尚未为其命名。

长期以来，软件开发通常被描述为两个循环：

• 内循环是开发者个人的循环，包括编写、测试和调试代码
• 外循环是更广泛的交付循环，包括 CI/CD、部署和运维

本次研讨会识别出了第三个循环：位于两者之间的“中间循环”，即一种监督型工程工作 (supervisory engineering work)。

这一中间循环的工作包括：对 AI agent 的输出进行指导、评估和修正。 这类工作需要与编写代码完全不同的技能集：

• 将问题拆解为适合 agent 处理的工作单元的能力
• 校准对 agent 输出的信任
• 识别 agent 产生“看似合理但实际错误”的结果
• 在多个并行的 agent 生成工作流中保持架构一致性

在这类新型工作中表现突出的实践者通常具备以下特征：

• 他们以委派 (delegation) 和编排 (orchestration) 为思考方式，而非直接实现 (direct implementation)
• 他们对系统架构具有清晰的心智模型
• 他们能够在不逐行阅读代码的情况下快速评估输出质量

这些能力往往存在于经验丰富的工程师身上，但在职业发展体系中很少被明确培养或认可。

职业影响

中间循环给那些热爱编程的开发者带来了真正的身份认同危机。 许多人正是因为能将已拆解好的需求转化为可运行代码而被雇佣，但这类工作正在消失。 新的工作需要不同的能力，也需要不同的职业满足感来源。 如果组织不能帮助这些人完成转型，最有经验的人才将因挫败感而流失。

研讨会将这一变化与计算机图形学发展历史类比。 在 1992 年，工程师需要手工编写多边形渲染算法。 两年后，这项工作被下沉到硬件层，工程师的工作转变为动画和光照。 再到今天，工作变成了自定义物理和游戏世界。 每当抽象层提升时，那些坚持认为自己职责只是“渲染多边形”的工程师都会被淘汰。 现在代码生产领域也正在经历同样的动态。

产品管理侧同样处于不稳定状态。 如果开发者开始更多思考“做什么”和“为什么做”，他们实际上正在承担原本属于产品经理 (Product Manager, PM) 的工作。 一家大型科技公司正在研究是否需要为产品经理这一角色重新命名。 另一家公司则在培训所有产品经理在开发工具中使用 Markdown 工作。 角色融合已经发生，只是大家尚未就最终形态达成一致。

3. Agent 拓扑与企业架构

康威定律 (Conway’s Law) 并没有失效，而是变得更加复杂。

本次研讨会提出了“agent 拓扑” (agent topologies) 的概念，作为对团队拓扑 (team topologies) 框架的延伸。 其基本前提是：如果组织设计的系统会映射其沟通结构，那么当 agent 成为这些结构中的一等参与者时，会发生什么？

与人类不同，agent 可以被瞬间复制，并部署到多个团队中，而无需入职培训的成本。 一个专用的数据库 agent 可以同时存在于每个团队中，提供一致的专业知识，而不会出现单个人类数据库专家带来的中心化瓶颈。 这听起来是纯粹的胜利，但研讨会也指出了几个复杂因素。

速度不匹配

agent 能极快地清空待办事项，却会撞上缓慢的组织依赖。 一位参与者描述了这种体验：给一个团队配备 AI 工具后，他们可以在几天内清空待办事项，但随后就会撞上跨团队依赖、架构审查以及人类决策速度所形成的瓶颈。 结果并不是更快的交付，而是同样的速度却伴随着更多的挫败感，因为瓶颈从工程能力转移到了其他一切环节。

Agent 漂移

从其上下文中学习的 agent 会随着时间发生分化。 即使从相同配置开始，负责电商后端的数据库 agent 会逐渐形成不同于 ERP 系统中数据库 agent 的模式与偏好。 这类似于人类团队中形成各自规范的问题，但发生速度更快。 研讨会讨论了这种漂移是应当被管理 (类似于团队标准化)，还是应当被接受 (类似于团队本地优化)。

决策疲劳成为新的瓶颈

当 agent 产出工作的速度超过领导者审查与批准的能力时，约束将从生产能力转移到决策能力。 过去作为协调节点的中层管理者，现在可能成为审批瓶颈。 多位实践者报告称，这种情况已经在其组织中出现：agent 生成职位规格、代码修复和功能实现的速度，远快于任何人说“Yes”的速度。

研讨会提出了一个尖锐问题：如果人类理解系统的能力存在上限，而 agent 没有，那么我们是否还需要同样数量的中层管理者？小组未达成共识，但这一问题本身已经预示着未来的重大组织挑战。

“我们曾为人类优化软件交付流程。现在既然不再只有人类参与，我们就必须重新思考‘组织’本身意味着什么。”

4. 自愈与自我改进系统

雄心真实存在，但前提条件远未具备。

本次研讨会探讨了软件系统是否可以从人工驱动的事故响应，转向由 agent 辅助的自愈。 小组区分了两个层次的目标：自愈 (self-healing，将系统恢复到已知的良好状态) 以及自我改进 (self-improving，主动提升系统的非功能特性，如性能与可靠性)。

尚未具备的前提条件

实现自愈需要大多数组织尚未具备的几项基础条件：

• 对每一次变更的清晰记录，使 agent 能够理解发生了什么
• 面向 agent 的操作系统，具备身份控制与权限边界
• 强大的通用缓解能力 (mitigation capabilities, 如回滚、功能开关)，且无需修改代码即可生效
• 用于定义“健康状态”的适应度函数 (fitness functions)，并能被 agent 评估

研讨会给出的结论非常直接：在事故修复中，代码变更应当是最后手段。 通往自愈的路径，应优先依赖更完善的回滚机制、功能开关和可观测性，而不是依赖 agent 去重写生产代码。

隐性知识问题

资深工程师在事故响应中依赖多年积累的模式识别能力。 他们知道某个特定错误码实际上是更深层基础设施问题的表现； 他们知道某个服务 CPU 使用率升高时，应优先检查数据库连接池。 这类知识几乎从未被记录下来，而是存在于人的经验之中。

要让 agent 具备类似能力，组织需要构建研讨会中所称的“agent 潜意识”：一个由多年事后复盘 (post-mortem) 和事故数据构建的知识图谱，为 agent 提供解释实时信号所需的历史上下文。 一些组织已经在通过自动生成事后复盘文档来推进这一方向，但其中由人类补充细节与上下文的步骤仍然至关重要。

事故指挥官问题

人类事故指挥官会质疑假设、挑战表面合理的解释，并维持整体态势感知。 而大语言模型往往倾向于正向强化和附和。 要构建有效的 agent 事故指挥官，必须解决这种行为模式上的差异。 一种建议是训练“愤怒型 agent”，专门设计用来挑战主导假设。

Agent 协同风险

当多个 agent 同时尝试修复同一问题时，可能会形成反馈循环：一个 agent 的修复触发另一个 agent 的修正，从而形成不断升级的循环。 研讨会引用了一个真实案例：一个 agent 在面对限制文件长度为 500 行的代码规范时，通过增加每一行的长度来满足规则，从形式上符合约束，但违背了规则背后的原则。 当多个 agent 在权衡取舍时做出不同优先级决策，系统可能会在不同状态之间振荡，而无法收敛。

5. 人的因素：角色、技能与体验

AI 并不是在取代人，而是在重塑人们所做的工作，以及他们对这些工作的感受。

生产力/体验悖论

开发者体验 (developer experience) 传统上由三个维度构成：心流状态 (flow state)、反馈循环 (feedback loops) 以及认知负荷 (cognitive load)。 长期以来，生产力与开发者体验是紧密耦合的；本次研讨会发现证据表明两者正在发生分化。 组织即使在开发者报告满意度更低、认知负荷更高以及心流体验更弱的环境中，仍能通过 AI 工具提升生产力。

这带来了一个真实的困境。 如果组织可以在不改善开发者体验的情况下获得更高产出，那么投资开发者体验的商业理由将被削弱，除非开发者体验本身的定义随 agent 监督工作的新现实而演进。 一位实践者提出了一个重新表述：不要再称之为开发者体验，而应称为“agent 体验”。 为提升 agent 表现而投入的条件，更容易获得预算支持，而这些条件与促进人类良好表现的条件在很大程度上是重合的。

资深工程师承受压力

资深工程师比以往任何时候都更加重要，同时也承受着更大的压力。 一家研究机构对 500 家公司的数据分析显示，资深工程师使用 AI 工具的频率低于初级工程师，但一旦使用，他们每周节省的时间更多。 他们对系统架构更深刻的理解，使其在监督 agent 时更加高效。

矛盾之处在于他们被要求做的工作与他们应当做的工作之间存在差距。 许多资深工程师将大量时间花在人员协调上，而非技术监督。 研讨会认为应当进行有意识的转变：资深工程师应成为“摩擦消除者”，识别并移除阻碍人类和 agent 工作的障碍。 他们对“骷髅埋在哪里”了如指掌，使其非常适合这一角色，但许多人因长期被告知“没有预算支持改进”而产生了习得性无助。

初级工程师更有价值，而不是更少

研讨会对“AI 会消除初级工程师需求”的观点提出了挑战。 初级工程师比以往任何时候都更具经济价值。 AI 工具帮助他们更快度过最初的“负产出阶段”；他们相当于未来生产力的“看涨期权”；并且由于没有既有习惯和假设的束缚，他们比资深工程师更擅长使用 AI 工具。

真正令人担忧的是过去十年招聘热潮中成长起来的中级工程师，他们可能没有打下足够扎实的基础来适应新环境。 这部分人群占行业人数的绝大多数，对其进行再培训极具挑战。 研讨会讨论了学徒制、轮岗机制以及终身学习体系是否可以弥补这一差距，但也承认目前尚无组织真正解决这一问题。

教育信号

研讨会提到滑铁卢大学 (University of Waterloo) 的合作教育 (co-op) 项目作为一个范例：扎实的理论基础与长达 2.5 年的行业实习 (六次四月轮岗) 相结合。 毕业生同时具备 AI 工具无法取代的基本功和实践判断力。 多家公司报告称，相比传统的毕业生招聘，通过实习转正渠道的表现更优。

产品管理的未来

在 AI 驱动的世界中，没有人能够清晰定义产品经理将承担什么角色。 一些组织正在将产品经理推向更技术化的工具环境，培训他们在 Markdown 和开发工具中工作。 另一些组织则认为角色将进一步分化：产品经理成为战略协调者，而开发者承担更多战术层面的产品决策。

可以确定的是，AI 正在暴露产品经理与开发者关系中原有的功能失调，而不是创造新的问题。 知识碎片化、不同职能之间的文化差异以及角色边界不清等问题在 AI 出现之前就已存在，只是现在变得更难忽视。 研讨会强调将工具作为“边界对象” (boundary objects)，使不同角色能够以自己的方式工作，同时保持共享的可见性。

6. 技术基础：语言、语义与操作系统

面向 agent 时代的基础设施尚不存在。这些是正在逐步构建的组成部分。

面向 agent 的编程语言

现存的所有编程语言，都是以人类为主要使用者设计的。 动态类型 (dynamic typing) 是为了降低人类程序员的认知负担；强静态类型 (strong static typing) 是为了捕捉人类错误。 研讨会提出了一个问题：专为 agent 生成代码设计的语言会是什么样子？这样的语言是否也会更适合人类？

小组在一个原则上达成了一致：对 AI 有利的，也对人类有利。 通过强类型 (strong types)、受限计算模型 (restricted computation models) 以及形式化约束 (formal constraints)，使错误代码无法表达的语言，有助于 agent 生成正确结果，也有助于人类进行验证。 相反，强调表达能力而非安全性的语言，会同时增加 agent 生成和人工审查的难度。

一个更激进的可能性是：我们所熟知的源代码，可能会成为一种短暂存在的产物，按需生成而不被存储。 对此，研讨内部存在分歧。 一些人认为源代码将在十年内消失；另一些人则认为，确定性验证需要一个稳定的产物作为测试对象，而这个产物本质上就是源代码，无论我们如何命名它。

语义层与知识图谱

那些几十年来未能获得主流应用的技术，正在重新变得重要。 语义层 (semantic layers)、知识图谱 (knowledge graphs) 以及领域本体 (domain ontologies)，被重新发掘，成为 AI agent 理解业务领域的基础层。 研讨会包括一些正在大规模构建此类系统的实践者，他们报告称，一个大型电信公司的整个领域本体可以用大约 286 个概念来表示。 这一数字使得该工作看起来是可实现的，而不是不切实际的宏大工程。

其实际价值体现在遗留系统的现代化中。 通过从现有系统构建概念数据模型，并与领域专家进行验证，组织可以创建 agent 所需的规格层，从而有信心地推进现代化改造。 一个团队描述了其做法：利用大语言模型自动识别代码中的命令、事件、聚合和策略，从而自动生成事件风暴 (event storming) 工件。 随后由人类专家进行验证与修正，将原本需要数周的探索工作压缩到数天完成。

面向 agent 的操作系统

研讨会探讨了一个面向 agent 的操作系统需要具备的能力：

• agent 身份与权限管理
• 内存与上下文窗口管理
• 一个工作账本 (work ledger)，用于记录未来、当前和过去的工作，并包含所需技能、验收标准、服务级别目标 (SLO) 以及成本约束等属性
• 通过 agent 能力与合规要求构成的图谱进行治理路径管理

一个核心洞见是：agent 不仅仅由其角色设定、目标或当前上下文构成，还包括其历史工作记录。模型在 agent 内部是可替换的 (可以替换一个大语言模型为另一个)，但更换模型会从根本上改变 agent 的行为，因此必须被记录。 工作账本被视为这一新型操作系统的核心原语，类似于金融领域的区块链：可搜索、可审计，并使 agent 能够发现任务并进行竞标。

7. 安全、治理与敏捷的未来

安全严重滞后

研讨会担忧地注意到安全议题的讨论参与度较低，这反映了行业普遍现象：安全通常被视为在技术可行且可靠之后再解决的问题。 但在 agent 时代，这种顺序极其危险。

最直观的例子是：一旦授予 agent 访问电子邮件的权限，就能实现密码重置和账户接管。 为开发工具授予整机访问权限，也意味着 agent 可以执行其所决定的一切操作。 研讨会提出的建议非常直接。 平台工程应通过“安全默认”来主导，使安全行为变得容易，而不安全行为变得困难。 组织不应依赖个体开发者在配置 agent 权限时自觉做出安全意识强的选择。

提出了三个优先方向：

• 将“设计即安全”作为不可协商的基线
• 推动跨行业联盟，制定可互操作的 agent 安全标准
• 构建 AI 驱动的防御机制，以匹配 AI 驱动攻击的速度与复杂性

敏捷正在演进，而非消亡

研讨会明确反对“敏捷已死”的说法。实际发生的是更复杂的变化。 一些团队正在将迭代周期压缩到一周，并使用 AI 自动化迭代末端的流程，例如演示、报告和状态总结。 另一些团队则重新采用极限编程 (XP) 实践 (如结对编程、群体开发、持续集成)，因为这些实践能够提供 agent 辅助开发所需的紧密反馈循环和共享理解。

真正威胁敏捷的是治理 (governance)。 即使团队通过 AI 工具提升了工作速度，仍然会受到相同的审批流程、合规关卡以及组织依赖的限制。 如果不同时改革治理机制，那么更快的团队只会更早撞上相同的瓶颈。 研讨会强调，在重新设计团队实践时，应尽早让内部审计和治理职能参与，而不是将其视为后期需要应对的障碍。

随着变更批量的增加，软件稳定性也在下降。 AI 工具使得生成大规模改动变得容易，这正促使部分团队回到类似瀑布模型的模式，以大规模、低频次发布取代小规模、高频次发布。 这直接逆转了过去十年 DORA 研究的结论，即较小的变更批量与更高的稳定性正相关。 研讨会将这一现象视为一种正在发生的倒退，并认为需要引起行业关注。

8. Agent 集群：超越顺序思维

本次研讨会专门讨论了 agent 群体协作 (agent swarming)，并得出了一些挑战传统认知的重要洞见，即 AI 辅助工作的组织方式可能与以往假设截然不同。

实现有效群体协作的首要障碍是心智层面而非技术层面。 习惯于顺序分解问题的工程师，往往难以构想并行 agent 工作模式。 这种思维模型本身会阻碍学习。 那些在群体协作方面取得突破的实践者表示，这种体验与他们以往的软件开发经验完全不同。 仅仅是明确要求 agent 并行处理任务，并观察结果，其学习效果就超过任何理论框架。

对于企业级应用场景，研讨会识别出一个重要模式：单个 agent 的完美准确性不如整体向目标收敛更为重要。 只要系统架构能够引导收敛，由多个并不完美的 agent 组成的群体也可以产生有价值的结果。 这一原则源自分布式系统和生物群体智能，被应用于 agent 编排中。

研讨会还指出，在大多数企业场景中，agent 编排并不会表现为典型的“群体协作”。 更常见的模式是“循环巡检工作者 (patrol workers on loops)”：agent 持续运行定义明确的 ETL 转换、数据质量检查以及业务流程监控。 换句话说，就是那些不那么引人注目的数据可靠性与数据清洁工作持续在后台运行。 具备良好 API 设计的组织，在群体协作和巡检式 agent 部署方面，明显优于缺乏此类基础的组织。

模型局限性

一些前沿模型在结构上存在弱点，使其不适合用于群体协作场景。 这正在影响评估方法的设计，人们预期随着这些局限被更好理解，面向群体协作的架构将得到改进。 在为 agent 部署选择模型时，组织应专门测试多 agent 协同能力，而不仅仅是单 agent 能力。

9. 开放问题

本次研讨会提出的问题多于答案。以下是最令与会者持续思考的问题。

关于工作与身份认同

如何帮助热爱编写代码的工程师，在以监督型工程为主的工作中找到意义与满足感？
有哪些职业发展路径可以通向“中间循环”？
如果产品经理与开发者角色正在融合，那么新的角色将被称为什么？由谁来承担？

关于组织设计

如果 agent 使中层管理瓶颈更加显露，组织的应对是减少管理者数量、改变其技能结构，还是构建一种全新的协作模型？
当 agent 可以跨团队边界流动，而治理结构却不能时，应如何重新设计企业架构？

关于信任与验证

在什么条件下，组织可以完全停止对 AI 生成代码进行人工审查？
是否存在一个世界，测试套件与约束机制足以提供验证，而无需人工检查？
如何在本质上具有非确定性的系统中建立信任？在这些系统中，相同输入可能产生不同输出。

关于知识与理解

当代码变化速度超过人类理解能力时，我们是否需要一种新的方式来维护组织知识？
知识图谱与语义层，是否真的能够取代长期在代码库中工作所积累的人类直觉？
对于大多数组织尚未构建的“agent 潜意识”系统，应投入多少资源才是合理的？

关于速度与稳定性

我们是否正处于一种倒退状态：AI 带来的生产力提升，被更大批量变更导致的稳定性下降所抵消？ 开发是否需要放慢速度，因为决策数量已经超过人类评估能力？
我们应如何衡量随着时间累积的认知债务的真实成本？

接下来会发生什么

本次研讨会呈现出一个一致的模式：为纯人类软件开发所构建的实践、工具与组织结构，在 AI 辅助工作的压力下，正以可预期的方式失效。 替代方案正在形成，但尚未成熟。

已经准备好进入更广泛行业讨论的理念包括：

• 监督型工程“中间环”
• 将风险分层作为新的核心工程纪律
• 将 TDD 视为最有效的提示工程形式
• 将开发者体验重新表述为 agent 体验

对于这些主题的深入探讨将在后续展开。

同样重要的是那些尚未得到解答的问题：

• 如何帮助人们完成职业身份的转变
• 如何治理一个 agent 行动速度快于人类决策速度的组织
• 如何在本质上非确定性的系统中建立信任

这些并不是仅靠技术手段可以解决的技术问题，而是需要坦诚对话与协作的人类问题。 我们将在未来数月持续参与这一进程。

“本次研讨没有给出一份路线图。它提供的是一种共识：地图正在被重新绘制，而最有能力绘制这张地图的人，是那些愿意承认自己尚有大量未知的人。”

正文部分结束，以下为译者添加

参考

原文：The future of software engineering - Retreat findings and strategic insights