AI Made Writing Code Easier. It Made Engineering Harder.

Writing code is easier than ever. Being a software engineer is harder than ever. The paradox nobody talks about, and what engineers and leaders should do.

www.ivanturkovic.com

AI Made Writing Code Easier. It Made Engineering Harder.

本文探讨了人工智能(AI)对软件工程行业的深远影响,提出了一个核心悖论:虽然 AI 显著降低了“写代码”的门槛,却让“做一名工程师”变得前所未有的困难。作者 Ivan Turkovic 指出,随着 AI 辅助工具和智能体的普及,代码生成的效率大幅提升,但这导致了行业基准线的无形移动。管理层往往认为 AI 减轻了负担,但现实是工程师的期望产出成倍增加,工作范围也从单纯的开发扩展到了产品思维、架构决策和复杂的系统维护。

文章引用了 2026 年《哈佛商业评论》的一项研究,显示 83% 的员工认为 AI 增加了工作量,初级员工的职业倦怠率远高于高管。这种现象源于“加速陷阱”:任务变快导致任务量增加,进而导致对 AI 的过度依赖,最终形成一个工作强度不断升级的循环。此外,工程师正面临身份危机,从“创造者”转变为“审查者”,而审查 AI 生成的代码往往比自己编写更耗时且缺乏上下文。

对于初级工程师而言,AI 吞噬了基础的练习任务,导致人才培养链条断裂。作者呼吁领导层应意识到这一转变的艰巨性,通过提供系统性培训、设定明确的角色边界、重新定义衡量指标以及保护初级人才管道来应对挑战。对于工程师个人,则建议在拥抱工具的同时,坚持掌握底层原理,并学会设定职业边界以避免倦怠。


主题一:基准线的无形移动与加速陷阱

在 AI 普及的今天,软件工程师的产出预期在短短两年内发生了剧变。这种变化并非源于正式的会议通知或管理层的明确指令,而是因为 AI 工具让特定任务(如函数自动补全、脚手架搭建)变得极快。当任务变快时,行业默认的假设是:你应该做得更多。

2026 年 2 月《哈佛商业评论》对一家美国科技公司的 200 名员工进行了为期八个月的跟踪研究。结果揭示了一个令人不安的循环:AI 加速了任务,提高了速度预期;更高的速度让员工更依赖 AI;这种依赖扩大了员工尝试的任务范围;而更广的任务范围进一步增加了工作的数量和密度。研究显示,83% 的受访者表示 AI 增加了他们的工作量。更糟糕的是,这种压力在层级间分布极不均匀:约 61% 的基层员工感到职业倦怠,而 C-suite 高管中这一比例仅为 38%。这种认知偏差导致领导层误以为 AI 让一切变得轻松,而实际干活的人却在复杂性的泥潭中挣扎。

这种“加速陷阱”移除了一直以来保护工程师的“自然限速器”。在 AI 出现之前,人的思考速度、打字速度和查阅资料的时间构成了一个天然的天花板,防止工作量超出认知极限。现在,这个天花板消失了,唯一的限制变成了人的认知耐力。许多工程师发现自己虽然交付了职业生涯中最多的代码,却也感到了前所未有的精疲力竭。这种表面上的高产掩盖了质量侵蚀、技术债堆积以及团队士气崩溃的隐患。如果领导层继续无视这种基准线的移动,最终将导致人才的流失和组织信任的瓦解。

主题二:身份危机与监督悖论

大多数软件工程师选择这一职业是因为热爱“写代码”——这是一种将复杂问题转化为精确逻辑的创造性行为。然而,AI 正在将这种身份从“构建者”推向“审查者”。工程师们被告知,他们的价值不再在于编写代码,而在于指导编写代码的系统。这种转变对许多人来说并非进化,而是一种职业身份的丧失。

这种转变引出了一个核心矛盾:监督悖论。作者指出,审查 AI 生成的代码往往比自己写代码更难、更累。当你自己写代码时,你脑中存有每一个决策的上下文——为什么选择这个数据结构,为什么处理这个边缘情况。代码是你思维的表达。但当你审查 AI 生成的代码时,你继承的是结果而非推理过程。你面对的是一个统计模型生成的、看起来很合理但可能完全忽略了系统特定约束的代码块。你无法询问 AI 它的权衡逻辑,只能通过高强度的认知投入去逆向推导。

Harness 的一项调查支持了这一观点:67% 的开发者表示在调试 AI 生成的代码上花费了更多时间,68% 的人认为审查 AI 代码比审查人类代码更耗时。这并非工具的失败,而是工作流的结构性问题。随着 AI 生成代码的速度加快,确保这些代码在真实业务场景中安全运行所需的人类注意力也随之激增。生产瓶颈并没有消失,它只是从“编写”转移到了“理解”,而“理解”是极难被加速的。这种持续不断的“流水线质检员”角色,让工程师失去了工作的成就感,取而代之的是无休止的认知负荷。

主题三:角色泛化与初级人才的生存危机

随着 AI 压缩了代码实现阶段,组织开始悄然将原本属于其他角色的职责转移到工程师身上。现在的工程师被期望成为“全能型人才”:不仅要写代码,还要负责产品思维、架构决策、部署策略、安全评估和风险管理。这种所谓的“赋能”,在实际操作中往往变成了无限制的职能蔓延(Scope Creep),且通常没有相应的薪资增长或时间补偿。

这种角色扩张对初级工程师(Junior Engineers)的影响尤为致命。传统上,初级工程师通过处理简单的 Bug、编写基础功能和实现定义明确的任务来积累经验。这些“手活”是通往高级工程师的必经之路。然而,AI 正在迅速吞噬这些训练场。如果 AI 代理可以处理所有的样板代码和基础 CRUD 接口,初级工程师还能从哪里学习?数据显示,2023 年至 2024 年间,全球 15 家最大科技公司的初级职位招聘下降了 25%。

这不仅是个人职业发展的问题,更是整个行业的系统性风险。如果你从未亲手构建过系统,你就无法有效地监督系统。如果下一代工程师失去了深度阅读和推理代码的能力,再强大的 AI 工具也无法弥补这种底层能力的缺失。作者强调,代码是写给人看的,如果未来的工程师失去了这种“语感”,行业将面临严重的高级人才断层。好的领导力应该意识到这一点,保护初级人才的培养管道,而不是为了短期的效率提升而拆掉未来的梯子。


原文摘录

  1. 关于基准线移动: "The expected output of a software engineer in 2026 is dramatically higher than it was in 2023... The baseline just moved." (2026 年软件工程师的预期产出显著高于 2023 年……基准线已经移动了。)
  2. 关于身份危机: "Every day felt like being a judge on an assembly line that never stops. You just keep stamping those pull requests. The production volume went up. The sense of craftsmanship went down." (每天感觉就像是一个永不停歇的流水线上的法官。你只是不断地给拉取请求盖章。产量上去了,匠心却减少了。)
  3. 关于监督悖论: "Reviewing AI-generated code is often harder than writing the code yourself... You see the code, but you do not see the decisions." (审查 AI 生成的代码通常比自己写代码更难……你看到了代码,但你看不到决策过程。)
  4. 关于加速陷阱: "AI removed the governor. Now the only limit is your cognitive endurance. And most people do not know their cognitive limits until they have already blown past them." (AI 移除了限速器。现在的唯一限制是你的认知耐力。而大多数人在突破认知极限之前,并不知道极限在哪里。)
  5. 关于核心本质: "Tools do not build products. People do. And people have limits that no amount of AI can automate away." (工具不构建产品,人构建。而人是有极限的,这是任何 AI 都无法自动化消除的。)

问答

问:为什么说 AI 让工程变得更难了? 答:因为 AI 提高了产出速度,导致管理层对工作量和速度的预期水涨船高。工程师现在不仅要处理更多的代码,还要承担原本属于产品经理、架构师和运维人员的职责,导致认知负荷超载和职业倦怠。

问:什么是“监督悖论”(Supervision Paradox)? 答:这是指审查 AI 生成的代码往往比自己编写代码更耗时且更困难。因为 AI 只提供结果而不提供决策背后的逻辑和权衡,人类审查者必须花费大量精力去理解和验证这些缺乏上下文的代码。

问:AI 对初级工程师有哪些负面影响? 答:AI 自动完成了大量基础、重复性的编程任务,而这些任务正是初级工程师磨练技能的“训练场”。这导致初级职位减少,且新人难以通过实践积累底层经验,可能导致未来高级人才的断层。

问:面对这种变化,企业领导者应该怎么做? 答:领导者应承认这种转型的难度,提供系统架构和产品思维等新技能培训,设定明确的角色边界,重新定义衡量成功的指标(关注质量而非单纯的产出量),并坚持招聘和培养初级人才。

问:工程师个人应该如何应对? 答:不要放弃底层基础知识,因为在 AI 时代,理解架构、调试复杂系统和安全评估的能力变得更加稀缺。同时,要学会识别“加速陷阱”,设定可持续的工作节奏,并积极参与到产品和架构等更高维度的决策中。