Clean Code作者不再审查AI生成的代码
The Author of Clean Code No Longer Reviews AI-Generated Code
Clean Code的作者Robert Martin分享了他应对AI编程的最新策略。他坦言，为了充分利用AI代理的生产力，他选择不再阅读它们生成的任何代码。取而代之的是，他构建了一套极端的约束体系，包括Unit tests、gherkin tests、QA流程、质量指标、mutation testing以及测试覆盖率等。通过让AI代码经历这一系列严苛的测试关卡，他对最终产出的代码质量拥有了极高的信心。这种从“人工审查”转向“体系约束”的转变，或许代表了资深开发者与AI协作的新范式。
我比你们年长得多，从60年代末就开始编程，我目前的策略是不阅读我的代理编写的任何代码，这才是利用它们生产力的唯一方式。
HN 评论区
51- rich_sasha
我对这篇帖子的理解略有不同。
LLM 生成的代码只要超过几页，就完全没法读。一套'LLM 写代码，人来读/检查/修正'的工作流，在我看来（IME）效率极低且令人沮丧，通常还是自己手写代码更好（YMMV）。
如果你想获得一些生产力提升，就不能依赖逐行阅读、理解并接受 LLM 生成的代码。你基本上只能全盘接受。
所以你能做的最好的事情确实是：对它进行严格限制，比如先写好接口，然后让 LLM 写测试，再让它写代码。
我不是说我喜欢这种做法，但我同意手动验证 LLM 代码确实非常令人沮丧且效率低下。
- jvanderbot
《Clean Code》的作者（靠咨询如何编写软件为生）在一条引人注目的推文中转向了 AI，大谈如何搭建自动化软件开发流程，时机恰好能让他靠咨询如何搭建自动化软件开发流程继续谋生。
- daaaaaaan
就是那个觉得 optionals 太复杂的人？https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath...
- andai
我一直在发这条，但它总是很应景。我让一个 agent 实现了一个功能，结果完全搞反了。它写了一大堆测试来证明实现的正确性。所有测试都通过了。
真正让我觉得有趣的是，形式化验证在那里也帮不上忙——它只会写出一个关于这个反向功能正确性的数学证明。
- rpunkfu
讽刺的是，根据我大量看到 AI 写代码的经验，它可能完美地遵循了他那种啰嗦的 Clean Code 风格。