Loading... # AI 让写代码更容易，但让工程更难 # 一、新闻概述 ## 1. 标题 AI 让写代码更容易，但让工程更难 ## 2. 发布时间 2026 年 2 月 25 日 ## 3. 来源 ivanturkovic.com（Ivan Turkovic 的技术博客） # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 这篇文章探讨了一个鲜少被公开讨论的现象：虽然 AI 工具让写代码变得前所未有的容易，但软件工程师的日常工作却变得更加复杂、更具挑战性且更令人疲惫。 ### B. 核心亮点 - AI 加速了代码生产，但工程师的期望产出也随之提高 - 工程师正经历职业身份危机：从代码创作者转变为代码管理者 - 监督悖论：审查 AI 生成的代码比写代码更难 - 初级工程师面临培训场被 AI 消耗的困境 ## 2. 关键信息 ### A. 调查数据 哈佛商业评论 2026 年 2 月的研究跟踪了一家美国科技公司 200 名员工，持续 8 个月： - 83% 的员工表示 AI 增加了他们的工作量 - 62% 的员工和 61% 的初级员工报告职业倦怠 - C 层领导中仅有 38% 感到倦怠 Harness 调研发现： - 67% 的开发者花更多时间调试 AI 生成的代码 - 68% 的开发者花更多时间审查 AI 生成的代码 ### B. 招聘数据 - 2023 年至 2024 年间，15 家最大科技公司的初级工程师招聘下降了 25% - HackerRank 2025 年开发者技能报告确认期望上升速度超过生产力提升 ### C. 涉及产品 - AI 编程助手 - AI 代码代理 - 相关开发工具链 ## 3. 背景介绍 ### A. 前置背景 AI 工具的快速发展使代码生成的门槛降到历史最低。函数自动补全、特性脚手架、自然语言转代码等功能让任何人都能快速产出代码。 ### B. 相关上下文 行业正在广泛讨论 AI 的生产力提升，但很少有人关注其第二序效应：对使用这些工具的人带来的影响。 # 三、详细报道 ## 1. 主要内容 ### A. 基线移动现象 2026 年软件工程师的预期产出远高于 2023 年。这不是通过会议宣布的，也不是经理明确说明的，基线只是悄悄移动了。因为 AI 让某些任务变快，假设立即跟进：你应该做得更多。不是未来，而是现在。 哈佛商业评论的研究描述了一个自我强化的循环： 1. AI 加速某些任务 2. 提高了速度期望 3. 更高的速度使工人更依赖 AI 4. 增加的依赖扩大了工人尝试的工作范围 5. 更广的范围进一步增加了工作的数量和密度 ```mermaid graph LR A[AI 工具加速任务] --> B[速度期望提高] B --> C[更依赖 AI] C --> D[工作范围扩大] D --> A D --> E[工作数量和密度增加] E --> F[倦怠风险上升] ```  ### B. 身份危机 大多数软件工程师成为工程师是因为热爱写代码。不是管理代码，不是审查代码，不是监督产生代码的系统，而是写代码。这是吸引大多数人的创造性工作，是一种工匠精神的体现。 现在他们被告知要停止。不是显式地，而是微妙而持久的信息：使用 AI 写得更快，让代理处理实现，专注于更高级的任务。这种转变对许多工程师来说感觉像是被告知他们花费数年掌握的技能突然不那么重要了。 ```mermaid graph TD A[传统工程师身份] -->|热爱| B[写代码] B --> C[创造性工作] C --> D[工匠精神] B --> E[深度技术技能] E --> D F[新工程师身份] -->|被要求| G[管理代码] G --> H[审查 AI 输出] H --> I[ directing AI 系统] I --> J[价值在指导而非实现] A -.转型.-> F E -.失去.-> I D -.淡化.-> I ```  ### C. 职责范围扩大 工程师被要求少写代码，但同时被要求做更多其他事情：更多产品思维、更多架构决策、更多代码审查、更多上下文切换、更多规划、更多测试监督、更多部署意识、更多风险评估。 哈佛商业评论研究记录了确切模式：产品经理开始写代码，工程师接手产品工作，研究人员开始做工程任务。曾经有明确边界的角色随着工人使用 AI 处理原本在其职责范围之外的工作而变得模糊。 ### D. 监督悖论 审查 AI 生成的代码往往比自己写代码更难。当你写代码时，你脑海中携带每个决策的上下文。你知道为什么选择这种数据结构、为什么处理这种边缘情况、为什么这样构建模块。代码是你思考的表达，审查它是直接的。 当 AI 写代码时，你继承了输出但失去了推理。你看到代码，但看不到决策。你不知道做了什么权衡、内置了什么假设、考虑或忽略了什么边缘情况。 ```mermaid graph LR subgraph 自己写代码 A1[思考决策] --> A2[编写代码] A2 --> A3[审查代码] A3 -->|上下文已存在| A4[轻松理解] end subgraph AI 生成代码 B1[AI 推理] --> B2[生成代码] B2 --> B3[审查代码] B3 -->|缺少上下文| B4[需要额外理解] B4 -->|更多认知负荷| B5[审查更困难] end ```  ## 2. 技术细节 ### A. 加速陷阱 循环的自我强化性质使情况尤其困难： - AI 让某些任务变快 - 更快的任务创造更多可用容量的认知 - 更多感知容量导致分配更多工作 - 更多工作导致更多 AI 依赖 - 更多 AI 依赖导致更多需要审查的代码、需要维护的上下文、需要理解的系统，以及更多认知负荷 在 AI 之前，你一天能生产多少有一个天然上限。这个上限由思考速度、打字速度和查询信息的时间设定。有时令人沮丧，但也是一个调节器。防止你以超过维护质量能力的速度前进的自然速度限制。 ### B. 初级工程师的挑战 初级工程师传统上通过做更简单、更面向任务的工作来学习：修复小 bug、编写 straightforward 的特性、实现明确定义的工单。这种实践工作建立了基础理解，最终使他们能够承担更复杂的挑战。 AI 正在迅速消耗这个培训场。如果代理可以处理常规的 API 连接、样板模块、straightforward 的 CRUD 端点，初级工程师还能从中学到什么？ ## 3. 数据与事实 ### A. 疲劳与倦怠数据 - 83% 的员工报告 AI 增加了工作量 - 62% 的员工和 61% 的初级员工报告倦怠 - C 层领导仅有 38% 报告倦怠 - 近三分之二的工程师在使用 AI 的组织中经历倦怠 ### B. 招聘趋势 - 15 家最大科技公司的初级工程师招聘下降 25%（2023-2024） - HackerRank 2025 报告：期望上升速度超过生产力提升 - 初级招聘相比高级职位仍然缓慢 ### C. 生产力悖论 - 43% 的工程师认为领导层与团队挑战脱节 - 超过三分之一报告过去一年生产力实际下降 - 45% 的工程职位现在期望在多个领域具备熟练度 # 四、影响分析 ## 1. 行业影响 ### A. 技术趋势 - AI 工具正在重塑软件工程的工作流程 - 行业公开讨论这是积极发展，工程师应该成为 T 型人才或更广泛意义上的全栈人才 ### B. 人才结构风险 如果初级工程师没有机会通过实践工作建立基础技能，行业最终将面临真正理解他们监督的系统的资深工程师短缺。你无法监督你从未学会建造的东西。 ```mermaid graph TD A[初级工程师传统路径] --> B[实践简单任务] B --> C[建立基础技能] C --> D[承担复杂挑战] D --> E[成为资深工程师] F[当前 AI 路径] -->|AI 消耗| G[任务自动化] G --> H[缺少实践机会] H --> I[基础技能薄弱] I --> J[无法成长为资深工程师] J --> K[人才短缺] D -.正常供应.-> K K -.风险.-> L[行业长期危机] ```  ## 2. 用户影响 ### A. 现有工程师 - 职业身份危机 - 工作量增加而支持未增加 - 职责范围扩大但报酬和权威未相应增加 ### B. 初级工程师 - 失去传统的学习路径 - 被期望从一开始就做出更高水平的贡献 - 没有之前的工程师依赖的渐进式爬坡期 ### C. 组织影响 - 信任和士气的缓慢侵蚀 - 技术债务积累速度超过解决速度 - 表面指标上升但质量 quietly 侵蚀 ## 3. 技术趋势 ### A. 工作流程变化 - 实施阶段被 AI 压缩 - 瓶颈从实现转移到实施周围的所有环节：需求清晰度、架构决策、集成测试、部署策略、监控和维护 ### B. 技能需求转变 - 系统设计 - 架构思维 - 产品推理 - 安全意识 - 批判性评估未编写的代码 # 五、各方反应 ## 1. 作者观点 Ivan Turkovic（拥有 20 多年工程领导经验）认为： - 这是一种真实的困难，不是理论或抽象的 - 需要承认现实是维持信任团队的先决条件 - 组织需要与工具一起投资于人 ## 2. 业内评价 ### A. 积极观点 - AI 是不可思议的工具 - 工程师更早获得更广泛的能力集 - 这是先机而非负担 ### B. 关注点 - 43% 的工程师认为领导层与团队挑战脱节 - 超过三分之一报告生产力实际下降 - 超过三分之二报告倦怠 ## 3. 社区反馈 - Reddit 多数用户对 AI 持积极态度 - 部分用户担心 JIT 成熟度 - 许多工程师感到独自挣扎 # 六、给领导者的建议 ## 1. 承认困难 承认这种过渡 genuinely 困难。工程师报名的职业变化很快。他们被雇佣的技能正在被重新定位。他们工作的期望在明确的公告下转移。 ## 2. 提供真实培训 提供团队真正的培训，不仅仅是关于提示工程的午餐学习。真正投资于新工程格局实际需要的技能： - 系统设计 - 架构思维 - 产品推理 - 安全意识 - 批判性评估未编写的代码的能力 ## 3. 给予实验空间 给团队在没有立即生产力增益压力的空间实验。在这个环境中茁壮成长的工程师是有空间弄清楚 AI 如何适应他们的工作流程而不会因学习曲线受到惩罚的人。 ## 4. 设定明确边界 围绕角色范围设定明确边界。如果要求工程师在技术工作之外承担产品思维、规划和风险评估，命名它、定义它、补偿它。 ## 5. 重新思考指标 如果工程成功指标仍然集中在速度、关闭的工单和代码行数，你在 AI 辅助的世界中测量了错误的东西。更好的指标包括： - 系统稳定性 - 代码质量 - 决策质量 - 客户成果 - 团队健康 ## 6. 保护初级管道 如果因为 AI 可以处理入门级任务而停止招聘初级工程师，你是在通过创造长期人才危机来解决短期效率问题。 # 七、给工程师的建议 ## 1. 不要放弃基础 不要放弃你的基础。成为 AI 优先工程师的压力是真实的，但五年后最有价值的工程师是那些深刻理解他们工作的系统的人。 ## 2. 学会设定边界 学会与加速陷阱设定边界。仅仅因为你可以生产更多并不意味着你应该。可持续的节奏很重要。 ## 3. 拥抱扩展角色 拥抱真正感兴趣的扩展角色部分。如果工程角色现在包括更多产品思维、更多架构决策、更多跨职能沟通，将其视为机会而非强加。 ## 4. 公开讨论 公开讨论你正在经历的事情。感觉像是唯一一个为这种过渡挣扎的人的孤立感是当前时刻最具破坏性的方面之一。你不是唯一的一个。数据证实了这一点。 ## 5. 记住历史 记住这个职业在每一个消亡的预测中幸存下来。COBOL 被认为会消除程序员。专家系统应该取代他们。第四代语言、CASE 工具、可视化编程、无代码平台、外包。每个十年都带来一项新技术，承诺让软件工程师过时，每个十年对熟练工程师的需求都在增长。AI 不会有任何不同。 # 八、总结 AI 让写代码更容易，让工程师工作更难。这两件事同时是真实的，假装只有第一件事重要是组织如何失去他们最好人才的方式。 正在挣扎的工程师不是因为他们擅长工作而挣扎。他们挣扎是因为他们的工作在他们之下发生变化，而行业庆祝变得更容易的部分并忽略变得更难的部分。 期望没有公告就上升。角色没有边界地扩展。产出需求增加，而支持、培训或承认没有相应增加。提出担忧的工程师被隐含或明确地告知，他们只需要适应得更快。 这就是如何建立可持续的工程文化的方式。这就是你如何建立一个倦怠机器的方式。 行业需要诚实地命名这个悖论。AI 是一个不可思议的工具。它也给使用它的人带来了巨大的新需求。两件事都可以是真实的。两件事都需要解决。 那些做对的组织，与工具一起投资于人，承认快速技术变化的人力成本同时仍然向前推进，这些组织将是在未来几年吸引和留住最佳工程人才的那些组织。 那些不会的组织将发现每个技术周期最终教导的一件事：工具不构建产品。人构建。而且人的限制没有任何数量的 AI 可以自动化。 *** ## 参考资料 1. [AI Made Writing Code Easier. It Made Engineering Harder.](https://www.ivanturkovic.com/2026/02/25/ai-made-writing-code-easier-engineering-harder/) 最后修改：2026 年 03 月 01 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏