AI 编程的边界：代码能跑≠系统可维护

dev.to · AI#AI编程#工程判断#代码质量

Editor brief · 编辑速览

AI 代理能生成通过测试的功能代码，但接口契约、不可变性边界、错误可见性等系统长期可维护性仍需工程师判断；生成式编程与工程判断的分工是核心议题。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

AI Agent 能写代码，但工程决定它能不能活下来。

AI 工具已经跨越了最简单的问题：它们能产出可以运行的软件吗？能。问题紧随其后：这些软件是否融入系统、能否自解释其错误、能否在持续变化中不变成一团乱麻？

在这篇引发上述思考的文章中，Joseph Heck 将能力展示与工程工作区分开来。他认可测试套件和模型在构建和测试代码方面的增益，但坚持认为：API、层级、契约以及与现有系统的集成——这些衔接点——仍然需要人工判断[1]。

能跑的代码不等于完成

一个 Agent 可以生成一个功能，通过它收到的所有测试，却仍然交付一段难以调试的变更。这在需求只描述了即时行为、却没有明确维持系统可维护性的决策时就会发生：

这些问题不是开发流程中的繁文缛节。它们决定了未来的维护形态。没有它们，生成文件的速度就变成了将技术债务转嫁给下一个人的速度。

新的瓶颈在于选择

AI 降低了尝试一个实现的成本。这非但没有减少，反而增加了选择正确实现的价值。

当生产代码只需几分钟，接受过多备选方案就很廉价。一个团队可以在决定到底在解决什么问题之前，就生成三个集成方案、两个数据模型和一层抽象。真正的收益来自缩短这个循环：提出假设、固定边界、验证结果、丢弃无用的部分。

这就是架构仍然是具体活动的原因。它不是在编码之前画方框图，而是定义那些允许替换其中一个部分而不破坏其他部分的契约。是将系统的认知负荷维持在一个水平——让一个人在事故发生时能够检查。

在有可靠反馈的地方使用 Agent

Agent 的最佳场景不是"构建整个系统"。而是一个短小可验证的序列：

Heck 恰恰强调了恰到好处的简洁数据和确定性验证的价值——用自然语言反馈，以便 Agent 能够自我修正[1]。这是一个有用的指引：如果唯一的回报是"看起来不错"，整个流程就靠运气了。如果有契约、集成测试、可查询的日志和清晰的验收标准，工具就能在真实信号上迭代。

边界值得更多关注

一个错误的风险很少出现在 Agent 刚写的方法中。它出现在边界上：无法回滚的迁移、暴露了内部假设的 API、非幂等的 job、丢失上下文的失败处理、授予自动化过多读写或发布权限的许可。

这也改变了代码审查的方式。不只是问"实现正确吗？"，还值得问：

这些问题首先是软件工程问题，其次才是 AI 问题。

工具增加了对结果的责任

Agent 最好的副产品，可能是把时间归还给那些通常无人认领的工作：阅读系统、澄清接口、编写可逆的迁移、改善错误信息、移除那些只是因为有人过早创建而存在的抽象。

我们不需要在使用 AI 和尊重基础原则之间做选择。代码生成越容易，让代码可运维、可读、可修改的标准就越重要。差异将不在于谁向模型请求了更多文件，而在于谁构建了反馈循环，并做出了模型无法自行承担的决策。