AI 让新一代工程师更像工头

博途PLC工程智能体 | AI智能体博途网关 | 博途PLC程序知识图谱 | 梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 逆向生成程序块文档 | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI

过去几十年里，人类劳动经历了多次革命，每一次都催生了新职业，也让另一些职业走向终结。曾几何时看似坚不可摧的软件职业，如今被普遍视为人工智能冲击下最显眼的"受害者"之一。表面上看，这种担忧不难理解。

过去几年，大多数企业大幅加快了代码产出速度；与此同时，CIO 们在年初报告称，科技行业的裁员浪潮达到了 2024 年以来的最高峰。如果我想，现在用 AI 几天就能搭出一个能跑的 CRM，而不是几周。想到这一点，高管们重新审视实现业务目标究竟需要多少工程编制，也就合情合理了。但那个 CRM 真的够用吗？真的能安全地处理敏感的客户与业务数据吗？这些领域需要熟练的人类判断，所以我劝他们三思。

AI 确实改变了软件职业的传统路径，但知识、技能和软件工程经验的价值并未改变。正如 Faros AI 在其近期的开发者报告中发现的：AI 提升了个体编码者的速度，但在收益到达团队之前，评审和返工就把它们吞掉了。无论软件团队现在能以多快的速度产出代码，管理不善的项目仍会带来令人失望的结果。而且，按照企业需要追赶竞争对手的部署节奏，它们需要的是对组织有深刻理解的人，来引导 AI 生成的软件走向正向结果。

"软件工程师正受到 AI 威胁"这一结论，其实源于对他们真正擅长之事的误解。代码产出只是次要的；真正优秀的软件工程师，其价值在于他们的思维方式。这就是为什么我坚信：随着 AI 的到来，对这些头脑的需求会上升，而不是下降。

1、杰文斯悖论

当新的资源提升了效率，人们本能地认为该资源的消耗会下降；但杰文斯悖论（Jevons paradox）观察到，事实往往相反。煤炭和蒸汽让工厂效率更高，结果促使更多大亨开办工厂，总消耗反而上升。随着我们越来越擅长发电，我们找到了更多用电场景，如今的消耗量早已远远超出人们曾经以为的可能。

杰文斯悖论并不意味着效率提升后需求一定会增长，但它是一个有用的透镜，帮助我们理解软件工程为何能在 AI 浪潮中存活。根据 GitHub 的 2025 Octoverse 报告，开发者在 2025 年推送了近十亿次提交，同比增长 25.1%。随着开发成本降低，此前不可行的产出水平变得可以实现，企业对更多功能和价值的需求也在水涨船高。

因此，能够用 AI 加速业务价值的软件工程师，被要求创造更多价值，是顺理成章的。闭环由此形成：随着我的业务用更多代码产出更多价值，我倾向于雇佣更多软件工程师来管理更多的智能体团队，而不是更少。

就业前景给了 CIO 们另一个理由，避免基于短期兴奋做条件反射式的人事决策。2026 年 7 月，美国劳工统计局预测，软件开发者数量将从 2024 年到 2034 年增长 15.8%，新增 267,700 个岗位——即便已计入 AI 技术的扩散。这些岗位的形态会改变，但能把技术能力转化为业务价值的人的需求，并不会消失。

2、懒进，懒出

AI 只有在你能应用它而不外包自己思考时，才会成为加速器。让 AI 替你写一份战略文档，和让 AI 挑战你已经为任务打下的思考基础，是截然不同的两件事。把 AI 当作打磨工作的"陪练"，而不是对它产出的东西照单全收，自然会带来好得多的结果。

这正是我们这些负责招聘的人——包括我自己——希望在软件团队中培养的心态。AI 放大了"让优秀软件工程师脱颖而出的那种思考"的价值。他们需要理解自己为什么在做这些任务、他们的组织因何与众不同，才能真正做出贡献。初级开发者的典型工作通常是处理工单，但这项技能的优先级下降，并不会抽走他们成长的地基；相反，这应该腾出更多时间，让他们了解组织、成长为更好的问题解决者。

我把智能体视为虚拟同事。我不会雇一个同事，然后指望他交回来的第一份工作就完美无缺。同事需要被有效地引导入职，并获得关于组织及其目标的上下文，才能开始产出价值。一个上下文不全的懒惰提示词，只不过是更快地制造出一个"看起来合理但没解决正确问题"的东西。

3、软件工程师作为工头

管理 AI 辅助团队的软件工程师，正变得越来越像"工头"——设定工作方向、确保智能体获得正确的上下文，并在产出不达标时介入。Gearset 的研究发现，82% 的 Salesforce 团队信任 AI 承担构建阶段的任务，但到发布阶段这一比例显著降至 58%。常规配置变更和编写测试曾经是人工且耗时的工作，如今是团队最放心委托给 AI 的任务。这让工程师有更多空间去管理任务委派，并有策略地在 AI 上建立信任。

AI 在大型组织中打开了更多可以更快推进的工作流，这意味着质量控制如今成了首要任务。这为软件工程师设定意图、执行标准、更贴近业务创造了机会。

这一变化对初级工程师也有影响——他们传统上是通过完成常规工作来熟悉代码库的。如果 AI 承担了所有这类工作，领导者在招聘早期职业阶段的工程师时就必须更有针对性：训练他们解释项目背后的思路，并更多地参与架构讨论。目标不是为了制造工作而制造工作，而是保存并发展那些帮助企业维持规模化质量的问题解决能力。

这些技能并不新鲜：只是随着编码流程提速，优先级的顺序变了。

4、安全部署，否则别部署

质量控制是 AI 编码带来的首要挑战，也是工程师最能发挥作用的地方。他们为 AI 产出和人类工作定义"什么算好"，并确保所有软件变更既能安全地进入生产环境，又与其业务目标相关。

软件工程师提供确保代码真正就绪投产所需的上下文与经验。智能体可以生成一个孤立来看似乎正确的变更，但它未必反映了周边架构，也未必考虑了故障对客户和员工的后果。

这就是为什么，对那些能把更高产出转化为安全、有用部署的工程师，需求会持续改善。AI 生成的变更必须通过与人类编写工作相同的版本控制、测试、安全扫描、审批和审计流程，这一点至关重要。工程师必须设定这些标准，并找出确定性检查可以替代人工评审的合适位置。工程师将在帮助 CIO 决定哪些工作可以放心地委托给 AI 方面发挥巨大作用，同时在需要人类监督的环节保持团队问责。

因此，工程师的角色从编写每一行代码，走向治理从意图到上线的整条路径。AI 可以加速这些节点之间的工作，但无法为结果承担责任。

5、AI 可以成为向善的力量

在我看来，只要组织给工程师空间，让他们更多发挥批判性思维技能，AI 就是软件行业的一股积极力量。当自动化主要用于削减成本或裁减人手时，你抛弃的正是那些让工程师善于改进他们所构建的系统与产品的批判性思维技能。

在一个以心理安全感为基础、把保障措施置于纯粹生产力之上的环境中，熟练的软件工程师有巨大潜力以比以往快得多的速度引领项目走向成功。懒惰的输入导致糟糕的输出，但最优秀的软件团队里满是对组织有深刻理解的问题解决者。你无法把他们的思考外包给 AI——这个时代的最成功的企业深知这一点。

原文链接: AI Won't Empty The Software Factory: Why The New Engineers Act Like Foremen

汇智网翻译整理，转载请标明出处