AI辅助编码将如何改变软件工程：更需要经验丰富的工程师

可以肯定的是，生成式 AI 将继续改变我们开发软件的方式。

回顾 2022 年 11 月，ChatGPT 首次问世，这是大语言模型（LLM）开始被广泛运用的开端。尽管 LLM 的构建方式出人意料地简单，但它们在各个领域都取得了令人印象深刻的结果。编写代码无疑是它们的强项之一。这并不令人感到惊讶，因为：

• 编程语言的语法比任何一门人类语言都要简单得多。

• 这些 LLM 有大量的高质量训练数据可用，也就是那些有效的源代码，这得益于开源软件以及对 GitHub 和其他免费访问的代码仓库的爬取（尽管这种爬取和训练行为存在道德争议，但此类行为仍在持续发生）。

去年，我们的 AI 工具使用情况调查发现，大约 75% 的开发者使用某种 AI 工具进行与软件工程相关的工作。然而，我们似乎仍处于工具创新周期的早期阶段，而更复杂的方法，如软件工程 AI 智能体，很可能成为 2025 年创新的核心。

主流媒体对软件工程行业的描绘越来越戏剧化。3 月份，Business Insider 报道了“软件工程师越来越接近 AI 是否会让他们失业的真相”；9 月份，福布斯抛出疑问：“软件工程师是否正在变得过时？”尽管这类文章广为传播，但它们多出自非软件工程师之手，这些作者既不使用 AI 工具，也不了解这些新型 GenAI 编码工具的效率（以及局限性）。

那么我们能从 GenAI 工具重塑软件工程这件事情中期待些什么呢？GenAI 将改变软件工程的某些部分，但不太可能像一些之前的新闻所暗示的那样发生戏剧性的变革。在使用这些工具两年后，大多数工程团队使用它们的时间也已超过 12 个月，我们能够对它们形成更准确的判断。

Addy Osmani 是一名软件工程师和技术负责人，处于观察 GenAI 工具如何重塑软件工程的绝佳位置。他在谷歌工作了 12 年，目前担任 Chrome 开发者体验负责人。谷歌作为 GenAI 创新的前沿企业，在 2017 年发表了关于 Transformer 架构的论文，为 LLM 奠定了基础。如今，谷歌构建了最先进的基础模型之一——Gemini 2.0，并且是 OpenAI 的最大竞争对手之一。

Addy 在他的文章 《70% 问题：AI 辅助编码的严峻真相》 中总结了他的观察和预测。文章对 AI 工具的优势和劣势进行了务实的剖析，即强调了这些工具的根本局限性，也指出了工程师们不容忽视的积极方面。它还为各个级别的软件工程师提供了如何充分利用这些工具的实用建议。经 Addy 授权，本文对他的文章进行了编辑，并在文末加入了很多我的想法，内容包括：

1. 开发者现实中如何使用 AI。“加速器”与“迭代器”有着截然不同的使用方式，这或许也是为何一种工具不太可能对这两类人群都同样有效的原因？

2. 70% 问题：AI 的学习曲线悖论。一些较少被提及的 AI 挑战，包括“两步后退悖论”、“AI 速度”的隐藏成本以及“知识悖论”。

3. 真正有效的实用模式。AI 优先草案、持续对话以及“信任加验证”模式。

4. 这对开发者意味着什么？从小处着手，保持模块化，相信自己的经验。

5. 智能体式软件工程的兴起。与 AI 协作的转变、多模态能力、自主加指导方法以及“英语优先”的开发环境。

6. 软件作为工艺的回归？抛光艺术的复兴以及个人软件的复兴。

7. 额外的想法。现在是时候重新审视软件工程的本质以及 20 世纪 60 年代以来的无开发者软件工程的梦想。另外，未来对经验丰富的工程师的需求可能会增加，而不是减少。

以下是对 Addy 文章的编辑版本。

在过去的几年里，我一直深入参与 AI 辅助开发领域，并发现了一个很有趣的现象。尽管工程师们纷纷反馈，有了 AI 的帮助，他们的工作效率大幅提升，但我们日常所使用的软件在品质方面似乎并没有明显变得更好。这是怎么回事呢？

我想我知道原因，而这个答案揭示了一些关于软件开发的基本事实，这些是我们需要正视的。让我来分享一下我的发现。

我注意到在利用 AI 工具进行开发的团队中存在着两种截然不同的模式。我们可以把它们叫作“加速器”和“迭代器”模式。这两种模式都在帮助工程师（甚至非技术用户）有效缩短从构思到付诸实践（或最小可行产品）这一过程的距离。

像 Bolt、v0 和截图转代码这类工具正在彻底改变我们启动新项目的方式。这些团队通常：

• 从一个设计或初步概念开始

• 利用 AI 生成一个完整的初始代码库

• 在几小时或几天（而不是几周）内得到一个可运行的原型

• 专注于快速验证和迭代

其成果可能令人印象深刻。我最近看到一位独立开发者使用 Bolt 将一个 Figma 设计几乎在瞬间变成一个可运行的 Web 应用程序。虽然它还没有达到生产就绪的水平，但已经足够好，可以获取非常初步的用户反馈了。

第二类团队使用像 Cursor、Cline、Copilot 和 WindSurf 这样的工具来推进日常开发流程。这可能没有那么引人注目，但潜在的变革性可能更大。这些开发者：

• 利用 AI 进行代码补全和建议

• 借助 AI 完成复杂的重构任务

• 生成测试和文档

• 将 AI 作为“结对编程”伙伴来解决问题

但这里有一个问题：尽管这两种方法都能极大地加速开发，但它们都伴随着一些隐藏的成本，这些成本并不会立即显现出来。

之前一条推文引起了我的注意，它完美地描绘了我所观察到的一个现象：非工程师在使用 AI 工具进行编码时，往往会撞上一堵令人沮丧的墙。他们能在出人意料的短时间内完成 70% 的工作，但剩下的 30% 却变成了一场收益递减的艰难跋涉。

“70% 问题”揭示了当前 AI 辅助开发状态的一个关键事实。最开始的进展感觉就像魔法一样：你可以描述你想要的东西，AI 工具会生成一个看起来令人印象深刻的可运行原型，但随后现实的问题接踵而至。

接下来发生的情况，通常会遵循一个可预测的模式：

• 你尝试修复一个小问题

• AI 提供一个看似合理的修复建议

• 这个修复导致了新问题

• 你让 AI 修复新问题

• 这又导致了两个新问题

• 如此循环往复

对于非工程师来说，这个循环尤其痛苦，因为他们缺少理解问题根源的认知框架。当一位经验丰富的开发者遇到问题时，他们可以根据多年积累的模式识别经验来推理潜在的原因和解决方案。没有这样的背景，你基本上就是在玩打地鼠游戏，与你并不完全理解的代码作斗争。

当你看着资深工程师使用像 Cursor 或 Copilot 这样的 AI 工具时，就像魔法一样。他们可以在几分钟内构建好整个功能，包括测试和文档。但如果仔细观察，你会注意到一个关键点：他们并非一味照搬人工智能的建议，而是持续不断地：

• 将生成的代码重构为更小的模块

• 添加 AI 遗漏的边缘情况处理代码

• 增强类型定义和接口

• 质疑架构决策

• 添加全面的错误处理

换句话说，他们运用多年积累的工程经验来重塑和约束 AI 的输出。AI 加快了实现过程，但他们的专业知识才是保持代码可维护性的关键。

初级工程师往往会忽略这些关键步骤。他们更容易直接接受 AI 的输出，从而导致我所说的“纸牌屋代码”——看起来完整，但在现实世界的压力下不堪一击。

我见过的最成功的使用 AI 编码工具的非工程师采取了一种混合方法：

• 使用 AI 进行快速原型设计

• 花时间理解 AI 生成的代码

• 在使用 AI 的同时学习基本的编程概念

• 逐步积累知识基础

• 将 AI 作为学习工具，而不仅仅是代码生成器

但这需要耐心和奉献精神，恰恰与许多人使用 AI 工具所期望达到的目的背道而驰。

这是我发现的最反直觉的一件事情：AI 工具对经验丰富的开发者帮助更大，而不是初学者。这似乎反过来了。难道 AI 不应该使编码变得民主化吗？

现实情况是，AI 就像团队中的一个非常热心的初级开发者。他们可以快速编写代码，但需要不断的监督和纠正。你了解得越多，就越能更好地指导它们。

这就产生了我所说的“知识悖论”：

• 资深人员使用 AI 来加速他们已经知道如何做的事情

• 初级人员试图使用 AI 来学习该做什么

• 结果大相径庭

我看到资深工程师使用 AI 来：

• 快速原型化他们已经理解的想法

• 生成他们可以进一步提炼的基本实现

• 探索已知问题的替代解决方案

• 自动化常规编码任务

与此同时，初级人员常常：

• 接受错误或过时的解决方案

• 忽略关键的安全和性能考量

• 难以调试 AI 生成的代码

• 构建他们并不完全理解的脆弱的系统

这里存在一个更深层次的问题：AI 编码工具对非工程师来说容易上手，它们能够为你处理复杂性，但实际上可能会阻碍学习。当你不理解 AI 生成的代码的原理时：

• 你无法提高调试技能

• 你错过了学习基本模式的机会

• 你无法推理架构决策

• 你难以维护和改进代码

这就产生了一种依赖，你需要不断让 AI 解决问题，而不是自己培养和积累处理这些问题所需的专业知识。

这个“70% 问题”表明，我们目前最好是将 AI 编码工具视为：

• 经验丰富的开发者的原型加速器

• 那些希望理解开发原理的人的学习辅助工具

• 快速验证想法的最小可行产品生成器

但它们还不是许多人所期望的编码民主化解决方案。实现软件生产就绪水平、可维护性和健壮性的最后 30% 工作，仍然需要真正的工程知识。

好消息是，随着工具的改进，这一差距很可能会缩小。但就目前而言，最务实的方法是利用 AI 来加速学习，而不是完全取代学习。

在观察了数十个团队之后，我发现以下这些方法始终行之有效：

• 让 AI 生成基本的实现

• 手动评审并重构，增强模块化

• 添加全面的错误处理

• 编写详尽的测试

• 记录关键决策

• 为每个不同的任务开启新的 AI 对话

• 保持上下文专注和精简

• 频繁评审和提交变更

• 保持紧密的反馈循环

• 使用 AI 生成初始代码

• 手动评审所有关键路径

• 对边缘情况进行自动化测试

• 定期进行安全评审

尽管面临这些挑战，我对 AI 在软件开发中的作用持乐观态度。关键在于理解它真正擅长什么：

• 加速构建已知的东西。AI 在帮助我们实现已经理解的模式方面表现出色，它就像一极具耐心且打字速度极快的配对程序员。

• 探索可能性。AI 非常适合用于进行快速原型设计和探索各种方法。它就像一个沙盒，让我们能够快速验证概念。

• 自动化常规任务。AI 大幅减少了在样板代码和常规编码任务上耗费的时间，让我们能够专注在有趣的问题上面。

如果你刚开始使用 AI 进行辅助开发，可以看看我的建议：

• 使用 AI 处理独立且明确定义的任务

• 评审生成的每一行代码

• 逐步构建大型功能

• 将所有东西分解成小而专注的文件

• 维护好组件之间的接口

• 记录模块的边界

• 使用 AI 来加速，而不是取代你的判断

• 对感觉不对的生成代码提出质疑

• 保持工程技术标准

随着 2025 年的到来，AI 辅助开发的格局正在发生巨大变化。尽管当前的工具已经改变了我们的原型设计和迭代方式，但我认为我们正处于一场更重大变革的边缘：软件工程智能体的兴起。

我所说的“智能体”是什么？这些系统不只是简单地对提示词做出响应，而是能够以越来越自主的方式去规划、执行和迭代解决方案。

我们已经看到了这种进化的初步迹象：

目前的大多数工具只是在等待我们的指令，但看看 Claude Anthropic 对计算机的使用，或 Cline 自动启动浏览器并运行测试的新功能，它们不仅仅是高级的自动补全，它们实际上是在理解任务并主动解决问题。

对于调试，这些智能体不仅仅是建议修复，它们还可以：

• 主动识别潜在问题

• 启动并执行测试

• 检查 UI 元素并截取屏幕截图

• 提出建议并进行修复

• 验证解决方案是否有效

下一代工具可能不仅仅处理代码，还可能无缝集成：

• 视觉理解（UI 截图、草图、图表）

• 口头对话

• 环境交互（浏览器、终端、API）

这种多模态能力意味着它们可以像人类一样全面地理解和使用软件，而不仅限于代码层面。

我从使用这些工具中获得的关键见解是，AI 在未来并不是要取代开发者，而是成为一个越来越有能力的协作者，它可以在接受人类指导和专业知识的基础上主动采取行动。

2025 年最高效的团队可能是那些学会：

• 为 AI 智能体设定清晰的边界和指导

• 建立强大的架构模式，让智能体能够在其中高效工作

• 在人类和 AI 能力之间创建有效的反馈循环

• 在利用 AI 自主性的同时保持人类的监督

正如 Andrej Karpathy 所说的：

“最热门的新式编程语言是英语。”

这是我们在与开发工具交互方式上的一次根本性转变。清晰的思考和用自然语言进行精确沟通的能力正变得和传统编程技能一样重要。

这种向智能体辅助开发的转变要求我们提升技能：

• 更强的系统设计和架构思维

• 更好的需求规范和沟通

• 更多关注质量保证和验证

• 增强人类和 AI 能力之间的协作

尽管 AI 让快速构建软件变得前所未有地容易，但我们却面临着失去一些至关重要的东西的风险：创造真正精致、具有消费者品质体验的艺术。

这正逐渐形成一种模式：团队利用 AI 迅速构建令人印象深刻的演示品，理想路径运行得非常完美，投资者和社交网络都为之惊叹，但当真正的用户开始点击操作时，问题便开始浮现。

我亲眼目睹了这种情况：

• 错误信息让普通用户完全看不懂

• 边缘情况导致应用程序崩溃

• 混乱的用户界面

• 完全忽视了可访问性

• 在较慢的设备上存在性能问题

这些不只是 P2 级别的小问题，而是人们勉强凑合使用的软件和真心热爱的软件之间的关键分水岭。

打造真正意义上的自助式软件，即那种用户无需与客服联系的软件，需要一种全新的思维方式：

• 对错误信息的精心设计

• 在慢网络连接条件下进行测试

• 优雅地处理每一个边缘情况

• 使功能易于发现

• 让真正的、非技术用户参与测试

这种对细节的关注或许无法由 AI 生成，它源于同理心、经验以及对工艺的深切关怀。

我相信我们将迎来个人软件开发的复兴。随着市场充斥着 AI 生成的最小可行性产品，那些能够脱颖而出的将是那些由以下开发者构建的产品：

• 对自己的工艺感到自豪

• 关注小细节

• 专注于完整的用户体验

• 考虑到各种边缘情况

• 创造真正自助式的体验

颇具讽刺意味的是，AI 工具实际上可能促成这一复兴。AI 可以处理常规的编码任务，让开发者能够专注于最重要的事情：打造真正服务于用户并令用户满意的软件。

AI 并没有让我们的软件明显变得更好，因为软件质量并非主要受限于编码速度。软件开发中真正困难的部分——理解需求、设计可维护的系统、处理边缘情况、确保安全性和性能——仍然需要人类的判断。

AI 让我们能够更快速地迭代和实验，这种更快速的探索可能会带来更好的解决方案。但这只有在我们保持工程纪律并将 AI 当作工具而非良好的软件实践的替代品时才会实现。记住：我们的目标并不是更快地编写更多代码，而是构建更好的软件。明智地运用 AI 可以帮助我们达成这一目标，但归根结底仍然需要我们自己去明确“更好”所代表的含义以及如何将其付诸实践。

以下是我对 AI 和软件工程的一些额外的想法。

关于 AI 工具在软件工程中的应用，大部分都集中在代码生成能力上，这是有道理的。AI 工具在根据提示词生成可运行的代码或在构建软件时提供代码建议方面确实令人印象深刻，但在构建软件的过程中，编码环节究竟占多大比例呢？大约 50 年前，Fred Brooks 认为编码约占总时间的 15% 至 20%。以下是 Brooks 在《人月神话》中描述的观点：

“多年来，我一直运用以下的经验法则来合理安排软件开发任务的时间，并取得了显著的效果：三分之一用于规划六分之一用于编码四分之一用于组件测试和早期的系统测试四分之一用于系统测试，此时所有组件均已就绪。”

在我看来，如今的软件工程师的时间分配可能是这样的：

• 20% 用于规划

• 40% 用于编码（编写代码 + 编写测试）

• 20% 用于代码评审（评审他人的代码）

• 20% 用于准备生产发布 + 上线 + 上线期间的小修小补 + 监控 + 告警

当然，构建出色的软件还涉及许多其他环节：

1. 确定做什么：弄清楚要构建什么。这可能涉及头脑风暴、设计、用户测试、与产品经理和业务利益相关者合作等。对于初创公司，这一阶段可能耗时很少（“先构建出来看看效果如何！”）。而对于成熟的公司，这一阶段可能比构建本身耗时更多（“我们需要确保构建的东西不会让现有客户感到困惑！”）。

2. 确定怎么做：制定构建产品、功能、服务的计划。考虑架构的影响、依赖关系、如何测试产品等。初创公司可能会跳过这一环节，团队直接进入规划阶段。但对于拥有众多服务和依赖关系的大型公司，跳过规划环节最终会带来麻烦。因此，大多数团队都在使用设计文档、RFC 或 ADR 等进行某种形式的规划。

3. 构建：实现功能或产品：编写代码，并确保能够正常运行。

4. 验证：在部署到生产环境之前，再次检查是否按预期运行。在上线风险较大时，这一点尤为重要。例如，向银行应用程序推送回归更新可能会对客户和业务造成财务上的损失！

5. 上线：合并变更并推送给客户，有多种策略可用于将变更部署到生产环境，我们在“Shipping to production”一文中介绍了其中的几种策略。

6. 监控和待命：监测产品是否出现了问题，一旦出现故障，尽快解决，并确保类似的故障不再发生。我们在“Healthy oncall practices”和“Incident review and postmortem best practices”中探讨了这些常见方法。

7. 维护：聆听客户投诉和反馈，确定哪些错误需要修复，哪些功能需要优先处理，并弄清楚哪些反馈可以忽略。

8. 迁移：如果产品发生重大变化，或者技术栈出现重大变化——比如引入新的框架——可能就需要进行迁移。

如今的 AI 工具可以在“构建”环节提供很大帮助，那么问题来了：它们对于软件工程的其他七个阶段有多大用处呢？

自 20 世纪 60 年代以来，非技术人员无需依赖软件开发者就能创建可运行软件一直是人们梦寐以求的目标。编码本质上是将人们的需求（客户、业务利益相关者、产品经理等）转化为计算机能够理解的内容。大语言模型为我们提供了一个更高层次的抽象，我们可以将英语转化为代码。然而，这种新的抽象并没有改变软件的构建方式和软件的本质，即：

AI 工具没有改变流程，但它们确实使部分编码环节变得更加高效：

在技术发展的历史长河中，一些创新曾承诺能够让业务人员绕过“技术”环节，直接用高级的提示词获得可运行的软件：

• 20 世纪 60 年代：高级编程语言 COBOL，即“通用的商业语言”，其目标是让没有编程背景的业务人员也能够使用它。

• 20 世纪 90 年代：Visual Basic。这是一种旨在降低学习曲线的编程语言，它还提供了一个可视化的编程环境，可以通过拖放创建表单。

• 2010 年代后期：无代码。无代码解决方案，如 Bubble，通过模板和可视编辑提供了一种构建软件应用的方法。

一些 GenAI 编码初创公司也有着相同的目标：让任何人都能够使用英语来构建软件。过去已经一些成功的简单用例。例如，无需任何编码知识也能创建网站：非技术人员可以使用 Wix.com、Webflow、Ghost 或 WordPress 等视觉编辑器和服务来实现。

抽象层次越高，就越难以明确地说明软件应该如何运行，无代码解决方案已经遇到了这一限制。正如顾问首席技术官 Alex Hudson 在其文章“The no-code delusion”中所写的：

“这些语法的发展通常会遇到表达问题：一旦它们简化到易于快速掌握的程度，便难以在众多场景中充分表达软件的复杂功能和精细逻辑。反之，一些语言具备定义领域特定语言（DSL）的能力。然而，这些语言很少在广大的开发社区中真正取得成功，主要是因为它们又使事情变得极其复杂。”

对于复杂的软件，很难想象不需要软件工程师参与规划、构建和维护，而且 AI 工具越是降低非技术人员构建软件的门槛，需要维护的软件就越多。

在大语言模型推出两年后，我们中的许多人已经相当熟练地使用它们来增强编码和软件工程工作。它们非常适合用于原型设计、切换到不太熟悉的语言，以及那些可以验证其正确性并指出幻觉或错误输出的任务。

然而，AI 智能体还处于初级发展阶段。大多数人都还没有开始广泛使用它们。目前只有一个普遍可用的智能体——Devin，每月收费 500 美元，用户反馈褒贬不一。

大量的风投将涌入这一领域。我们将看到更多 AI 编码智能体工具出现，其价格也肯定会随之下降。GitHub Copilot 很可能在 2025 年让 Copilot Workspace（一种智能体）变得普遍可用。我们还可能会看到一些初创公司的产品，如由 Stripe 前首席技术官 David Singleton 创立的初创公司（/dev/agents，https://sdsa.ai/）推出的产品。

AI 智能体在延迟和成本（计算结果花费的时间更长，多次运行提示词，这些初创公司称之为“思考”）与准确性（基于提示词获得更好的结果）之间做了权衡。关于这种延迟加成本的权衡会带来多大的准确性提升，以及哪些用例会因此显著提高生产力，仍有一些值得探讨的问题。

未来，对经验丰富的软件工程师的需求可能会比今天更大。我们看到的 AI 工具的共同特点是，经验丰富的工程师可以更高效地使用这些工具，因为他们能够更好地“瞄准”目标。当你知道什么才是“出色的输出”，你就可以更好地提供提示词，当代码生成出现错误时能够及时停止，而且你知道何时停下来直接转而修改源代码。

我们将看到更多由这些 AI 工具生成的代码，更多的人和企业开始构建自己的解决方案。当这些解决方案达到一定复杂度时，需要引入专业人士来应对这种复杂性：这种复杂性需要经验丰富的工程师来处理。现有的科技公司几乎肯定会使用 AI 工具生成更多的代码：它们将依赖经验丰富的工程师来应对随之而来的复杂性。

作为一名软件工程师，掌握 AI 辅助开发工具将使你更具生产力，也更有价值。现在正是投身这一领域的时刻：我们正处在一个工具创新加速的时代。我们确实需要花时间去弄清楚如何“驯服”现有的工具，实现自身生产力的最大化。所以，一定要去尝试使用它们！

原文链接：

https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering

声明：本文由 InfoQ 翻译，未经许可禁止转载。