问 HN：如何处理你看不懂的 AI 生成代码上线？

测试、验证，以及“只要能跑就行”

• 许多人认为，发布 AI 生成代码的唯一稳妥方式是进行大量自动化测试：大规模单元测试和集成测试套件、跨架构测试农场、fuzzing、混沌测试、变异测试，以及端到端测试。
• 有些人严格采用 TDD，包括用于 agents：先让 agent 写失败的测试，再写代码直到测试通过。
• 另一些人担心让同一个 LLM 既写代码又写测试很危险，因为它们可能共享盲区；缓解方式包括：
  • 将“代码”与“测试”分成不同的 agent。
  • 在对抗性审查循环中使用多个不同的 LLM。
  • 故意注入故障并验证测试能否捕捉到它们。
• 也有人坚持认为仅靠测试远远不够：它们不能验证设计，不能证明不存在漏洞，而且 AI 写的测试往往很弱，或者只是自我合理化。

架构、设计，以及人的角色

• 一种常见模式是：人类设计架构和抽象（“骨架”），LLM 填充实现（“血肉”）。
• 人们强调事先规划：功能设计文档、实现计划、架构图、不变量和契约；然后由 LLM 在这些约束内实现。
• 有些人把这类工作类比为首席工程师：你理解意图和结构，而不是每一行代码。
• 也有人说，如果你不理解代码，那你实际上是经理/规格撰写者，而不是工程师。

质量、技术债与安全

• 支持者报告了显著的提速，并声称只要规划和护栏做得好，质量可以很高。
• 怀疑者则看到的是“垃圾代码”，并担心技术债激增、架构脆弱，以及未来高昂的维护成本。
• 关于安全性也存在争论：有人预测未经审查的 AI 代码会引发“灾难级”的 CVE；也有人指出人类编写的代码本来就不安全，并认为根本问题是缺乏专业标准，而不是 AI 本身。

工具、护栏与工作流

• 人们在构建护栏框架：静态分析、lint 工具、覆盖率门槛、CVE 扫描器、性能检查、可观测性仪表盘、预发/功能开关、备份，以及自动回滚。
• 有些人使用 agent“团队”：构建者、审查者、QA，以及一个更高层的“CTO”/经理 agent 负责协调任务。
• 也出现了新的工具，用于：
  • PR 摘要与分类。
  • 架构与调用图可视化。
  • 面向复杂子系统的交互式代码探索和“解释器”。
• 现在有几个人花在打字写代码上的时间更少，而把更多时间用于测试、设计审查和监控。

职业规范与职业焦虑

• 一派认为：“永远不要上线你不理解的代码”；这样做是失职，也会贬损这个职业。
• 另一派则认为，在大型系统中，你从来就不可能完全理解所有上线的代码（依赖、同事的工作），因此这只是既有实践的延伸。
• 潜藏着强烈的焦虑：担心自己变成 agent 的“肉身代理”，担心工程文化退化，以及未来 SWE 角色相对于 PM/“维护工程师”被降级。
• 也有人接受这一变化，认为拒绝使用 AI 会限制职业发展，而真正的杠杆现在在于设计、规格说明，以及围绕 agents 构建稳健流程。

抽象层级与领域差异

• 许多人把 LLM 编程类比为过去的抽象跃迁（编译器、ORM、框架），但批评者回应说，LLM 是非确定性的黑箱，不同于编译器。
• 对 AI 生成、而自己并不完全理解的代码的容忍度，强烈取决于影响范围：
  • 对 UI、内部工具、仪表盘、社交功能更宽松。
  • 对支付系统、账本、基础设施、航空/医疗类领域则严格得多。