6 月 19 日，巴西开发者 Vinicius Brasil 在个人博客发表「当我拒绝 AI 代码，即使它能跑」。文章在 Hacker News 上获得 237 个赞、167 条评论，讨论集中在一个日常工程问题上：AI 生成了大量代码之后，开发者能否理解并为这些改动负责。
四天后的 6 月 23 日，Flask 和 MiniJinja 的作者 Armin Ronacher 发布「The Coming Loop」。他关注的是，在外部控制程序驱动的循环中，编码 Agent 不断接收反馈和重试，减少人类中途介入。他担心某些长期维护的代码会因此越来越难理解：「我为代码设置了很高的标准，我想理解我交付的代码。」
两篇文章从个人审查经验与自动化流程两个角度，提出了相近的担忧：代码生成越快，理解和审查这些代码所需的时间就越值得重视。这些是两位开发者的实践观察，也为团队评估 AI 编码收益提供了具体问题。
五条拒绝标准，都要求开发者理解改动
Vinicius Brasil 列出了他拒绝 AI 代码的五条具体标准：
- 当 diff 比问题本身还大，拒绝。
- 当代码尚未证明需要某种抽象就将它引入，拒绝。
- 当代码在本地能跑但让整个系统更难推理，拒绝。
- 当无法用自己的话解释代码的实现方式，拒绝。
- 当信任的是 AI 的输出而不是自己的理解，拒绝。
这五条规则关注的是设计是否合适、系统是否易于理解，以及开发者能否解释自己的改动。功能正确是必要条件，合并代码时还要考虑它如何融入现有系统。
他在文章中描述了一种认知过载：「即使我遵循了好的实践——从 plan 模式开始、把大任务拆成小阶段、小批量交付——审查那些我没有真正思考过的代码，仍然让我感到认知过载。」他说，用 AI 完成大任务仍然需要几天，而「更多时候，我拒绝 AI 的所有改动，然后从头开始。第一次会话和第二次的区别不是 LLM 模型，而是屏幕后面的人。」
Hacker News 用户 panchtatvam 用更激烈的措辞表达了怀疑：「你只有在认为自己比 AI 蠢的时候才应该接受 AI 代码。」这反映了部分参与者的不信任；Brasil 自己列出的判断标准，则更具体地落在改动规模、抽象和理解程度上。
代码质量研究提示风险，但样本与指标各不相同
一些代码质量研究提供了更大范围的观察。GitClear 在 2024 年发布的分析覆盖 2020–2023 年约 1.53 亿行代码变更，关注到短期改写增多和移动复用代码减少的趋势。这里的 churn 指新写代码在两周内被修改或删除的比例；整体仓库趋势与 AI 使用的关系，需要结合采用情况来判断。CodeRabbit 对 470 个开源 Pull Request 的分析则发现，AI 参与编写的 PR 平均有 10.83 个问题，人工 PR 为 6.45 个，前者约为后者的 1.7 倍。这是按 PR 统计的问题数，并非每一行 AI 代码的出错概率。
Of Ash and Fire 的工程领导力指南将审查负担和技术债务列为需要关注的成本。Uplevel 在 2024 年公布的研究，追踪了约 800 名开发者采用 GitHub Copilot 前后的工程指标，并设有未获 Copilot 访问权的对照组。研究报告称，采用 Copilot 后，样本中的 PR 缺陷率增加 41%，PR 周期和吞吐量没有显著改善。它反映了当时工具、团队与使用方式下的结果，后续模型和流程仍需重新评估。
这些结果提醒团队，衡量生产率时需要同时看交付速度、缺陷与维护投入，单独计算生成了多少代码并不充分。
自动重试可能不断增加局部防御代码
Armin Ronacher 所说的「The Coming Loop」，指的是编码 Agent 外层的控制循环：任务进入队列，机器尝试执行，随后由控制程序判断是否结束；如果没有完成，就继续当前会话、调整上下文，或者将任务交给另一个 Agent。它延长了自主工作的时间，也减少了人在每一步介入设计的机会。
Ronacher 坦诚地写道：「对于我真正在乎的代码，我还没有用这种方式取得太多成功。」按他自己的代码偏好，当模型在一个循环中无间断工作 30 分钟或更久时——比如 Claude Code 配合 Fable 模型——产出的代码比去年秋天人工介入较多的流程「更差」。
Ronacher 将问题归于自己观察到的一种模型倾向：面对局部失败，添加局部防御和回退处理。Karpathy 将其形容为「对异常有致命恐惧」。但在依赖重要约束的系统中，有时更合适的修复是让非法状态无法产生。若每轮迭代都只多加一层防御，系统可能显得更健壮，却更难理解。
「当你在循环后面加入更多循环，每个迭代添加另一个小防御，系统慢慢地变得更不可理解，同时看起来更健壮。你越放手，这种情况就越严重，」Ronacher 写道。
长期维护的代码，需要检验设计是否一致
AI 编码能力的讨论常常关注模型能否生成正确算法、补全函数或通过 LeetCode 测试。这些能力有价值，但它们只覆盖软件交付的一部分。
Vinicius Brasil 和 Armin Ronacher 更关注可维护性：代码完成眼前任务后，是否值得保留，六个月后团队还能否理解它。
Of Ash and Fire 的分析将缺乏实现理解、只凭运行效果不断提示生成的方式称为「vibe coding」。文章认为，随着代码库扩大，不一致的架构、重复逻辑、浅层抽象和脆弱测试，会让后续修改更加困难。
GitClear 关于代码重复与短期改写的观察，也让复用和返工成为值得追踪的指标。对具体团队来说，更有用的是持续检查自己的代码库：相似逻辑是否越来越多，同一处实现是否反复修补，新成员是否更难理解设计。
把理解、审查与任务边界纳入编码流程
Brasil 使用 coding agent 已有一段时间，承认它们「令人印象深刻」。Ronacher 也参与 Pi 的开发，这个工具本身就被用于构建外部控制循环。他还肯定自动循环在代码移植、性能实验和安全扫描中的作用，并提到自己成功将 MiniJinja 移植到 Go 的经验。他的保留意见主要针对需要长期维护、而负责人难以理解的代码。
结合两人的实践与代码质量讨论，团队可以把以下要求落实到工作流程中：
第一，理解优先于合并。代码必须能被解释，不只是能运行。Ronacher 写道：「在压力下，或在与其他人的讨论中，我希望能够解释系统做了什么，而不需要先让一个 clanker 解释给我听。」
第二，检查防御代码是否必要。对每一层回退和异常处理，都要确认它解决的是什么问题。能通过数据结构与系统约束避免非法状态时，就不必不断叠加局部补丁。
第三，保留明确的审查责任。团队可以要求开发者说明 AI 参与的范围，并确认提交者能解释实现。认证、授权、输入验证和数据处理等部分，需要按其风险进行严格审查，不能只以测试通过作为合并依据。
第四，按任务划定自动化边界。代码移植、短期实验与核心业务实现，对可验证性和长期维护的要求不同。认证授权、性能关键路径和新架构等任务，应先明确设计约束、验证方法与负责人，再决定交给 Agent 自主完成多少工作。
交付提速之后，仍要有人能解释并维护系统
6 月下旬的这两篇博客，使 AI 编码讨论进一步关注交付之后的工作。Brasil 的文章吸引了 167 条评论，说明这类审查体验引起了不少开发者的共鸣；讨论的价值，在于把模糊的不满意拆成可以检查的工程问题。
Ronacher 对自动循环的前景仍持肯定判断：「我毫不怀疑这就是未来的方向。」他提出的问题是，在这样的工作方式中，「我们如何不放弃判断，如何保留好的工程规则，如何确保负责任的人能够继续监督。」
代码写完之后，团队还要修改需求、定位故障和解释系统行为。AI 节省的编写时间，最终需要与这些持续发生的工作一起计算。
