取决于你去问谁，AI 驱动的编程要么正在为软件开发者提供前所未有的生产力飞跃，要么正在粗制滥造地批量生产设计低劣的代码——这些代码不仅消耗了开发者的精力，还给软件项目埋下了严重的长期维护隐患。
问题在于，目前很难判断哪一种说法才是真相。
随着科技巨头向大语言模型（LLM）投入数十亿美元，编程被吹捧为这项技术的“杀手级应用”。微软 CEO 萨提亚·纳德拉（Satya Nadella）和谷歌 CEO 桑达尔·皮查伊（Sundar Pichai）都宣称，他们公司现在约有四分之一的代码是 AI 生成的。今年 3 月，Anthropic 的 CEO 达里奥·阿莫代（Dario Amodei）更是预测，六个月内 90% 的代码将由 AI 编写。这是一个极具吸引力且显而易见的用例：代码是一种语言形式，我们需要大量的代码，而人工编写代码非常昂贵。此外，代码是否有效很容易验证——运行程序，它是否具备功能性是一目了然的。
高管们迷恋于突破人类瓶颈的潜力，正推动工程师们全面拥抱 AI 驱动的未来。
但在采访了 30 多位开发人员、技术高管、分析师和研究人员后，《麻省理工科技评论》（MIT Technology Review）发现，情况并不像看起来那么简单。
对于一些身处一线的开发人员来说，随着他们撞上技术的局限性墙壁，最初的热情正在消退。而且，随着越来越多的研究表明所谓的生产力提升可能是虚幻的，一些人开始质疑“皇帝是否真的穿了衣服”。
不过，技术进步的速度让局面变得更加复杂。新模型的持续发布意味着这些工具的能力和缺陷都在不断演变。而且，它们的效用往往取决于所应用的具体任务以及围绕它们建立的组织结构。所有这一切都让开发人员在期望与现实之间令人困惑的差距中艰难摸索。
借用狄更斯的话，对于 AI 编程来说，这究竟是最好的时代还是最坏的时代？也许两者皆是。
一个快速发展的领域
如今，很难避开 AI 编程工具。市面上有令人眼花缭乱的产品，既有来自 Anthropic、OpenAI 和 Google 等模型开发商的产品，也有像 Cursor 和 Windsurf 这样的公司，它们将模型包装在精美的代码编辑软件中。根据 Stack Overflow 的 2025 年开发者调查，这些工具正在被迅速采用，65% 的开发者现在至少每周使用一次。
AI 编程工具最早出现于 2016 年左右，但随着 LLM 的到来而被“注入了超能力”。早期版本的功能仅限于程序员的自动补全，提示接下来该输入什么。如今，它们可以分析整个代码库、跨文件编辑、修复漏洞，甚至生成解释代码工作原理的文档。所有这些都是通过聊天界面中的自然语言提示来引导的。
“智能体（Agents）”——即由 LLM 驱动的自主编程工具，能够接受高层计划并独立构建整个程序——代表了 AI 编程的最新前沿。这一飞跃得益于最新的推理模型，它们能够分步处理复杂问题，更关键的是，能够访问外部工具来完成任务。
“这就是模型能够真正‘写代码’，而不仅仅是‘谈论代码’的方式，”Anthropic 旗下编程智能体 Claude Code 的负责人 Boris Cherny 说道。
这些智能体在软件工程基准测试（衡量模型性能的标准化测试）上取得了惊人的进步。当 OpenAI 在 2024 年 8 月推出 SWE-bench Verified 基准测试（一种评估智能体修复开源库中真实漏洞成功率的方法）时，顶级模型仅解决了 33% 的问题。一年后，领先模型的得分已持续超过 70%。
今年 2 月，OpenAI 创始成员、特斯拉前 AI 总监安德烈·卡帕西（Andrej Karpathy）创造了**“氛围编程（vibe coding）”**一词——意指人们用自然语言描述软件，然后让 AI 编写、优化和调试代码的方法。社交媒体上充斥着认同这一愿景的开发者，他们声称生产力得到了巨大提升。
但是，尽管一些开发者和公司报告了此类生产力收益，但确凿的证据却喜忧参半。GitHub、Google 和 Microsoft（均为 AI 工具供应商）的早期研究发现，开发者的任务完成速度提高了 20% 到 55%。然而，咨询公司贝恩（Bain & Company）9 月份的一份报告则称现实世界的成本节约“平平无奇（unremarkable）”。
开发者分析公司 GitClear 的数据显示，自 2022 年以来，大多数工程师产出的持久代码（durable code）——即几周内未被删除或重写的代码——大约增加了 10%，这可能归功于 AI。但这一收益伴随着代码质量多项指标的急剧下降。 Stack Overflow 的调查也发现，人们对 AI 工具的信任度和积极情绪首次显著下降。最具挑衅性的是，非营利研究机构“模型评估与威胁研究”（METR）7 月份的一项研究表明，尽管资深开发者认为 AI 让他们快了 20%，但客观测试显示他们实际上慢了 19%。
日益增长的幻灭感
对于软件咨询公司 Substantial 的首席开发人员 Mike Judge 来说，METR 的研究触动了他的神经。他是 AI 工具的热情早期采用者，但随着时间的推移，他对这些工具的局限性及其对他生产力带来的微薄提升感到沮丧。“我当时在向人们抱怨，‘它确实在帮我，但我搞不懂怎么让它帮我更多，’”他说，“我一直觉得 AI 很笨，但也许如果我找到了正确的‘魔法咒语’，就能骗过它让它变聪明。”
当一位朋友问起时，Judge 曾估计这些工具大约提供了 25% 的速度提升。因此，当他在 METR 研究中看到归因于开发者的类似估算值时，他决定测试一下自己。
在六周的时间里，他会预估一个任务需要多长时间，通过抛硬币决定是否使用 AI，并为自己计时。令他惊讶的是，使用 AI 实际上让他的速度中位数下降了 21%——这与 METR 的结果如出一辙。
这让 Judge 开始研究数据。他推断，如果这些工具真的在为开发者加速，你应该能看到新应用、网站注册、电子游戏和代码托管平台 GitHub 上的项目出现大规模爆发。他花了几个小时和几百美元分析了所有公开可用的数据，结果发现到处都是平缓的线条。
“这难道不应该是一条向右上方飙升的曲线吗？”Judge 说，“那些图表上的‘曲棍球棒’（指数级增长）在哪里？我以为大家现在的生产力都高得惊人呢。”他说，显而易见的结论是，对于大多数开发者来说，AI 工具几乎没有提供生产力提升。
接受《麻省理工科技评论》采访的开发者普遍认同 AI 工具擅长的领域：生产“样板代码”（boilerplate code，即在多处重复且修改很少的代码块）、编写测试、修复漏洞以及向新开发者解释陌生代码。几位开发者指出，AI 通过提供一个不完美但可用的初稿，帮助克服了“空白页问题”，激发了开发者的灵感。它还可以让非技术同事快速构建软件功能原型，从而减轻本已过度劳累的工程师的负担。
这些任务通常很枯燥，开发者通常乐于将它们移交出去。但它们只占资深工程师工作量的一小部分。许多开发者告诉《麻省理工科技评论》，对于那些工程师真正赖以生存的更复杂问题，这些工具面临着重大障碍。
也许最大的问题是，大语言模型（LLM）在其“上下文窗口”（本质上是它们的工作记忆）中只能容纳有限的信息。这意味着它们难以解析大型代码库，并且在执行较长任务时容易忘记自己在做什么。“它变得非常目光短浅——只会盯着眼皮底下的东西，”Judge 说，“如果你让它做一打事情，它会做完其中 11 件，然后就把最后一件彻底忘了。”
LLM 的短视会给人类程序员带来头痛。虽然 LLM 对某个问题的回应在孤立状态下可能有效，但软件是由数百个相互关联的模块组成的。如果构建这些模块时没有考虑到软件的其他部分，很快就会导致一个纠缠不清、不一致的代码库，让人类难以解析，更重要的是，难以维护。
开发者传统上通过遵循“约定”（conventions）来解决这个问题——即在不同项目和团队之间差异巨大的松散定义的编码准则。“AI 有一种压倒性的倾向，即不理解代码库内现有的约定是什么，”GitClear 的 CEO Bill Harding 说，“因此，它非常可能会针对如何解决问题想出一套稍微不同的版本。”
模型有时也会直接出错。像所有 LLM 一样，编程模型容易“产生幻觉”——这是它们工作原理中固有的问题。广告技术公司 Mediaocean 的软件工程总监 James Liu 表示，由于它们输出的代码看起来非常完美，错误可能很难被发现。把所有这些缺陷加在一起，使用这些工具的感觉就像是在拉一台老虎机的手柄。
堆积如山的债务
达特茅斯学院工程创新教授 Geoffrey G. Parker 说，开发者经常在开发速度和代码可维护性之间进行权衡——从而产生了所谓的**“技术债务”**。每一条捷径都会增加复杂性，使代码库更难管理，从而积累了必须最终通过重构代码来偿还的“利息”。随着这种债务的堆积，添加新功能和维护软件变得越来越慢、越来越难。
GitClear 的 Harding 表示，在大多数项目中积累技术债务是不可避免的，但 AI 工具让时间紧迫的工程师更容易偷工减料。GitClear 的数据表明这正在大规模发生。自 2022 年以来，该公司发现复制粘贴的代码量显着增加——这表明 AI 正在建议开发者重用更多从别处获取的代码片段——而代码从一处移动到另一处的数量（这通常发生在开发者整理代码库时）则出现了更大的下降。
Sonar 是一家制作代码质量检查工具的公司，其 CEO Tariq Shaukat 表示，随着模型的改进，它们生成的代码变得越来越错综复杂。他说，这正在减少明显的漏洞和安全漏洞的数量，但代价是增加了**“代码异味（code smells）”**的数量——即那些难以定位的缺陷，会导致维护问题和技术债务。
Sonar 最近的研究发现，在领先的 AI 模型生成的代码中，这些问题占到了 90% 以上。“容易发现的问题正在消失，剩下的是需要很长时间才能发现的更复杂的问题，”Shaukat 说，“这就是目前这个领域让我们担心的地方。你几乎被诱入了一种虚假的安全感中。”
乔治城大学的安全研究员 Jessica Ji 表示，如果 AI 工具使维护代码变得越来越困难，那可能会产生重大的安全影响。“更新和修复东西越难，代码库或任何给定的代码块随着时间的推移变得不安全的可能性就越大，”Ji 说。
她说，还有更具体的安全担忧。研究人员发现了一种令人担忧的幻觉类别，即模型在代码中引用不存在的软件包。攻击者可以通过创建具有这些名称并包含漏洞的软件包来利用这一点，而模型或开发者可能会在不知不觉中将其整合到软件中。
已被转化的人群
尽管存在这些问题，但可能已经没有回头路了。“每行代码都由人工在键盘上敲出来的日子——这种日子正在迅速离我们远去，”GitHub 的首席运营官 Kyle Daigle 说道，该公司生产了一款名为 Copilot 的流行 AI 工具。
Stack Overflow 的报告发现，尽管对该技术的信任度日益下降，但在过去三年中，其使用率一直在迅速且持续地增长。Stack Overflow 的高级分析师 Erin Yepis 表示，这表明工程师们正在清楚地认识到风险的前提下利用这些工具。报告还发现，频繁使用的用户往往更热情，而且超过一半的开发者并未使用最新的编程智能体，这或许解释了为什么许多人仍然对该技术感到失望。
但是，虽然个人开发者正在学习如何有效使用这些工具，要在大型工程团队中获得一致的结果则要困难得多。Google 产品管理高级总监 Ryan J. Salva 表示，AI 工具会放大你工程文化中的优点和缺点。如果拥有强大的流程、清晰的编码模式和定义明确的最佳实践，这些工具就能大放异彩。
但如果你的开发流程混乱无章，它们只会放大问题。将这些机构知识编纂成典也至关重要，这样模型才能有效地利用它。“需要做很多工作来帮助建立上下文，并将部落知识（tribal knowledge，指团队内部不成文的经验）从我们的脑海中提取出来，”他说。
加密货币交易所 Coinbase 一直直言不讳地支持采用 AI 工具。CEO Brian Armstrong 在 8 月份透露公司解雇了不愿采用 AI 工具的员工，此举登上了头条。但 Coinbase 的平台负责人 Rob Witoff 告诉《麻省理工科技评论》，虽然他们在某些领域看到了巨大的生产力提升，但影响是不均衡的。
对于像重构代码库和编写测试这样的简单任务，AI 驱动的工作流实现了高达 90% 的速度提升。但 Witoff 表示，对于其他任务，收益较为温和，而且因彻底改革现有流程而造成的干扰往往抵消了编码速度的提升。
快速演变
不过，使用智能体（Agents）进行编程与以前的工作实践截然不同，因此公司面临一些初期问题也就不足为奇了。这些也是非常新的产品，每天都在变化。“每隔几个月模型就会改进，模型的编码能力就会出现巨大的阶跃变化，你就必须重新校准，”Anthropic 的 Cherny 说。
例如，Anthropic 在 6 月为 Claude 引入了内置的规划模式；此后其他提供商也纷纷效仿。10 月，该公司还启用功能，让 Claude 在需要更多上下文或面临多种可能的解决方案时向用户提问，Cherny 说这有助于避免它简单地假设哪条路径是最佳前进方式的倾向。
最重要的是，Anthropic 增加了让 Claude 更好地管理自身上下文的功能。Cherny 说，当它接近其工作记忆的极限时，它会总结关键细节并利用这些细节开启一个新的上下文窗口，从而有效地赋予它一个“无限”的窗口。Claude 还可以调用子智能体来处理较小的任务，因此它不再需要在自己的脑子里记住项目的所有方面。该公司声称，其最新模型 Claude 4.5 Sonnet 现在可以自主编程超过 30 小时而不会出现重大的性能下降。
软件开发的新方法也可以避开编程智能体的其他缺陷。麻省理工学院教授 Max Tegmark 引入了一种他称之为**“验证编程（vericoding）”**的方法，这可以让智能体根据自然语言描述生成完全无漏洞的代码。它建立在一种称为“形式化验证（formal verification）”的方法之上，即开发者创建其软件的数学模型，可以无可辩驳地证明其功能正确。
Tegmark 说，LLM 数学能力的快速提升开启了一种诱人的可能性，即模型不仅能生产软件，还能生产证明它是无漏洞的数学证明。“你只需要给出规范，AI 就会返回可证明正确的代码，”他说，“你不需要碰代码。你甚至根本不需要看代码。”
AI 生成代码的速度也可以缓解对可维护性的担忧。商业软件巨头 Intuit 的首席工程师 Alex Worden 指出，维护之所以困难，往往是因为工程师在项目中重用组件，造成了依赖关系的纠缠，以至于一个更改会触发整个代码库的连锁反应。Worden 说，过去重用代码是为了节省开发人员的时间，但在一个 AI 可以在几秒钟内生成数百行代码的世界里，这种必要性已经消失了。
相反，他提倡**“一次性代码（disposable code）”**，即每个组件都由 AI 独立生成，而不必考虑它是否遵循设计模式或约定。然后，它们通过 API（允许组件相互请求信息或服务的一组规则）连接。Worden 说，单个组件的内部运作不依赖于代码库的其他部分，这使得在不造成广泛影响的情况下将其剥离并替换成为可能。
“行业仍然在担心人类维护 AI 生成的代码，”他说，“我怀疑人类还会看代码或在乎代码多久。”
收窄的人才管道
然而，在可预见的未来，人类仍然需要理解和维护支撑其项目的代码。而 AI 工具最有害的副作用之一可能就是拥有这种能力的人才库正在萎缩。
早期证据表明，对 AI 破坏就业效应的担忧可能是有道理的。斯坦福大学最近的一项研究发现，2022 年至 2025 年间，22 至 25 岁软件开发人员的就业率下降了近 20%，这与 AI 编程工具的兴起相吻合。
经验丰富的开发人员也可能面临困难。电子游戏基础设施开发商 Companion Group 的工程师 Luciano Nooijen 在他的日常工作中大量使用 AI 工具（公司免费提供）。但是，当他开始一个无法使用这些工具的副业项目时，他发现自己很难完成以前自然而然就能完成的任务。“我觉得自己好蠢，因为过去凭本能就能做的事变成了手动的，有时甚至是繁琐的，”Nooijen 说。
他认为，就像运动员仍然要进行基本训练一样，保持编程直觉的唯一方法就是定期练习那些枯燥的基础工作。这就是为什么他在很大程度上放弃了 AI 工具，尽管他也承认还有更深层的动机在起作用。
Nooijen 和《麻省理工科技评论》采访的其他开发者之所以抵制 AI 工具，部分原因在于他们感觉这些工具正在掏空他们工作中热爱的部分。“我进入软件工程领域是因为我喜欢和计算机打交道。我喜欢让机器做我想做的事，”Nooijen 说，“坐在那里看着工作被别人（或机器）完成，这一点都不好玩。”
