问HN：在使用大型语言模型（LLMs）时，代码审查过程会发生什么变化？
我正在寻找一些建议，针对小型技术团队（约3名开发人员）快速开发大型语言模型（LLMs）相关的项目。
和大多数人一样，我们越来越依赖LLMs来生成代码。我们在侧边栏使用Cursor，以保持对应用程序的严格控制和工程质量标准。
然而，我们发现代码审查在开发中成为了一个更紧迫的瓶颈，拉取请求（PR）迅速堆积。生成代码与审查代码所需的时间平衡在过去一年中发生了变化。现在，代码审查所花费的时间相对增加了。
我们尝试过整合像CodeRabbitAI这样的工具，但并没有发现它是解决问题的灵丹妙药。它在报告基本错误和缺失的测试用例方面有用，但通常会忽略在更广泛应用背景下的重要问题。
此外，AI代码审查还错过了代码审查的一个重要目标，即与团队其他成员分享上下文、理解和责任感。
我担心我们最终面临一个严峻的矛盾。我们希望能够比传统的代码审查（即理解）更快地生成新功能，同时仍然希望能够亲自理解所生成的架构和代码。
因此，我在寻找建议。你们尝试过什么有效的方法？在一个比以往任何时候都要更快生成代码的专业工程团队中，需要牺牲什么？
查看原文
I'm looking for some advice for small tech teams (~3 devs) developing quickly with LLMs.<p>As most people are, we are leaning more and more on LLMs to generate code. We use Cursor in the side-panel to maintain strict control and engineering quality standards of our application.<p>However, we are finding more and more that the code review is a tighter bottleneck in development, with PRs stacking up quickly. The balance of how long it takes to generate vs review code has skewed in the last year. Code review now takes proportionally more time.<p>We have tried integrating tools like CodeRabbitAI, but have not found it to be a silver bullet. It is useful for reporting basic bugs and missing test cases, but usually misses critical issues in the context of the wider application.<p>Additionally, AI code review misses the important code review goal of sharing the context and understanding and ownership with the rest of the team.<p>I'm concerned that we're ultimately looking at a bleak contradiction. We want both to generate new features quicker than can be traditionally code reviewed (i.e. - understood), and still want to personally understand the architecture and code that is being generated.<p>And so I'm looking for advice. What have you tried and found to be effective? What needs to be sacrificed in a professional engineering team generating code faster than ever before?