当人工智能编写代码：具有价值的工程技能

编写代码正逐渐成为软件工作中最简单的一部分。决定要开发什么、检查人工智能生成的成果以及识别错误何时出现，这些才逐渐成为至关重要的技能。

有一个问题不断被提及：如果人工智能能够编写大部分代码，那么开发者还剩下什么工作？这是一个错误的问题。更好的问题是，如今开始软件职业的人应该学习哪些人工智能难以轻易替代的技能。

显然已经发生了变化。Claude Code、Codex、Copilot、Cursor等工具早已超越了简单的自动补全功能。它们能够读取整个代码库，编辑多个文件，运行命令，编写测试用例，追踪故障，并持续处理任务直至完成。尤其是Claude Code，早已超越了“为我写一个函数”的简单功能，更像是一个存在于代码库中的工程智能体。这彻底改变了相关工作的性质。

代码的成本正在降低

不久前，开发人员可能需要花费半天时间来完成一个功能。而现在，这个功能只需向智能体描述一下即可：

Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.

接着，该代理就开始工作。它会创建文件、编辑现有类、运行测试、遇到错误后调整实现方式，然后再重新运行测试。这一切都已不再是假设而已。

值得注意的一点是，开发者并没有从这个过程中消失。开发者变成了对结果负责的人，这一区别非常重要。

Anthropic的案例所揭示的要点

Anthropic是最典型的例子之一，因为该公司在实际开发中就使用了Claude Code。其创始人Boris Cherny曾公开谈到公司内部的工程实践发生了多大变化，今年早些时候的报道也指出，在某些工程工作中几乎所有代码都是由人工智能生成的。

开发者应当关注一个后果：生成的代码越多并不意味着工程工作量就会减少，反而可能意味着责任更重。假设Claude生成了5,000行代码，那么现在就有人需要对此负责：

Is the architecture correct?

Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?

人工智能可以提供实现方案，但后果仍由你承担。

围绕这一问题的更大争议

据公开报道，前Anthropic研究员雅各布·考克森于2026年9月宣布辞职。他的警告并非针对Claude能否写出合格的JavaScript代码，或是人工智能能否构建Spring Boot API，而是关乎能力日益强大的人工智能系统将走向何方。据称，他在X平台上的帖子触达了超过1亿人，他认为各大研究机构正在过快地朝着自主化且可能具有危险性的系统发展。

这一观点颇具分量，因为它出自一位曾在相关技术公司工作的人之口。这一讨论已经变得十分严重，以至于Anthropic的首席执行官达里奥·阿莫代也呼吁放缓前沿技术的发展速度，并加强对人工智能系统的独立评估。

因此，2026年的局面颇为有趣。一种观点认为人工智能能极大加速软件开发；另一种观点则来自那些构建这些系统的人，他们认为大家应当更加谨慎地看待这种加速会带来什么后果。这两种观点完全可以同时成立。

最大的错误

最大的错误并非避免使用人工智能，而是在不了解其产出结果的情况下就加以使用。举个例子：

@GetMapping("/users")
public List<User> getUsers() {
    return userRepository.findAll();
}

人工智能两秒钟就能写出这样的代码。应该上线吗？也许可以。但如果表格有2000万行怎么办？如果没有分页功能呢？如果接口是公开的，或者User类型包含敏感字段，又或者有五千人同时调用它怎么办？从技术层面看代码是可行的，但工程决策仍可能是糟糕的。这就是区别所在。

应该学习什么

在2026年开始入行的话，最好少花时间记忆语法，多去了解系统的实际运作方式：

• 系统设计与分布式系统
• 数据库、API与网络技术
• 安全性
• 调试与测试
• 性能与可观测性
• 云基础设施
• 人工智能智能体的工作原理

编写代码依然重要，但开发人员的评价标准已从输入的行数转向将复杂问题转化为可靠系统的能力。人工智能在处理这类任务方面已经非常出色：

Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.

越来越有价值的开发者，是那些能够给出如下回应的人：

Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.

AI并未消除思考的必要性

问题在于：虽然AI让编程变得更简单，但如果程序员因此停止思考，他们的能力反而可能下降。已有相关证据：Anthropic的一项研究显示，在学习不熟悉的编程库时，使用AI辅助工具的开发者在理解测试中的表现更差，尽管AI在其他场景下确实能提升效率。

关键并非停止使用AI，而是避免完全将学习过程交由AI处理。当Claude给出解决方案时，先阅读它，再分析其逻辑，尝试修改，并思考其为何有效以及存在哪些缺陷。可以先手动构建一个简化版本，然后再求助于AI。这样的方法远比单纯依赖AI有效得多：

Prompt → Copy → Commit → Next task

新的软件工程师

工程师本身并未消失，但这份工作变得愈发艰难。那些仅能将需求转化为CRUD代码的初级开发人员，其立足点比以往更为薄弱。而那些能够理解业务问题、架构设计、安全机制、系统故障原因以及如何运用AI工具的人，能力则大幅提升。如今，一名拥有优秀工具的工程师就能探索过去需要整个小团队才能完成的想法。

这固然令人兴奋，但也充满风险，因为当软件的开发成本降低时，劣质软件的成本也会随之下降。很快就会出现数以百万计由AI生成的应用程序，创建它们并不困难，但判断哪些应用值得存在却是个难题。

如今作为开发人员该做些什么

在编写代码时与人工智能竞争是必输的博弈。应当积极运用人工智能，同时提升审查其输出结果的能力。了解真实系统为何会出故障，掌握API背后的数据库机制以及部署后的运行情况。研究安全性问题及自动化工具的工作原理。必要时仍要保留不依赖人工智能独立开发的能力。

未来很可能不是人类与人工智能的对决，而更像是拥有人工智能的开发者与没有人工智能的开发者之间的竞争。更进一步而言，那些明白该构建什么、为何要构建以及何时不应构建的开发者，可能会比那些仅会生成代码的人更有价值。人工智能降低了编写代码的成本，同时也让工程决策的价值愈发重要。