AI 接管 Coding 后,软件开发将走向哪里?

SOFTWARE / 2026

从写代码，到定义并证明软件

过去，我们向 AI 提的编程请求通常是这样的：

现在，越来越多请求变成了：

两句话都和代码有关，却不是同一种工作。

前者要求 AI 生成一段实现；后者要求它阅读代码库、判断影响范围、修改多个文件、运行工具、分析错误，再用测试结果决定下一步。

变化的关键，不是 AI 一次能写多少行代码。

一、AI Coding 只是入口

代码补全和对话式生成解决的是局部问题。它们让一个函数、一段 SQL 或一个组件更快出现。

但软件工程最费力的部分，往往发生在代码生成之外：

• 需求究竟意味着什么；

• 改动会碰到哪些系统边界；

• 旧行为是否必须兼容；

• 失败发生在代码、配置还是环境；

• 测试通过之后，结果是否真的符合业务要求。

这也是为什么真实仓库任务比代码片段更值得观察。SWE-bench 不再只问模型能不能补完一个函数，而是给它一个真实代码库和 GitHub issue，要求生成能够解决问题的补丁。其 Verified 子集包含 500 个经工程师确认可解决的问题，并用容器化环境执行评估。^[1]

这类基准并不等于真实生产环境，但它至少改变了问题的尺度：AI 面对的不再是一张空白答题纸，而是一套已经存在、充满约束的软件系统。

二、Agentic Engineering 的本质，是闭环

代码生成器与软件工程 Agent 的分界，不在于回答有多长，而在于它能否形成反馈闭环。

Anthropic 把固定路径的系统称为 workflow，把能够动态决定过程和工具使用方式的系统称为 agent。对编码任务而言，这个循环通常是：

Agent 必须不断从环境中取得 ground truth：命令有没有成功、页面是否真的渲染、测试在哪里失败、改动是否引入新的回归。没有这些反馈，它仍然只是一个更会说话的代码生成器。^[2]

于是，代码的角色开始发生变化。它当然仍是软件的重要组成部分，却不再是 Agent 工作的唯一终点。计划、补丁、测试结果、运行日志和验证证据，共同构成了任务的交付物。

这就是 Agentic Engineering：人类给出目标和边界，Agent 在工具与环境反馈中推进实现，人类在关键节点判断方向与结果。

三、别把能力演示等同于生产效率

到这里，很容易得出一个过快的结论：既然 Agent 已经可以解决真实 issue，程序员的实现工作很快就不重要了。

现实没有这么整齐。

2025 年，METR 对 16 名长期参与大型开源项目的资深开发者做了一项随机实验。他们提交了 246 个原本就有价值的 bug、功能和重构任务。结果是，在允许使用当时的 AI 工具时，开发者完成任务平均多花了 19% 的时间。更有意思的是，参与者事前预计 AI 会让自己提速 24%，实验后仍认为 AI 让自己快了 20%。^[3]

这个结果不能被概括为“AI 编程没有用”。研究对象是熟悉大型仓库的资深开发者，工具也停留在 2025 年初。METR 自己明确反对把结论外推到所有开发者、所有项目和未来工具。

AI 能写出补丁，不等于团队已经拥有能吸收这些补丁的工作流。生成之后的阅读、等待、纠错、风格调整和信任校验，都可能抵消节省的时间。

所以下一阶段的竞争不会只发生在模型上。上下文如何组织、工具接口是否清楚、测试能否快速给出反馈、风险操作在哪里停下来，这些“模型之外”的工程，决定了 Agent 能否真正进入生产。

四、从 Prompt 走向 Specification

自然语言适合表达方向，却不天然适合约束复杂系统。“做一个类似微信的产品”可以启动讨论，却无法告诉实现者权限、状态、兼容边界、性能底线、异常行为和验收标准。

当 AI 接手更多实现工作，这些原本散落在会议、代码评审和工程师经验里的隐性知识，必须被更明确地写出来。

这就是 Prompt 走向 Specification 的过程。

它已经不只是一种概念推演。GitHub 的 Spec Kit 把开发流程组织为 Specify、Plan、Tasks、Implement，并强调先定义“做什么”，再决定“怎么做”；规格通过多轮细化成为 Agent 的结构化上下文，而不是一次性提示词。^[4]

我愿意把这种工作称为 Specification Engineering。

它不是写一份长文档然后交给 AI，而是持续维护一套可以驱动实现、暴露冲突并支持验收的意图系统：需求、边界、约束、示例、失败条件和验证方法必须彼此一致。

当实现越来越便宜，含糊的需求反而会变得更昂贵。因为 AI 可以很快把一个不清楚的意图扩散成大量看似完整的代码。

五、编程语言不会消失，但会重新分层

如果人类不再亲自写每一行代码，编程语言还有必要吗？

有，而且原因比“AI 还不够强”更根本。

代码不仅是给编译器的指令，也是团队理解系统、审计风险、处理事故和追踪责任的共同介质。即使大部分改动由 AI 完成，人类仍需要在关键时刻读懂它、质疑它，并接管它。

变化更可能发生在评价维度上。我们不仅要问代码是否清楚、可维护，还要问 Agent 能否准确定位影响范围，接口、类型和依赖是否明确，改动能否通过自动化证据验证，失败时人和 Agent 能否快速恢复上下文。

这不是用“AI 可读性”替换“人类可读性”，而是在代码质量上增加新的使用者和新的约束。

未来或许会出现更适合 AI 操作的中间表示，甚至为特定项目生成 DSL。但语言容易生成，不代表生态、调试、迁移和长期维护也会自动变便宜。

六、真正稀缺的，会是三种能力

1. Intent：决定什么值得做

AI 可以把一个想法实现得很快，却不能替组织承担“为什么要做”的责任。问题选错了，更快的实现只会更快地产生维护成本。

2. Judgment：决定什么可以接受

Agent 可以提出多个方案，但复杂度、演进空间、安全风险和业务取舍没有统一答案。判断不是从十个答案里选一个，而是知道哪些代价不能交换。

3. Verification：证明结果真的成立

Agent 之所以适合编码，一个重要原因是代码能够运行，测试能够反馈。但测试通过只证明测试覆盖到的部分成立。Anthropic 在总结编码 Agent 时也强调，自动化测试能验证功能，人工审查仍然需要确认结果是否符合更广泛的系统要求。^[2]

未来最重要的工程资产，可能不只是代码库，还包括高质量测试、可复现环境、观测能力、验收标准和决策记录。

因为生成越快，错误也越容易被批量放大。

七、程序员不会消失，但交付物会变化

我们可以用四个阶段理解这次迁移：Programming 是人类直接写代码；AI Coding 是 AI 帮助完成局部实现；Agentic Engineering 是 AI 在工具和环境反馈中完成软件任务；Specification Engineering 则是人类重点维护意图、约束和验证，AI 承担更多实现循环。

这不是一张所有团队都会按时经过的路线图。同一个组织里，低风险工具可能已经进入第三阶段，核心支付系统仍然停留在严格的人类实现与审查中。

真正变化的是工程师的主要交付物。

开发环境也会随之改变。代码编辑器不会消失，但旁边会长出任务控制台、系统地图、Agent 工作区和验证中心。一个文件、一个光标，仍然重要，却不再代表软件生产的全部界面。

结语

所以，AI 接管 Coding 之后，软件开发仍然需要编程。只是 Programming 可能不再独占中心。

代码会继续存在，编程语言会继续演化，工程师也仍然需要理解实现。与此同时，人类的工作重心会逐渐向上游移动：把模糊愿望变成明确意图，把明确意图变成可执行规格，再用可靠证据证明软件确实满足它。

过去几十年，编程语言帮助我们更容易地告诉机器“怎么做”。

这或许就是从 Coding 走向 Specification Engineering 的真正含义。