AI 正在怎样改变软件工程团队的日常？

AI 编程工具的变化已经不只体现在“能不能补全一段代码”，而是团队开始同时运行多个代理、把任务从聊天工具交给云端系统处理。The Pragmatic Engineer 作者 Gergely Orosz 汇总了他对 AI 实验室、创业公司和大型科技公司的走访，也引用 GitHub、Linear 等公司的数据。他看到的变化很快，但随之出现的代码审查、系统质量、成本和工程师注意力问题，也没有自动解决。

原始来源：The state of the tech industry in 2026 - LDX3 New York。中文深度整理，非逐字翻译。本文依据演讲者在 The Pragmatic Engineer 发布的主题演讲整理，不是 YouTube 字幕；文中企业数据均归属于演讲者引用的来源。

工程师开始并行管理多个代理

Orosz 说，越来越多工程师不再手写每一行代码，而是把任务交给代理，并同时启动多个会话。Anthropic 的 Claude Code 创作者提到，他会在本地并行运行多个工作副本，也会同时让云端代理处理任务；Cockroach Labs 的 Peter Mattis 则说，自己通常会并行管理数个代理会话。

工作方式因此从“我写完这一段，再处理下一段”转向分配任务、核对结果和决定下一步。Orosz 还提到，越来越多开发任务从 Slack 开始：有人在频道里描述需求，由集成在公司工具链里的代理继续写代码、创建 PR 或调用测试。这种方式适合边界清楚的任务，但当代理越多，工程师也要处理更多相互等待的结果和上下文。

企业把代理接进自己的开发流程

演讲整理引用 GitHub 的数据：代理编写的 PR 在八个月里增长约九倍，2026 年 8 月，平台上的代理 PR 数量已超过人类直接编写的 PR。Linear 的数据也显示，代理创建的 issue 数量上升。Orosz 同时列举了多家公司建立内部开发代理和“软件工厂”：它们把 Slack、代码仓库、CI/CD、代码审查和部署连在一起，让代理不仅写代码，还能沿着公司的工作流程继续执行。

这种集成把开发代理从个人工具变成团队基础设施。它也增加了系统责任：代理是否有权访问生产环境、失败后如何回滚、谁负责审查它生成的改动，都必须由团队设计。演讲展示了采用趋势，却没有证明所有组织都能复制同样效果。

快速迁移省下时间，代码质量仍要追踪

Orosz 汇总了多个企业迁移案例：Anthropic 把 Bun 从 Zig 迁到 Rust，据报道用了 11 天；Uber 迁移几十万项 JUnit 测试，耗时数月；其他公司也用代理处理大量测试文件和 API 迁移。这些任务过去可能要花几年，但模型降低了修改成千上万文件的成本。

不过，变化越快，代码评审越容易跟不上。Orosz 转述一位工程师的观察：PR 数量上升后，团队的审查有时变成“盖章式”流程，成员没有足够时间逐项理解改动。Linear 的数据还显示，完全由代理完成的 PR 审查正在增加。对团队来说，减少手工逐行检查不等于风险消失；如果评审、自动测试和上线后监控没有同步加强，代码量增长反而会放大故障影响。

代理多了，费用和注意力也会被放大

AI 使用量上升会带来成本压力。演讲提到 Uber 通过开源模型和模型路由降低每 token 成本；这里的 token 是模型处理文本时计量的基本单位。对企业而言，选用更便宜的模型、把简单任务交给小模型、减少重复请求，都可能比单纯限制工程师使用更直接。

人的注意力也是有限资源。Orosz 引述一位工程师说，多个代理各自等待反馈，让他频繁切换上下文；原本一小时能完成的工作变多后，团队也会提高对每个人并行处理任务的期待。于是“更快”未必代表工作日缩短。企业需要同时观察交付量、错误率、返工和员工负荷，而不能只看代理完成了多少任务。

下一阶段更可能是团队仍在、工具链改变

Orosz 认为，云端开发代理和企业自建的运行环境会继续普及，工程师也可能越来越少逐行阅读模型生成的代码。但他同样强调，团队依然负责软件所有权、上线和 on-call；AI 高采用率的公司仍保留明确的工程团队。演讲里的趋势数据来自访谈、企业分享和行业样本，不代表整个软件行业都以相同速度变化。

真正需要验证的，是团队能否在代理提高产出的同时，保持系统可靠、让人理解关键设计，并避免审查变成形式。AI 让代码生成变便宜了，但如何决定该做什么、怎样验证结果，以及出了故障由谁处理，仍然是工程工作的一部分。