Ask HN: How are you doing code reviews in the era of GenAI? | Hacker News Reader

Ask HN: How are you doing code reviews in the era of GenAI?

I'm a more senior member on my team, and like many software engineering companies, we're using various GenAI technologies like LLMs and agentic AI to help with coding tasks.

The good news is, it does increase the output of less-experienced developers. The bad news is, it also increases the output of less-experienced developers.

We use a fairly standard code review process: make a PR, have it pass CI/CD tests, have other developers review, and merge into main if approved. The problem is that we are getting a larger volume of PRs to review and it's beginning to cut into the productivity of more senior members of the team.

How do you handle this increase in PR review activity?

View on HN

I'd question your definition of productivity. If reviewing PRs is part of your job, and you are doing it, but some measurement of your productivity is down, then your measurements are wrong, not the code reviews.

I've seen teams try too hard to keep the seniors "productive", and they just end up with the juniors/mids bottlenecked because their code never gets reviewed. So if you measure productivity by overall flow of code through your process (think Kanban, not Scrum), you'll be able to resolve this conundrum.

I guess the problem I see with that is that the bigger "lifts" that we count on to carry out business strategy are typically carried out by the senior engineers, and reviewing PRs, while technically productive, delays those bigger lifts.

Why wouldn't the senior break off smaller tasks within the "lift" and delegate those parts to juniors? Then reviewing those PRs is a productive part of the lift. Or, if you really cannot break down a task into smaller parts, have one senior take over more PR work while another does the lift.

Right now we're doing a lot of architectural stuff in the big lifts surrounding design patterns and stuff that perhaps junior devs might not understand as well.

We're doing more of the latter suggestion, though that is coming with more "reviewer's burnout". We are trying to deal with it through smaller PRs, but then of course, you fall back to the problem of having more of them.

Gather all my acquired tribal knowledge and put it into a code reviewer [1]

This way you're not asking juniors to fix every little thing and they can learn from standards that already exist.

[1] https://wispbit.com

Reply on news.ycombinator.com