AI没有制造这些问题，它只是不再绕过它们
作者通过亲身经验指出，AI暴露了软件开发中长期存在的系统性问题，如缺乏文档、测试不完善、隐性知识依赖等。AI像混沌工程一样测试系统的韧性，迫使团队修复这些漏洞。文章强调，为AI设置的护栏本应是工程实践的一部分，并提出了80/20准则：80%确定性的代码加上20%AI灵活性。
文章情报
要点
- AI揭示了开发流程中长期被忽略的缺陷，如陈旧文档和隐性知识。
- AI是高效的混沌工程工具，能发现系统脆弱点。
- 工具需要适配AI，如输出结构化JSON而非纯文本。
- 80%确定性代码与20%AI结合的架构更稳健。
为什么重要
这条新闻值得关注，因为AI揭示了开发流程中长期被忽略的缺陷，如陈旧文档和隐性知识。
技术影响
可能影响模型选型、推理成本、产品能力和评测基准。
作者在过去几年中大量使用AI进行工作，并观察到一个有趣的现象：所有为了保持AI在正轨、提高效率、减少风险而设置的护栏，其实都是我们本应一直做到的事情。测试、文档、明确的所有权、更新的文档、确定性验证——这些都不是新东西，也不具争议性，但一旦让AI掌握主动权，就会发现这些方面缺失了多少。
AI特别擅长找到最短路径来实现目标，常常穿过花坛和蔬菜地。对人类来说显而易见的东西，对AI来说并非如此。随着开发者经验的增长，许多问题变成了背景噪音，我们下意识地绕开它们。例如，一个3-5年前的回调钩子，用于验证子模型的排序，如果一次更新超过30条记录就会变慢。它从未被记录，没有注释，没有linter会捕捉到，甚至不知道是谁写的。这种情况在人类团队中可以通过经验避免，但AI没有这种记忆，它会直接撞上去，导致死锁，凌晨3点被叫醒。
如果这是人类造成的，我们不会责怪他们，而是会问系统为何失败。同样，AI会犯错误，我们需要建立护栏使其可识别和可恢复。AI作为混沌工程，类似于Netflix的Chaos Monkey，随机破坏服务器，测试系统的自愈能力。AI是最好的混沌工程师，它发现你从未考虑过的缺口和漏洞。
我们的工具并非为AI设计。例如RSpec，AI运行测试套件，获取失败信息，然后需要多次尝试才能得到正确输出。它需要结构化输出，如JSON格式的失败列表，以便一次性诊断问题。同样，Rubocop、Minitest等工具都输出人类可读文本，不适合AI解析。作者开始要求所有AI工具输出JSON，并重新解析，禁止直接运行原始命令，这大大提高了效率。
在开发工具时，作者采用80/20准则：80%的确定性代码（类型检查、lint、测试、特性标志、阶段性推出），20%的AI胶水用于灵活性和判断（摘要、路由、分类）。当人们试图100%依赖AI而没有确定性基础时，就会发生灾难性故障，如数据泄露、令牌提交、银行账户清空。
AI迫使团队修复长期存在的系统性问题：文档因AI需要而编写，测试变得有意义，所有权明确化。每个为AI修复的缺口，也可能让人类掉入其中——新毕业生、转岗的高级工程师、赶进度的合同工。这些问题一直存在，AI只是让它们无法忽视。作者提到Square的做法：让新团队成员建立产品并记录所有令人困惑的地方（称为“WTF文档”），结果发现了许多未知的缺口。AI就像是集体版的WTF文档，迫使我们以前所未有的速度规模面对系统缺陷。
文章最后强调，正如团队将失败视为系统性问题而非个人问题时会蓬勃发展，AI系统也是如此。问“我们的系统缺失了什么导致了这个错误？”而不是“AI不好，我们不该用它”，将获得更好的结果。并非每个问题都有完美答案，但诚实审视系统的实践就是好的工程，这不会因AI而改变。AI只是让长期存在的需求变得不可忽视。