软件工程的身份危机：拥抱 AI 时代的挑战与机遇
Annie Vella
软件工程的身份危机
- 2025年3月21日
我们中的许多人成为软件工程师，是因为我们在构建事物中找到了自己的身份认同。不是管理事物，也不是监督事物，而是构建事物。用我们自己的双手，我们自己的头脑，我们自己的代码。 但这种身份正在受到挑战。 AI 编码助手不仅仅改变了我们编写软件的方式，它们还在根本上改变了我们是谁。我们正在从创造者转变为编排者，从构建者转变为监督者。从工程师变成看起来非常像……管理者的人。 这种讽刺意味很深：多年来，我们一直说软件工程超越了单纯的编码。需求、设计、测试、运维——这些都被认为是我们的技艺的一部分。然而，行业却把我们推向了相反的方向。我们将这些责任交给了专家——Product Owners、Architects、Quality Engineers、Platform Engineers——而我们则加倍投入到我们的编码专业知识中。我们成为了代码大师，现代魔法的骄傲使用者。 现在，就在我们完善了这门技艺之后，AI 却威胁要把它从我们手中夺走。
我们即将失去的乐趣
让我们坦诚地谈谈这里所面临的风险。我们中的许多人不仅仅是编写代码，我们热爱编写代码。我们的身份与我们精心设计的每一个优雅的解决方案，我们通过的每一个测试，我们通过纯粹的逻辑和创造力解决的每一个问题交织在一起。这不仅仅是工作，不仅仅是一门手艺——这是我们是谁。
想想那些充满满足感的时刻：当你最终追踪到那个困扰生产环境的难以捉摸的 bug 时，当你算出如何优化那个缓慢的算法，并看到响应时间从几秒降到几毫秒时，当你把迷宫般的遗留代码变成干净且可维护的东西时。这些不仅仅是成就——它们是我们作为工程师的表达。它们是提醒我们为什么选择这条道路的时刻。
现在想象一下 AI 接管这些工艺时刻。这些工具的创造者描绘了一个乐观的景象——他们说我们会花更多时间在 定义意图、高层架构 和 系统思考 上。但仔细听听他们真正要说的是什么：我们将成为监督者而不是创造者，管理者而不是构建者。
这种转变引发了关于我们作为构建者的身份的重要问题：监督是驱动我们的东西吗？是不是让我们早上迫不及待地起床，渴望解决下一个难题的东西？
身份转变：它已经到来
我们讨论的不是一些理论上的未来——这是我们现在生活的现实。当 Google 最近透露 AI 生成了他们超过四分之一的新代码时，这仅仅是个开始。Y Combinator 的 CEO Garry Tan 透露，对于大约四分之一的他们的初创公司，95% 的代码现在是由 AI 编写的——标志着一个真正重大的转变。我自己的硕士研究也揭示了类似的情况：77% 的人花费更少的时间编写代码，并且几乎一半的人认为我们的核心技能可能会退居其次，让位于 prompt engineering。想想这个转变：从制作解决方案到制作 prompts。
Prompt Engineering 会取代传统的编码技能吗？
当被问及如何培养 prompt engineering 技能时，软件工程师强调提高沟通技巧。让 AI 按照你的意愿行事，意味着能够清晰地表达事物——提供适量的上下文，以及对任务的清晰描述。你与 Gen AI 沟通得越好，输出就越有可能符合你的期望。有些人甚至建议对这些工具礼貌，像对待团队成员一样——仿佛你正在引导另一个人为你做某事。
这些变化如此深刻，以至于我们正在发明新术语来描述我们正在成为什么样的人。以 vibe coding 为例，这是 Andrej Karpathy 最近在 tweet 中创造的一个术语。它捕捉了我们编写软件方式的深刻转变。
在这种频谱的一端是传统的方式——工匠的方式。我们有目的地编写每一行代码，每一个函数名称和架构决策都反映了我们对系统的深刻理解。
在另一端呢？我们让 AI 填写空白，“感受”它的建议。我们关注的是 “什么”，而不是 “如何”。正如 Karpathy 所说：“完全屈服于 vibes，拥抱指数增长，并忘记代码的存在。”
最后一部分让我们停下来思考——如果我们忘记了所有的代码，我们还是工程师吗？
在最近的一次 pairing session 中，工程思想领袖 Gene Kim 和 Steve Yegge 演示了这在实践中是什么样子的。使用 AI 编码助手，他们将一个 3500 行的遗留 Ruby 脚本移植到 Kotlin——这项通常需要一周才能完成的任务——只用了一个小时。AI 不仅翻译了代码，还改进了它，添加了他们多年来一直想要的模块化架构和单元测试，但却没有时间去做。
甚至 Patrick Debois，DevOps 的教父，也看到了这种转变正在重塑我们的身份。在他 最近对 AI Native Development 模式的分析 中，他概述了我们工作方式的四个根本性转变：
Patrick Debois: AI Native Dev 的 4 种模式
这些模式揭示了一个深刻的转变：我们正在从 AI 系统的生产者转变为管理者，从详细的实现转变为表达意图，从交付转变为通过快速实验进行发现，以及从内容创作转变为知识管理。我们的角色正在演变为将创造与编排相结合，将构建与监督相结合。
总的来说，我认为可以公平地说，我们的职业身份的本质正在发生变化。
塑造我们身份的技艺
为了理解这场身份危机，我们需要看看编码这门技艺对我们自身的塑造有多么深刻。从核心上讲，编写代码是关于掌握和控制——我们花了多年时间完善的技能。现代编程语言比过去更高级，但它们仍然需要深刻的技术理解。今天很少有开发人员处理指针和内存管理的细节，但我们仍然为知道底层的工作原理而感到自豪。即使框架做了更多繁重的工作，我们仍然保持着我们作为工匠的身份，他们对自己的工具了如指掌。
今天的编程更多的是以创造性的方式将 APIs、框架和库缝合在一起，以构建有意义的东西。事实上，Google 最近的研究表明，软件工程中的创造力集中在 巧妙的重用而不是纯粹的新颖性 这一概念上。这对我来说很有道理——我经常评论说，我们现在都只是“集成”工程师，真的。
尽管如此，我们仍然对知道构建某些东西所需的所有奇怪的语法感到自豪。这就像一种只有我们才能理解的秘密语言。精通一种编程语言可以让你很好地控制它，让它精确地按照你想要的方式行事。它非常详细——只是一个错误的字符就会破坏整个东西，而且可能需要大量的时间和耐心才能让它按照你想要的方式行事。
首先，一个人必须完美地执行。计算机在这方面也类似于传说的魔力。如果一个字符，一个停顿，的咒语不是严格按照正确的形式，魔力就不会起作用。
——Frederick P. Brooks, The Mythical Man-Month, Chapter 1, Addison-Wesley, 1975
另外 99% 的人认为我们是理解代码的魔术师，而且确实，可能需要多年的刻意练习才能掌握它。那些掌握多种编程语言的人有幸被称为 polyglots。我们中的许多人为编写干净、优雅的代码感到非常自豪。我们热情地争论不同的风格和最佳实践，通常都太当真了。
一个不情愿的经理的故事
让我分享一个关于身份演变的可能引起共鸣的故事。
在担任个人贡献者十年之后，我触及了技术晋升的臭名昭著的天花板。Senior Lead Software Engineer ——这就是技术晋升的尽头。Staff+ Engineering 还不存在，而我所在公司的唯一架构师职位已被填补。我面临着一个会改变我身份的选择：保持构建者还是成为监督者。
我选择了管理。不情愿地。那是这条路带领我的地方。我告诉自己这仍然是工程，只是在一个不同的层面上。管理系统与管理人并没有太大的不同。我仍然可以在其他任务之间保持对代码的参与。
听起来很熟悉吗？这种相似之处是惊人的。正如我不得不将直接解决问题换成会议和文档一样，我们现在也被要求用编码换成 prompt engineering。定义我们作为工程师的技能——掌握语法，优雅地架构我们的代码，捕获和处理边缘情况，调试复杂的问题——正在被降级到 AI。相反，我们被告知要关注听起来非常像管理者的技能：清晰的沟通，系统思考，问题定义。
但这里没有人谈论的是：身份危机。当你意识到你不再用自己的双手构建东西时，那种深深的失落感。当你的技术掌握变得不如你“管理”工具的能力那么重要时。当你的技艺变成监督时。
编排 AI 能否给我们同样的身份认同感？作为一名建造者，一名创造者，一名问题解决者？
当机器挑战我们的身份
到目前为止，我们身份危机的根源变得清晰起来。我们花了多年时间完善的技艺——赋予我们目标、意义和自豪感的技艺——现在正被机器以更快的速度、更低的成本和更大的规模完成。当然，质量不如你手写的代码（但）。但现在编写代码的速度是惊人的，企业都在争先恐后地参与其中。
这就是一线希望出现的地方。还记得那种讽刺吗——我们是如何将更广泛的技艺方面交给专家的？AI 正在推动我们重新获得我们曾经知道的东西：软件工程超越了单纯的编码。这个核心真理依然存在——最终，软件工程是关于解决问题，创造解决方案，构建重要的事物。
这些更广泛的技能——Addy Osmani 在他关于 AI 辅助编码中人类占 30% 的文章 中称之为“持久的工程技能”——一直将伟大的工程师与优秀的工程师区分开来。沟通、大局观思考、处理模糊性——这些在 AI 驱动的世界中变得更加重要。
然而，这种对更广泛技能的强调在我们社区引发了争论。对于某些人来说，这听起来非常像重新包装的管理。他们并没有完全错——最近的一篇 CIO 文章 证实，开发团队已经在进行重组，以专注于监督而不是创造。这篇文章设想未来的团队由一名产品经理、一名 UX 设计师和一名主要使用 AI 生成原型的软件架构师组成。这些架构师，或高级开发人员，必须“理解内容……客户是谁，以及我们试图实现什么”——经典的管理职责被重新包装成技术工作。
披着外衣的管理
这种演变引发了关于我们作为工程师的身份的根本性问题：随着传统职业阶梯的转变，下一代软件工程师将如何发展他们的技能？我们如何在拥抱这些新工具的同时，保留塑造我们专业的深刻的技术理解和技艺？也许最令人不安的是——随着 AI 能力呈指数级增长，我们作为工匠的角色是否会像工业革命期间的手工织布工一样过时？
前进的道路
也许答案不是抵制这种转变，而是通过历史的视角来理解它。这些身份危机——这些通过我们的工作来定义我们自己的根本性转变——并不是什么新鲜事。它们是一种模式的一部分，每当技术重塑一个职业时，这种模式就会重复出现。
在 工业革命 期间，工匠们也面临着类似的危机。他们的传统技能——经过几代人的磨练——正在被机器取代。但接下来发生的事情很令人着迷：许多人适应了，成为了可以修理和改进这些威胁要取代他们的机器的专业人士。另一些人则找到了应用他们对材料和工艺的深刻理解来改善整个工厂运营的方法。
如果我们把这种类比应用到我们的 AI 时代，就会出现一条类似的道路。软件工程的核心——解决问题和创造价值——保持不变。我们的工具正在进化，随之而来的是有效利用它们所需的技能。
问题不在于我们是否会成为机器的管理者——而在于我们是否能从我们技艺的这种演变中找到同样的满足感。
工程师的困境
那么这让我们身处何地？我们是否注定要成为 AI 代理的监督者，而不是代码的编写者？这是一个需要抵制还是拥抱的未来？
真相，一如既往，是细致入微的。正如一些工程师自然而然地倾向于管理，而另一些人则更喜欢亲力亲为一样，我们可能会看到一个类似的谱系出现在我们与 AI 的互动方式中。一些人将擅长编排 AI 系统，专注于高层设计，并使这些系统更加高效和可靠——指挥一场技术交响乐，而不是独自演奏。另一些人将在人类专业知识仍然至关重要的领域找到自己的使命——也许是在安全敏感的应用中，在 AI 缺乏训练数据的新领域中，或者在性能和可靠性至关重要的系统中。关键不是抵制这种演变，而是在其中找到我们的位置。
显而易见的是，“软件工程师” 的定义正在扩大，而不是缩小。使某人有价值的技能正在多样化。这既带来了挑战，也带来了机遇。
对于那些热爱编码技艺的人来说，这种转变可能会让人感到威胁。但请记住，AI 工具仍然只是工具。他们不理解代码背后的“为什么”，业务背景，或所服务的人类需求。他们无法真正意义上进行创新，至少目前还不能。据我们所知，他们也无法感受到解决一个复杂问题的满足感，或创造新东西的喜悦。
也许在这个新环境中，最有价值的技能不是 prompt engineering 或系统架构，而是适应性——愿意进化，学习新技能，并在一个快速变化的领域中找到你独特的位置。
光明的一面
尽管存在这些挑战，但我们需要承认一些重要的事情：这些 AI 工具可以令人难以置信地赋能。随着像 Windsurf 和 Cursor 这样的 agentic IDEs 将软件开发提升到一个全新的水平，这就像拥有一个支持性的结对编程伙伴，他们总是在那里，随时准备帮助你解决以前可能看似令人生畏的问题。
对于初级开发人员或我们这些可能感到有点生疏的人来说，AI 助手可以增强信心——帮助你从空白文件开始，在你犹豫不决时验证你的方法，或以对你有意义的方式解释复杂的概念。对于经验丰富的开发人员来说，他们就像拥有一个不知疲倦的助手，可以处理日常任务，而你则可以专注于问题中更具挑战性的方面。
我们现在可以快速原型化想法，探索不同的方法，并学习新技术的速度确实非常惊人。可能需要数周的研究和试错才能完成的事情，通常可以在几小时甚至几分钟内完成。这就像拥有一种超能力——能够放大我们的能力，并以前所未有的速度将我们的想法变成现实。
现实检查
但权力越大，责任越大。最近一项全面的 GitClear 研究 分析了 2.11 亿行代码，揭示了一些令人担忧的趋势，因为 AI 代码生成工具变得越来越普遍：
- 复制粘贴的代码增加了 17.1%，这是 AI 辅助代码复制首次超过重构（移动）代码。
- 重复代码块增加了 8 倍，现在 6.66% 的提交包含重复的代码段。
- 代码变动增加了 26%，所有代码更改中有 5.7% 在两周内被修改或删除。
虽然我们生产代码的速度比以往任何时候都快，但我们也在花费更多的时间来修复 AI 生成的错误，并处理更难维护的代码。这不仅仅是速度问题——这是关于编写可持续的、可维护的软件的技艺。
隐藏的身份危机
然而，在这些表面上的变化之下，隐藏着一个更深层次的挑战——一个触及我们作为工程师的身份核心的挑战。新兴的人机团队合作领域正在揭示关于我们未来的令人不安的真相。2024 年的一项研究 表明，当人类和 AI 协同工作时，结果往往达不到预期。不是因为 AI 缺乏能力，而是因为与机器建立信任的方式与与人类建立信任的方式不同。
我们不会像与人类队友那样与 AI 建立信任。
对于人类来说，信任会随着共同的成功而逐渐增长。一起解决的每一个问题都会加强彼此的联系。即使是处理得当的失败也可以加深信任。对于 AI 来说，信任通常一开始很高，但会迅速消退。
每一个不正确的响应，每一个幻觉般的 bug 修复，每一个错位的信心都会削弱我们对机器的信任。与人类关系中信任通常会随着时间推移而增长不同，AI 信任通常在早期达到顶峰并下降。
当信任受到侵蚀时，生产力也会下降。
这项研究揭示了原因：
- AI 在如何解释我们的意图方面存在固有的不可预测性
- 它缺乏使人类协作流畅的上下文感知
- 它的决策通常缺乏透明度，一旦失去信任，就很难重建信任
这些挑战反映了我们中的许多人在转型为技术领导者时所经历的事情。正如新的工程经理必须学会信任其团队的工作，而无需自己去做一样，我们现在也面临着与 AI 类似的转变——学会指导和验证，而不是自己编写每一行代码。
现实是严峻的：尽管 AI 具有原始能力，但团队与 AI 合作的效果通常比没有 AI 合作的效果更差。正如团队的生产力在无效的领导下会受到影响一样，当我们不了解如何与我们的 AI 工具合作时，我们的效率也会降低。
重塑你的身份
从我作为一名不情愿的经理的经历和我对 AI 变革的研究中，我看到了三种可能保留我们作为构建者身份的方式：
- 抵制 —— 有些人会选择专注于人类创造力和深刻的技术专业知识仍然至关重要的领域
- 适应 —— 另一些人将拥抱 AI 编排，成为一种新型技术交响乐的指挥家
- 平衡 —— 许多人，像我一样，将寻求一条中间道路——使用 AI 来完成日常任务，同时保留直接解决问题的乐趣
然后我意识到，这种想法改变了我的观点：我们不必只选择一条道路。
身份摆锤
也许我们身份危机的答案在于 工程师/经理摆锤。我自己在这些角色之间的旅程教会了我一些关于身份的关键信息：
- 管理并没有取代我的工程身份——它扩展了它
- 重返亲力亲为的工作不是倒退——它们是身份的更新
- 摆锤的摆动本身成为了我的一部分——适应性强，不断成长，不断进化
就在那时，我意识到：这正是我们在 AI 时代所需要的模型。
与其被迫成为永久的“AI 经理”，不如让我们在以下两者之间摆动：
- 深入的技术工作，我们可以直接编写和改进代码
- 战略编排，我们可以指导 AI 系统
- 结合这两种方法的创造性问题解决
这种平衡的方法与我从其他工程师那里听到的声音产生了深刻的共鸣。我的研究表明一个明确的信息：保持强大的工程基础比以往任何时候都更加重要。我们需要深刻的技术知识来有效地审查、验证和调整 AI 生成的代码——因为它通常不太正确。当被问及他们对 AI 编码助手的担忧时，软件工程师将代码质量和安全性排在职位保障之上。
软件工程师对 AI 编码助手的主要担忧
这告诉我一些深刻的事情：我们把自己视为卓越工程的守护者，确保 AI 生成的解决方案符合可靠的软件工程原则。我们不是要将我们的专业知识委托给 AI——我们正在进化以新的方式应用我们的技艺。
你的行动
当我们应对这场转型时，一个根本性的真理浮出水面：我们的身份危机根本不是关于 AI 的。对人机团队合作的研究，与管理转型的相似之处，角色的摆动——它们都指向更深层次的东西。在选择成为构建者还是监督者之外，在于我们是谁的核心：创造者。
现在我们又回到了起点：AI 不是在抢走我们的工作；它是在给我们一个机会，让我们重新获得我们曾经交给专家的那些更广泛的角色方面。回到软件工程不仅仅意味着编写代码的时代。当它意味着理解整个问题空间时，从用户需求到业务影响，从系统设计到卓越运营。
摆锤的隐喻在这里为我们提供了智慧。正如我们中的许多人已经在工程和管理角色之间摇摆一样，我们可以以一种类似的流动性来拥抱 AI。有些时期，我们会深入研究代码，体验设计优雅解决方案的快感。其他时候，我们会退后一步来指导 AI 系统——不是作为监督者，而是作为理解其技艺每个部分的大师级建造者。就像工业革命的工人成为优化改变他们技艺的机器的专家一样，我们可以掌握这些 AI 系统——使它们成为我们创造力的工具，而不是替代品。
在 AI 时代，最重要的是保留我们本质的东西：构建事物、解决难题、使事物完全按照正确的方式运行的纯粹乐趣。我们的工程卓越性不仅仅是验证 AI 的工作——它源于对系统的深入了解，以至于我们可以塑造它们、改进它们、改造它们。
选择不是 AI 是否会改变我们的行业——它已经改变了。真正的选择是 我们如何与它一起进化。我们是会坚持对工程师意味着什么的一种过时的看法吗？还是我们会重新获得我们的技艺，不是作为单纯的编码者，而是作为 AI 增强系统的大师级建造者？
摆锤正在摆动——你会坚守阵地，还是会随之而动？
- < 更新的
- 更旧的 >
© Copyright 2025 Annie Vella
Powered by Hugo and Whiteplain