AI年内取代软件工程师？

当 Anthropic 的 CEO Dario Amodei 说我们可能距离能够完成软件工程师所做的一切只有 6 到 12 个月时，我不得不停顿。不是因为这是一个大胆的声明（在科技界这是正常的），而是因为 12 个月太具体了。

这不是"在未来"。那基本上是明年。

与此同时，Anthropic 为他们新的 Claude Opus 4.5 模型发布了基准测试，显示在编码、推理和处理复杂任务方面的重大改进。这些数字看起来确实令人印象深刻。

所以我开始想知道：这些基准测试是否真的意味着软件工程即将完全自动化？让我分解我认为这里实际发生的事情。

这里是 Dario Amodei 声称这一点的完整 YouTube 视频。

1、这些基准测试真正测试的是什么

根据 Anthropic 的说法，Claude Opus 4.5 在诸如 SWE-bench 等软件工程测试、需要许多步骤的长任务、复杂推理以及高效使用不同工具等方面，比早期版本要好得多。

Anthropic 报告的 Claude Opus 4.5 在编码和代理任务上相对于先前模型的基准测试改进。

你也可以参考 Anthropic 博客以获取详细视图。

他们还说它在扩展工作流期间保持专注。这实际上很重要，因为早期的 AI 模型在编写单个代码块方面不错，但在跨越多个步骤时记住上下文方面很糟糕。

如果这个差距正在缩小，自动化的潜力肯定会上升。

但这让我烦恼的是。像 SWE-bench 测试 这样的基准测试，衡量的是模型是否可以在受控环境中解决定义明确的问题，通常，有测试反馈来指导它。

这与实际软件工作的混乱现实完全不同。真正的项目有模糊的业务需求，每周都在变化。文档要么缺失，要么过时。来自第三方的 API 会在没有警告的情况下中断。部署管道用胶带勉强维持在一起。利益相关者都想要不同的东西。

基准测试在真空中测量技术技能。它们不衡量你在组织混乱中导航的能力。

2、我在实际开发工作中看到的

我一直在观察人们如何实际使用这些 AI 编码工具，模式非常清晰。

是的，AI 现在可以生成完整的可工作程序。我见过开发人员在几个小时内启动完整的全栈应用程序，而以前这需要几天。但他们一直说：编写代码从来不是困难的部分。

困难的部分是弄清楚要构建什么，处理变化的需求，管理技术债务，支持遗留系统，以及与有相互冲突优先级的人一起工作。

我还注意到特定的失败模式。AI 会修复 bug A，这会破坏功能 B。然后它修复 B，这又会破坏 A。这个循环一直持续，直到有人手动介入。AI 在孤立中优化每个部分，但看不到所有东西是如何连接的。

我经常遇到的另一件事是过度工程。AI 工具构建不必要的复杂解决方案，因为它们不会质疑原始方法。它们只是实施你要求的一切。它们不会回过头来说，"等等，这真的是最好的方法吗？"

我最常看到的模式是：AI 编写代码很快。人类仍然决定代码应该存在。

3、生产力提升是真实的，但也有限制

老实说，AI 已经处理了大量的实现工作。对于标准的 CRUD 操作、脚手架和基本集成，生产力提升是不可否认的。我在这些领域完成得更快。

但是当我从事复杂的分布式系统、关键安全代码或数据完整性问题时，我对 AI 的信心会显著下降。

我最近花了一周时间追踪导致跨多个服务级联失败的微妙上下文不匹配。AI 本来不会捕捉到这一点。另一次，我意识到向 AI 充分解释我的整个系统架构以生成正确的代码，将比我亲自编写它需要更长的时间。

4、为什么这些预测可能被夸大了

让我们花一点时间谈谈商业方面。

AI 公司正在为企业和投资者资金展开激烈竞争。关于激进的工作替代的声明会制造紧迫感。它们推动公司在竞争对手这样做之前，迅速地围绕 AI 工具重新构建工作流程。

我认为激进的自动化声明也可能在于塑造市场和预期，即使完全自动化没有按时到达。

别误解我。技术的进步速度惊人。但商业激励奖励乐观的时间表，而不是现实的时间表。

技术发展的方向与它在拥有实际约束的真实公司中实际部署的速度之间通常存在巨大差距。

5、实际上准备好自动化

基于我的经验和观察，以下是我的分析：

现在准备好高度自动化：

• 常见模式的代码
• 测试脚手架
• 重构现有代码
• 文档
• 内部工具

可能差不多在那里：

• 有人类监督的调试
• 多文件功能
• 当规格非常清楚时的 API 集成

甚至没接近：

• 系统架构决策
• 需求协商
• 权衡分析
• 生产可靠性调用
• 安全建模
• 长期维护策略

根据开发人员工作流程和当前 AI 能力的软件工程任务近似自动化准备程度。

实现变得快得多。但不确定性下的决策制定并没有消失。

这解释了我周围的情况。工程师更有效率，但不那么重要。

6、真正的工作从来不仅仅是打字

这是我学到的：软件工程中最困难的部分一直是决定要构建什么以及为什么。

代码只是该决策的可见结果。工程是塑造它的不可见思维过程。

AI 确实在非常擅长处理"如何"。它远没有掌握"为什么"。

而这有个关键点：错误的"为什么"决策随着系统的增长而变得更昂贵。更快的实施意味着错误传播得更快，也是。

具有讽刺意味的是，这可能会使强大的架构判断更有价值，而不是更少。

7、"端到端自动化"实际上意味着

让我将其分成两种场景。

如果端到端意味着"AI 在给定正确的、详细的规范时可以生成可工作的代码"，那么是的，我们离那个已经非常接近了。

如果端到端意味着"AI 可以找出正确的规范，解决利益相关者之间的冲突，管理不断变化的需求，并对系统结果负责"，那么不，我们根本不接近。

第一个是技术实现问题。第二个是组织和认知问题。

基准测试主要衡量第一个。

8、我对明年的预测

以下是我认为未来 12 个月内实际会发生的事情：

我们将会看到更少的纯实现导向的初级职位。对于能够明确定义问题并做出良好架构决策的工程师，需求将会增加。基于代理的编码工具将成为标准。原型设计和迭代将会快得多。

但我们也将会看到对人类系统拥有权的持续需求。严重依赖高级工程师进行审查和决策。当公司将自动化推入定义不明的领域时，会有大量的失败。

软件工程在一年内将会感觉非常不同。但我不认为角色本身在 12 个月的时间线上消失。

我认为完全自动化的预测混淆了能力增长与组织中的实际替代。

如果历史教给我们任何东西，那两件事很少以同样的速度移动。

你怎么看？我们真的距离 AI 取代软件工程师还有 6 到 12 个月吗，还是这只是另一个过度炒作的时间线？我很想在评论中听到你的观点。

原文连接：Will AI Really Replace Software Engineers in 12 Months?

汇智网翻译整理，转载请标明出处