问HN：你们如何审查生成式人工智能创建的代码？
我在几条评论中提到过这个问题，但想要展开一个更大的讨论。
有些观点认为，使用大型语言模型（LLMs）来编写代码只是我们作为工程师所使用的一种新的高级语言。然而，这在代码审查时会导致一种脱节，因为被审查的代码是生成该代码过程的产物。如果我们现在通过自然语言（提示、规划、编写，作为新的“编程语言”）来表达自己，但只将生成的产物（实际代码）提交审查，那么我们如何才能全面审查它呢？
我最近感到有些困惑，似乎缺少了关于如何产生这些变化的上下文，包括计划、提示等，以理解工程师是如何得出这个具体代码变更的。他们是一次性完成的，还是花了几个小时进行提示、迭代等？或者是介于两者之间的情况？
PR中的总结通常说明了变化是什么，但并不包含完整的对话或我们是如何得出这个具体变化的（权衡、替代方案等）。
在你们的组织中，如何进行PR审查？你们是否制定了任何规则、自动化流程等？
查看原文
I've posed this in a couple comments, but want to get a bigger thread going.<p>There are some opinions that using LLMs to write code is just a new high level language we are dealing in as engineers. However, this leads to a disconnect come code-review time, in that the reviewed code is an artifact of the process that created it. If we are now expressing ourselves via natural language, (prompting, planning, writing, as the new "programming language"), but only putting the generated artifact (the actual code) up for review, how do we review it completely?<p>I struggle with what feels like a missing piece these days of lacking the context around how the change was produced, the plans, the prompting, to understand how an engineer came to this specific code change as a result. Did they one-shot this? did they still spend hours prompting/iterating/etc.? something in-between?<p>The summary in the PR often says what the change is, but doesn't contain the full dialog or how we arrived at this specific change (tradeoffs, alternatives, etc.)<p>How do you review PRs in your organization given this? Any rules/automation/etc. you institute?