Codex 联合创建者 Tibo Sottiaux 在 The Pragmatic Engineer 的访谈中，提出了一个值得思考的观点：Code Review 同时承担着检查正确性、交换知识和对齐意图的职责。AI 正在改变这些职责的分工。

据他介绍，OpenAI 已将 AI 安全检查纳入 PR 流程，发现安全问题时会阻止合并。模型还能沿着依赖关系深入检查，发现文档描述与实际实现之间的差异——这些问题往往需要人工花很长时间才能定位。

他认为，正确性和安全检查会越来越多地被自动化。而团队仍然需要认真讨论：

• 我们究竟想解决什么问题？
• 这个改动是否值得做？
• 系统应该保证什么，又接受哪些取舍？

这些讨论，最好在写代码之前发生。

过去，PR 经常成为需求和设计讨论的最后一道关口：代码已经写完，大家才开始追问目标是否合理。AI 加快实现速度后，如果团队仍然等到 Review 才对齐意图，返工也可能随之加速。

这给工程团队一个很具体的启发：在加强自动审查的同时，把需求、接口契约和验收标准讨论得更清楚、更早。

代码审查的演进，也需要协作方式一起改变。

#CodeReview #SoftwareEngineering #AI #EngineeringLeadership

来源：The Pragmatic Engineer｜Building Codex with Tibo Sottiaux

这个例子提醒我，生成代码只是交付过程中的一个环节。

自己逐步实现功能时，也在建立对需求、数据流和边界的理解。接收 AI 生成的结果后，这些理解可能需要重新补上。

比如，一个导出功能很快就写好了，但数据范围是否正确、失败时如何处理、是否符合现有接口约定，仍需要有人判断和验证。

再加上不断回答问题、查看进度、在多个 Agent 之间切换，节省下来的实现时间，可能变成了更密集的审查和决策。

团队也会遇到同样的问题：如果待审改动增加的速度持续超过审查完成的速度，积压就会越来越多。

所以，我更关心的是：从提出需求到完成交付，团队总共投入了多少实现、理解、审查和返工的时间。

几个调整值得尝试：

• 让每份改动有明确的目的和验证方式，减少一次接收大量陌生代码的负担。
• 提前约定常规事项的处理方式，把人的注意力留给重要取舍，减少反复确认。
• 按团队的审查能力控制并行任务，给已有工作留出完成的空间。

对于熟悉的小改动，直接动手写也可以是高效选择。AI 参与到什么程度，可以随任务调整。

在你的团队里，哪些调整让 AI 编程更省力？

讨论来源：Syntax #1039，26:19 起 https://syntax.fm/1039

#AICoding #SoftwareEngineering #DeveloperExperience