HackerNews中文版

我正在为小型技术团队（约 3 名开发人员）在快速开发中使用大型语言模型（LLM）寻求一些建议。和大多数人一样，我们越来越依赖 LLM 来生成代码。我们在侧边栏使用 Cursor 来严格控制和维护我们应用程序的工程质量标准。然而，我们发现代码审查正日益成为开发中的一个瓶颈，拉取请求（PR）堆积如山。在过去一年里，代码生成与审查所需的时间平衡已经发生了倾斜。代码审查现在占用的时间比例更高。我们尝试过集成 CodeRabbitAI 等工具，但并未发现它们是万能的。它们对于报告基本错误和遗漏的测试用例很有用，但通常会忽略与整个应用程序上下文相关的关键问题。此外，AI 代码审查也未能实现代码审查的重要目标——与团队其他成员共享上下文、理解和所有权。我担心我们最终会面临一个令人沮丧的矛盾。我们既希望比传统代码审查（即理解）更快地生成新功能，又希望亲自理解正在生成的架构和代码。因此，我正在寻求建议。你们尝试过哪些有效的方法？在一个代码生成速度比以往任何时候都快的专业工程团队中，需要牺牲什么？

查看原文

I'm looking for some advice for small tech teams (~3 devs) developing quickly with LLMs.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.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.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.Additionally, AI code review misses the important code review goal of sharing the context and understanding and ownership with the rest of the team.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.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?

HN 提问：使用大型语言模型（LLM）后，代码审查流程会发生什么变化？