alt Hacker NewsWe do architecture reviews now. Code reviews are going away because agents handle it.
When I ask an agent to do a code change for a PR, it’s because it’s not something I think the other engineer really should waste their time on. It’s on the same level as nitpicking what lines the braces go on before we had auto-formatters and lint checkers in CI.
Other staff engineers I rarely even see their code. I trust them to be able to review and deliver and support their own code and communicate breaking changes. Knowledge gets disseminated at weekly architecture reviews, in person.
Offshore developers under me have their code gone over with a fine-toothed comb. They don’t own the work. They don’t support it. They can’t even speak to me without using copy pasted Claude responses that are wrong half the time anyway. I have zero qualms with “going over them”.
Replies
Then does the original author own the changes you made to their PR, e2e? Do you get their signoff on them if that's the case?
> We do architecture reviews now. Code reviews are going away because agents handle it.
So you already failed the first part of doing your goddamn job as an engineer which is reviewing and owning code. Code review is a vital part of that, because code ownership is a responsibility shared by your entire team. We used to say that cowboy coders were a disaster for your team and now you're saying everyone on your team is effectively a cowboy coder.
If it turns out claude or whatever LLM you're using pulled in a bad package and now your companies data has been exfiltrated are you going to be the one willing to be fired for your blunder?
> Code reviews are going away because agents handle it.
Agents don't "handle" code review. With no human in the loop, there is no difference between "generating" code and "reviewing" code. Let's not bastardize the word "review". The code is unreviewed. Now, whether that's a dealbreaker or not for your project or company is a different question.
Personally, I've found that unreviewed LLM code unnecessarily explodes in complexity and the credit / token cost per change increases in tandem as the LLM pulls more into its context window. This is especially the case when you let it go wild on test cases. We don't have an unlimited budget for AI, maybe you do, so this is a concern for us. So we've decided to continue to review code and ask LLMs to significantly reduce the complexity of their generated code - which is a task that we're finding they are extremely bad at.
They're probably extremely bad at reducing complexity because the incentive for frontier model providers might be to train models that are capable of one-shotting flappy bird, instead of models that are capable of maintaining mature code bases that already have an implementation of the ad-hoc parsing function it just generated, as well as the newly-generated 50 test cases for it.