2026 年科技行业的真实状况｜LDX3 纽约主题演讲

Gergely Orosz 以走访 AI 实验室、大型科技公司和初创企业，以及与从业者的交流为背景，将演讲分成四部分：什么变了，什么没变，什么出了问题，以及接下来可能发生什么。

这个取样范围很重要。前沿组织中出现的模式，能为可能的发展方向提供线索，但不是所有软件团队的代表性调查。产品名称、采用比例和迁移周期都属于录制时的语境，本文把它们作为有归属的观察，而不是实时市场清单。

Orosz 描述，工程师越来越多地提示、检查和协调多个智能体，而不是把全部时间用于手写一份实现。一些受访者同时运行多个工作树和会话，因此本地键盘操作不再是并发工作的唯一限制。

他也观察到，交互入口正从重量级 IDE 向智能体工作空间和聊天入口扩展。这不能证明所有 IDE 都已消失，也不意味着每位工程师都该照搬五到十个会话的配置。执行并行度提高，会带来新的协调与注意力问题，演讲后半段还会回到这一点。

演讲列出多家自行建设内部运行框架或扩展现有工具的组织。反复出现的原因，是接入公司特有的数据、环境和流程。Slack 中的一句请求能够变成编码任务，是因为智能体连接了让这句话具有实际意义的系统。

Orosz 描述了一些软件工厂循环：生产观察或其他智能体输出，可以引出代码变更。他明确说，这些系统尚未完全自动化，关键或影响范围大的变更仍涉及人工审查。需要区分的是有检查的闭环，与无人负责的生产自主权这种强得多的说法。

演讲举出多项语言或测试框架迁移，相关团队据称借助 AI 更快完成。它们可能是实质性改动，不只是替换一个依赖名称，但范围和起点各不相同。

Orosz 在 Asana 案例中保留了重要限定：最后那段很短的迁移之前，已经有多年准备。最终执行窗口，不能代替准备、验证和上线的全部成本。这些例子提示某些过去被搁置的工作变得更可行，但不能建立“多年工作一律压缩成几周”的换算公式。

演讲中的厂商和平台数据，显示智能体创建工单、代码变更和使用技能的活动增长。这些测量描述的是特定系统和用户群，能够说明活动量，却不能单独衡量正确性、客户结果，或整个行业采用同类流程的比例。

成本讨论也需要类似区分。路由优化和开放模型投入，可能降低单位成本或帮助控制支出，但用量增长仍会改变总账单。组织要问的是系统以何种成本交付了什么有用工作，而不只是产生了多少生成物。

Orosz 观察到，个人能够跨越过去的技术专门领域，以更少人手承担项目。但他又单独强调，团队仍负责软件、值班、质量标准，以及成员休假时的连续性。

这两点并不冲突：一个人完成的实现项目，不等于取代长期负责服务的团队。演讲中“非工程岗位并未独立发布生产代码”的说法，也需要限定范围：请机器人发起变更，与批准并运营一次发布，是不同责任。公司个案不能直接变成适用于所有组织的断言。

13:05查看原图

复杂基础设施仍需要规划、跨团队对齐和客户沟通。更快地做出错误的东西，仍然是浪费。Orosz 也强调，测试及其他验证方法，是让生成代码值得信任的重要方式。

他提到，曳光弹式推进、深模块等旧工程思想重新受到关注。价值不在于某个词能神奇地修好模型，而在于这些思想为实现与判断提供了有用结构。生成加速改变了工作方式，却没有替人回答结果是否正确、是否值得维护。

Orosz 警惕“审查表演”：变更量太大，难以仔细查看，却仍保留形式上的批准。他还报告软件质量问题和基础设施容量压力，包括某些场景下 CPU 供应紧张。

这些观察不是证明 AI 导致每次故障的受控实验，也不意味着所有云区域都面临同样短缺，更不能据此一概取消审查。它们提醒团队，需要让验证与审查投入匹配风险，同时认真规划容量和人的注意力预算。

演讲中的一位工程师描述，最初加速完成任务令人兴奋，后来并行工作却成为新的基本预期。即使别的任务还在推进，一个等待回应的智能体，也可能不断打断专注。

Orosz 与工程负责人的交流还呈现出多种压力：不现实的预期、业务不确定性、团队规模变化，以及疲惫。这是一组被选择的访谈，不是对每位负责人的诊断，也不是每份工作的未来预测。运营上的启示是，协调与恢复成本也应当和生成产量一起计算。

展望未来，Orosz 预期云端运行框架、交付管道中的评测，以及参与运营的智能体会增加。他把孤立的个人自动化，与从业务结果出发、减少团队或公司层面交接和摩擦的系统作了区分。

这些仍是预测和建议，不是普遍允许发布未读代码，也不是说迁移已经没有风险。结尾强调亲自学习与领域判断：当实现成本下降，知道什么重要、并推动他人行动的能力可能更有价值。演讲鼓励实践，却不能证明任何职业都已免受未来变化影响。

26:10查看原图