AI优先使命：这将是软件工程的未来吗？

越来越多的组织争相标榜为 “AI‑First”，并常常实施激进的使命，根本性地改变软件工程工作流。在一些极端情况下，工程师被要求不手写任何代码，而是依赖由 AI 代理和专有框架构成的复杂网络。虽然速度的承诺很诱人，但实际情况往往显示管理层的愿景与工程现实之间存在巨大的落差。

“AI‑First”使命的崛起

在最近一次软件工程师的讨论中，一位开发者分享了在一家财富500强前十公司里的惊险经历。团队的开发方式并非仅仅用 AI 增强工作流，而是彻底取代了人类的编码环节。这种 “AI‑First” 策略包括：

• 强制使用 AI：必须使用类似 Claude 的大语言模型，并配合包含超过 100 个代理和技能文件的专有框架。
• 代理驱动的代码审查：质量保证的人为环节正被自动化代理审查所取代。
• 理解的侵蚀：这种做法的一个关键副作用是工程师交付的代码他们并未完全理解，导致一种文化：没有人花时间深入了解系统架构。

这种转变导致文档和 Jira 任务中出现所谓的 “小说篇幅的废话”，这是 AI 能生成大量缺乏实质意义或精确性的文本的副产物。

工程界的反弹

有经验的开发者正在敲响警钟，认为这种做法违背了软件开发的核心原则。实践者的共识是，虽然 AI 能加速实现，但它无法取代可持续软件所需的批判性思维、产品判断和架构监督。

一位拥有 30 年经验的资深开发者将当前趋势形容为 “混乱、浪费且违背我对软件开发乃至基本沟通所学的一切”。

其他工程师注意到一种模式：管理层喜欢这些 AI 驱动团队的表面效率，但实际的工程组织对其产出缺乏信任。在某些情况下，这导致创建出没有用户、每天都有故障的工具（例如 MCP），形成一种掩盖系统性不稳定性的生产力假象。

编排 vs. 实现

尽管有诸多挫败感，人们仍认识到工作流正在改变。软件工程师的角色正从代码编写者转变为系统编排者。

我越来越像是一个编排者/审查者，而不是从头编写所有代码的人。AI 极大地加快了实现速度，但约束/产品判断仍然非常依赖人类。

这暗示了一种折中方案：让 AI 处理样板代码和实现细节，而人类专注于高层设计、约束以及产品‑市场匹配。当 “编排者”被迫交付他们不理解的代码时，便失去了人类理解的安全网，风险随之而来。

结论：不确定的状态

行业目前正处于动荡之中。有些人将当前的 AI 驱动混乱视为 “哀伤” 或幻觉的暂时阶段，而另一些人则认为我们只是在探索新的最佳实践。

无论 “AI‑First” 使命是可持续的模式还是企业幻想，有一点是明确的：时间无法倒退五年。下一代软件工程面临的挑战是寻找 AI 生成速度与人类理解严谨性之间的平衡。