Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I wonder how codebases for important products (not demos or short-living ones) end up without anyone reviewing the code. Some claim engineers should become more of "architects" and "designers", but not coders/reviewers anymore. Wish to hear people's stories, if much documentation and reviewing from the high-level only is enough to keep the project from becoming a failureby sagabai
- If someone’s best practice,optimization or security check is that important, automate it. Automation is more scalable and consistent . It would make more sense to me to build purpose built agents to look for any patterns that matter. Yes, humans are needed to sanity check and design the agents and rules. Combine that with a well designed build and test harness , human code review seems to me to be obsolete.by stikit
- It depends. Since I started coding with AI, I rarely review the code for my personal projects — I only run the code-review skill on critical features. But for internal company projects, we still run a strict code review tool, SonarQube, at build/release time to check code quality and security.by ylynbuilds
- No code review here. I tried to make it a regular part of my work flow but, it didn't last. That being said, I'm a retired developer and everything I build are personal projects so the stakes are lower than for working developers. I retired just a year or two before AI coding agents came into existence so I never experienced using these tools in an actual workplace setting. Working must have a whole different vibe these days
- Generally, I'll review any code I generate with AI myself before publishing it. I often find it interesting to try and extend these projects myself without the help of AI in general, and the results Claude spits out are usually unoptimal, so it only makes sense to me.by CM30
- Same as most others here, I think it depends so much on your use case.
The speed you're as able to move at with no to lightweight manual code reviews is just so much higher, but there are cases where broken code could mess up critical prod systems so I don't see how you'd get rid of human code reviews there just yet.
For personal usage I've found quick DeepSeek flash reviews a massive boon to finding obvious bugs though.
by byra - Before coding agents, people generated code that was reviewable. Now, people generate entire features or 5K+ lines of changes in a single PR, fully introducing new functionality. We can’t defend ourselves against this and make production slow. But the only way forward is to start relying more on AI-based reviews.
Here’s the interesting part: each PR gets reviewed by more than 3 people, each from their own perspective. Based on the questions and the affected paths, the reviewer directs the agent to focus on different points. Someone who is already familiar with the codebase can also guide the agent in the right direction.
Recently, we also started automating UI reviews. The agent runs all the services, verifies the feature through the UI, takes screenshots, and uploads them directly to the GitHub PR. We call this UI Review. + Test coverage also improtant.
by shanforge - >>> each PR gets reviewed by more than 3 people
How does this work exactly -this is your current workflow? Which tools are you using . I assume you mean your human reviewers are using ai tools interactively and deciding which fixes the tools propose will be implemented ?
by stikit - Personal/side-business: Almost fully automated PR review flow. Local agents review before PR, Github Actions runs Codex/Claude to review the PR, if everything passes (Unit, e2e, lint, etc) then I merge. I'll review critical code paths if they are touched but that's not too often.
Day Job: Similar but more human-in-the-loop and we are still feeling out "what needs human review" and "agent review is good enough".
LLM reviews have shown me/us that they will catch more things (legit things and silly things, to be fair) than human reviewers. Human reviewers are very bad at seeing what's _not_ there. Yes, humans will catch some things that the LLM won't but it's normally only on very custom things we've done that the LLM isn't "trained" on. [0]
I think that as time goes on code reviews will be almost fully automated and humans will focus more on the plans before building, overviews of what was built, and other spec/diagram-type "artifacts" than looking at the actual code.
[0] For my side projects and even a little for work I've been trending in the "do it the way the LLM wants" not "force it into the shape you thought of" because it's easier for the LLM to write/maintain/"understand". Similar to how I don't tell an LLM "put a red button on the page here that does X", I give it the problem I'm trying to solve so that I don't "bias" it to the way I first thought of. I may force it to do it "my way" in the end but I find I get exposed to new ideas or new/different ways to solve my problem when I don't "lead the witness".
by joshstrange - I don’t think so, even I review my code using ai(Claude or codex). A human can review a code if it is minimum of 200 lines or maximum 1000 lines of code, I think. Bet it is so time consuming. I prefer using Claude for this.by codst
- My team still reviews one another's code, but for my personal projects it's Claude writing and Claude reviewing.by jsturgill
- Both. AI code review is built-in, but there's always a second human in the loop.
I'm concerned that there are people pushing on the code generation front, the code reviewing front, and the laziness front. Eventually they're going to all meet in the middle, and there will be a significant number of engineers who are using AI to write and review the code, rubber stamp it, and push it into prod, with disasterous results.
by shaftway - I like having different models review each other—for instance, having Claude write code for Codex to review, or having Codex write it and Claude review it.by dawn3727
- I personally review most of the code written by my team without using an LLM.
Just today I reviewed a patch made by a teammate using Claude for a not very significant bug, where in addition to fixing it (in a very roundabout way), it introduced 2 new very subtle bugs, and refactored a large portion of another function that was unrelated to the code, and made several observations and comments which were subtly wrong and out of touch with the rest of the code.
I ended up rejecting the PR and writing my own very small local patch for the bug.
Other people in the team use Claude to help them review my own PRs, and it sometimes finds minor issues, although there was only a single time it found a major issue.
My own use of LLMs is mostly to develop large features, which I then thoroughly review myself.
by olvy0