Ask HN: What happens to code review process when using LLMs?

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?

1 points | by ethanr2000 2 hours ago

1 comments

  • 404softwarelabs 1 hour ago
    Well, not sure why you need 3 developers, unless you can split work on really independent parts.

    My pipeline: - beads for task tracking. - one Claude Code session that runs few development lanes. Each lane is dynamic workflow that - takes a ready task - runs a designer agent if there are ui changes - runs implementation agent (on a git worktree) - runs review agent - loop to implementation once if it rejected - if approved creates a PR - when CI checks are green (tests, vulnurability audits etc) marks as lane-verified) - task can be marked as needed my attention (when it needs some decision, or manual configuration/action) - same session runs a lander, which - take lane-verified task - rebases on master - ensures master is green - merge - deploy - hand tasks back to pipeline if conflict resolution is complex or CI is red after rebase. - I don't look at the code - I don't verify individual tasks

    - in the other session I review what needs my attention - that's actual bottleneck, sometimes questions are very stupid and can be saved by LLM directly. - I have dedicated sessions for planning/researching big feature/epics. - I review periodically how product is working, and submit bugs via my own tool (https://session-replay.com)

    This delivers 50-100 PRs a day (depending on my ability to resolve questions) with a quite decent quality. Apart of my attention, CI is other bottleneck (had to install a dedicated server for CI).

    Feel free to ask if you have questions.

    • ethanr2000 44 minutes ago
      Serious questions: - roughly how much are you spending on tokens to achieve all this? - what's the longevity of the application/s you're developing? (i.e. are you maintaining the same codebase for 1 year+, or shipping one-off small applications frequently?)

      My main concern with leaning in this hard is the long-term impact to complexity and maintainability, which coding agents have been shown to struggle with moreso than solving the problem now.

    • 404softwarelabs 1 hour ago
      Ah, one thing I missed: I started with a good boilerplate (happens also to be mine), so most architectural questions are already solved.