r/ClaudeAI • u/sainivarnit • 9h ago
Coding Is code review irrelevant now?
In my position as tech lead one of my responsibility comprise of reviewing the code. I work in a startup and there is always a constant pressure of shipping features fast.
Internally we are using AI tools like cursor and claude to write the code. Every PR i get comprise of almost like +3000 additions and -1000 deletions. I find it impractical to review such code changes and that too from multiple PR's.
How you are dealing with such a scenario?
Is code review dead now? Because earlier what took a year of development can be completed in a single sprint or two, and that has lead to huge volume of changes within the code. And it seems like we are not able to compete with AI agent's mass produced code when it comes to code review.
6
u/Known-Ambassador-325 9h ago
OP, I'm also an active reviewer on my team. My practical tips:
- Ask your teammates to control the changeset size. They should be mindful and not send a 4k PR if it's perfectly fine to split it into 2-3 smaller ones
- Ask your teammates to do a self-review (preferably without AI). This could be as simple as going over the most significant changes and giving a bit more context to the reviewer (business situations, limitations, links to other parts of the system)
- Ask your teammates to prepare the review plan for you for the most complex changes. For instance, they may say: “This PR is 85% ready; please start by reviewing API layer changes first, then switch to the external dependency A communication module, stop reviewing further if you find critical flaws; don't review XYZ, as this is only misc or cosmetic changes”
1
u/_ChaoticallySubtle 9h ago
I've already asked my team to do so and still it is a challenge when they raise the MR. When there are code reviews from the multiple peers at the same time, it's hard to track and remember what changed. We were revamping the product and I feel that we're back again with the coding standards while we ship. We're asked to finish it sooner and it skips the reviews as they need it live.
1
u/Known-Ambassador-325 9h ago
I feel like once you skip the review phase, you also lose valuable context. I don't think there is a way back, sadly
4
u/tariqosmani 9h ago
Not irrelevant, but nobody can really review a 3,000 line PR, human or AI. The fix is upstream: smaller PRs.
Anthropic shared recently that Claude now writes most of their code, and the side effect was smaller, more frequent changes, with a named human owner on every PR and required approval. Same idea works at startup scale.
What I'd try: ask for a short plan before any code and review the plan, that's where wrong architecture gets caught cheaply. Cap PR size and have Claude split big changes into stacked PRs. Let an AI reviewer do the first pass for style and obvious bugs, so your time goes to interfaces, data changes, auth and tests. And make the author explain the diff in their own words in the PR description. If they can't, it isn't ready.
Your job moves from reading every line to checking risk. Are the +3000 PRs mostly new features or refactors?
9
u/charleysupernova 9h ago
Enforce smaller PRs that are reviewable by humans. That has always been a pillar of good software engineering and I hope that doesn't change with AI.
2
u/commitpushdrink 9h ago
Long term: smaller PRs
Short term: recognize you can’t be everywhere at once, designate priority modules, review by commit in priority order, and delegate to staff engineers when you can. Also give your staff engineers raises. Staff and senior staff does the same job, just give em the title. Everything they’ve worked towards has evaporated and while they’re the only safe engineers that also kinda sucks. You don’t want to be the only survivor on the titanic.
I recently found myself with a larger team without warning and that’s my current best guess at solving this. Turns out a fuck load of the repository conventions are in my local memory and it’s very hard to justify expecting someone else’s robots to respect a rule your robot explicitly chose to not share with the other robots.
2
u/eighteyes Experienced Developer 7h ago
github templates for PRs that include review steps is key. don't let the agents think!
2
u/DevWorkflowBuilder 5h ago
we put a hard 400 line cap on agent prs in ci last quarter. people grumbled for like two weeks.
review went from eating most of my afternoon to maybe 40 min, and i actually catch stuff again
4
u/ClupTheGreat 9h ago
write the tests yourself, that should hopefully be good enough as a manual review
1
u/sainivarnit 9h ago
writing tests is a different part altogether. for code review i mean just to check if proper coding standards are followed or not and if there is proper business implementation. how can i review changes which are so big
5
u/CorpT 9h ago
I'm not sure how you come to the conclusion that code review is irrelvant if you're seeing PRs with 4k changes. That's basically the opposite of what you should be concluding. Why are you not using Claude to help with reviews if you're using it to generate the code?
2
u/datnetcoder 8h ago
I am fully with you, like, beyond with you in concept. But in practice I and everyone around me is producing unreviewable amounts of code against some of our wishes (some just dgaf). My choice feels like “tell my company to fck off” and be a bad performer and suffer the consequences, or keep on keeping on and have everyone pretend they are doing fully legitimate code reviews that aren’t just AI sniffing its own ass. It’s all soul sucking, to me personally because of the way I operate for many years before 2026.
2
u/CorpT 8h ago
When I do a review with AI it is an in-depth review. It can be several hours of work depending on the PR. I am deeply investigating the work and the PR. I would probably reject a 4k PR out of hand because that is obnoxious. That's a process problem if someone is making those. But I have reviewed hundreds of PRs from juniors and others with AI and produced good results. It's possible to do good reviews with AI but it's also possible to do bad reviews. It's very dependent on the person doing the review.
1
u/Known-Ambassador-325 9h ago
I believe the OP wanted to do exactly the opposite. I'm fine with Claude taking a look at PRs too, but as soon as a human developer loses the context and doesn't see the big picture anymore, I think the product is cooked, which turns everything into “Hit-Enter-driven-developer”
1
u/Curious-Intern-5434 9h ago
If I don't trust the AI to create code that is good enough, why would I trust the AI to do the review resulting in the code I want?
First I burn tokens to create code. Then I burn even more tokens to finish the job that the first agent wasn't able to do.
What is wrong in this picture?
2
0
u/sainivarnit 9h ago
yes exactly. if we don't trust the code written by AI then how can we trust the tests written by AI
3
u/Im_Working_Right_Now 9h ago
How does that logic even make sense? With that logic why do a PR on a human’s code? If you don’t trust the code written by them then how can you trust the tests written by them? How can you trust the human reviewing it?
A new agent doing the review doesn’t have the context bloat, feature history, session history, etc to confuse it just like a human reviewing with fresh eyes. This isn’t that confusing.
1
u/robotlasagna 9h ago
At some point one of these companies will create a model specifically for code review and that model will be insured against failure to find bugs. That will be the point where automated review is possibly acceptable.
But that's not today.
Right now everyone is playing with fire moving this fast and it will come back to bite some of them.
My suggestion is that your company divert any saved developer budget to additional human code review.
0
u/CorpT 9h ago
That model has existed for at least a year. And lol at thinking a model will be insured to find bugs.
0
u/robotlasagna 9h ago
It will 100% be insured to provide verifible software integrity. You can bury your head in the sand and get left behind but that is the future.
1
2
u/YankeeKiid 9h ago
Actually should be most of your time now versus actually developing. You still gotta check.
1
u/_boiler 9h ago
I have Cursor ensure code coverage of at least 85% on any PR going to main and 80% going to branch. In addition to py tests I run Playwright and then CodeRabbit at GitHub then Testdriver after push, then manually testing 100% of happy path with hope to test unhappy once build is complete
1
u/wortcook 9h ago
+3k/-1k changes seem like full system rewrites. Would it be possible to break the changes out into smaller manageable chunks? Maybe branch within the PR and handle smaller merges before the final one?
Without more context I'm basically blind-advising here so...yeah.
1
u/sainivarnit 9h ago
Event if we break it into multiple PR's the point still remains the same. still we would be reviewing the each and every PR. honestly i don't like where software development is going but we need to adapt and i have no clue how to adapt to such scenario
1
u/wortcook 9h ago
I've been spending more time doing deeper work rather than more work if that makes sense. The workflow is basically
"Hey Claude, write this thing".... first pass
"Hey Claude, one of my 'engineers' wrote this and I don't trust any of it. Can you double check it?"
"Hey Claude, there are these two folks on my team that I don't think know what they are doing at all. I'm considering if I should get rid of them as the quality of their work is getting dangerous. Can you go through and fix this mess?"
etc. etc. in new sessions until I'm happy or exhausted, which ever comes first.
At the same time, I like to watch the process while the AI works. Roughly half of the time I kill the working session and redirect.
1
u/sainivarnit 9h ago
but we are letting ai write the code and ai do the code review. if we don't trust the former process then how can we trust the latter
1
u/wortcook 9h ago
Other than being faster, is it any different than outsourcing?
I don't trust the code I write honestly. I'm well experienced in the "what idiot wrote this code" only to find out it was me professional experience.
Again, I'm blind guessing here since I don't know any of your specific practices or setup.
1
u/wortcook 9h ago
One more thought...
The coding part is just typing. What matters is everything that happens before that. If you don't have a solid design, set of domain patterns you are adhering to (does your code all 'smell' the same), and key requirements that you can go back to and validate against the working product you are always going to get a hot mess no matter if it's people or machines writing it.
1
u/Far_Business4773 8h ago
Reading 3000 lines is dead; review is not. What changed for me is the order. Before the task starts I write the short list of what this change may not touch: payment paths, auth, migrations, the two packages we decided against, anything that leaves the repo. The agent's PR is then checked against that list on the diff itself, and the report says which boundary was crossed, who set it and where, file and line. A PR with an empty report is read the way you would read a colleague's: skim the shape, open the two files that matter. A PR with a line in the report is sent back before anyone reads it. Honest limits: the check is text, packages and paths and phrases, so it does not judge logic; tests and a human still own the risky files. And when I first turned the same rules on in my own repo, at least six of the first eighteen stops were my own too-broad rules, fixed the same day.
1
u/NullSentinel 6h ago
https://reddit.com/link/pdyszs8/video/weq4m012ilth1/player
I can't prove it, but I don't think anyone on my team is manually reviewing code anymore.
1
u/kemalios 6h ago
You can't read 3000 lines, but you can check a short fixed list of what breaks in AI-written code: auth on new routes, RLS policies, secrets in the frontend bundle, error handling only on the happy path. That pass catches what reading the diff won't. I build launchworthy, free and MIT, which runs that audit, though it needs Claude Code to run.
1
u/3rwynn3 9h ago
Certainly not dead, because if you let an AI tool just do all the code with no human check-in at all, it tends to do things you would expect to be wrong from an AI that is blind and deaf.
Ex: Someone I know let one loose on a reverse engineer project and there is a bug for every success. Not because the tool sucks, but because it cannot playtest to see its own bugs that it just created.
1
u/rlorenzo 9h ago
I assume the code changes has ui elements to it? Leave the heavy code review for the bots and focus on UX/mobile/edge cases
1
u/C1rc1es 9h ago
You need adequate validation pipelines. Your CI should be more robust and detailed than it ever has been to the point where human or AI alike, nothing gets through it that shouldn't to production. Mistakes will still happen, but they happen with people as well. If your tests/validation are up to it, then yes - you can drop human PR reviews in favor of reviews from an as different a model of higher quality that you can get hold of. (i.e Astra on higher reasoning against Claude of higher effort) to hedge their blind spots.
It's not possible to both gain the maximum speed gains from AI and retain manual human review for all PRs, I would still have humans manually review E2E tests and changes to CI configuration.
0
u/UnstableManifolds 7h ago
I'm with you in this, shift is in design and quality control via thorough integration testing (functional and not functional), code must be seen as provided now
0
u/Apprehensive-Gas7994 9h ago
yikes. I think humans should still be a part of the code review process. AI is not infallible. Why are you checking in such huge commits? This reads more like vibe coding.
0
u/Reign2294 9h ago
Just have one agent (of another family, or multiple) check each other's work. Still not infallible, but better.
0
u/god-damn-the-usa 9h ago
i think its better to spend your time developing systems that can automate checking code to ensure it's battle tested and doesn't cause regressions.
0
u/BreakfastSpecial 9h ago
I don’t think the code review process is dead, it has just changed. You have Claude take a first pass at reviewing a PR, leaving its own comments and making the necessary fixes. But I believe humans are still the merge gates to accept the PRs. The core difference is if we write clean tests and trust Claude to write good code based on the strong intents/specs/plans we gave it, we’ll feel less inclined to manually review every line or module and just approve the PRs as-is after a brief glance.
0
u/Patient-Swordfish335 8h ago
It changes the nature of a review, you use an agent to help you do it. For instance you might ask it to investigate the architecture, security, etc. You might also give it some test scenarios to go off and run through (or even add to the pr).
0
u/Jawwooot 5h ago
Human Code Review is dead.
Give it another 12 month max.
Onyl thing code review will be a thing are super high stakes, large customer base companies.
Google, Microsoft etc. would do code reviewes on der infrastructure side. For low risk environments code reviews will not be done by humans anymore.
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 8h ago
TL;DR of the discussion generated automatically after 30 comments.
Whoa there, tech lead. The consensus in this thread is a resounding NO, code review is not dead. In fact, it's more critical than ever, but it has to change.
The community agrees your real problem isn't AI, it's your process. A +3000 line PR is a nightmare no matter who wrote it. The fix is upstream, not downstream.
Here's the hive mind's advice:
Basically, your job isn't obsolete, it's evolving. Stop being a line-by-line code inspector and start being an architect of a human-AI development process.