Stop Sending Me Huge PRs: A Rant
Stop sending me huge PRs; a rant
A developer vents about the growing trend of AI-generated pull requests that span thousands of lines, arguing that small PRs are essential for reviewability and maintainability. The author dismisses the excuse that large changes are necessary, emphasizes the importance of clear naming over excessive comments, and challenges the idea of using AI to review AI-generated code. The post ends with a playful accusation that giant PRs might be a tactic to get approvals through reviewer fatigue.
I'm tired boss. I'm tired of reviewing one, two, three _thousand_ line PRs because some agent was able to "one shot the whole issue."
- danpalmer
In my experience the models perform substantially worse if asked to create small PRs or commits. They lack the ability to sequence work and understand dependencies efficiently enough to manage it – it's not that they can't do small PRs, it's that doing them takes vastly more resources which then hits context limits etc. And if you want to then go back and edit a stack of commits or PRs, rebasing work into the middle, that's even more. I don't think any of this scales linearly in the amount of code or number of commits.
This is all in addition to the fact that the models are generally poor at storytelling, because that requires a theory of mind of the person you're communicating with. Authoring for review is storytelling, it's making changes in such a way as to build confidence in the reviewer. I believe current LLMs are still years away from this.
In my opinion, if you can't do these things, you're just cosplaying software engineering. Vibe coding has its uses, as does LLM programming, I do a lot of this! But we're kidding ourselves and dropping our standards dangerously low if we think that this is software engineering.
- gensym
> why did you put it up for a human review at all then?
This seems to be the crux of the issue.
I'm guessing the most of the time, the answer is "because that's a mandatory gate to getting these changes into production". If the PR author doesn't see the value in review, it's going to be hard to convince them to write reviewable PRs.
If they're actually looking for human feedback, telling them how to submit PRs in a way that's amenable to human feedback is going to be a lot more successful.
- sackfield
It is reasonable to break PRs up into smaller chunks, but there is a limit. There are frequently reviewers who get very zealous about this and insist on breaking things up beyond what is reasonable, for example if breaking it up would destroy the intent, or if the "thousand line" PR just contains lots of tests (AI's love to write tests, and I love that they do that). Some tasks are just long, and its important to contextualise this when reviewing.
In the end though, these reviewers will die off like the dinosaurs. The article actually states that they find the idea of reviewing a large PR with AI bad because "it wastes your tokens reviewing a reingesting code that was already made by an AI". This doesn't make a whole lot of sense, AI will frequently reingest AI generated content, evals are a great example of this.
Just after this the article touches on the real issue at play: "okay, great, why did you put it up for a human review at all then?". Indeed, this is a good question to ask, why do we put it up for human review? I would wager that they don't actually want human feedback, a human has placed themselves as a gatekeeper and thus must be placated, and probably chooses the most inefficient way to keep that gate slowing everyone down who has kept up with the technology of our times.
- bawolff
>I'm tired boss. I'm tired of reviewing one, two, three thousand line PRs because some agent was able to "one shot the whole issue." Small PRs were never asked for because they're easier to write, it's always been for the benefit of the reviewer.
100%
but also "no" is a two letter word and one of the most important and hardest parts of being a maintainer.
- ulrikrasmussen
If you generate PRs too big to review for others, then they are too big to review for yourself. This means you are delegating the task of understanding the code to an LLM, and the end result is inevitably that noone in the organization understands the code better than someone who just walked in the door. They can write the next LLM prompt just as well as you because they know as little about the system as you.
In that situation I ask you: what is your moat as a software company? Why would your customers keep paying you when companies like Anthropic can just do your-software-company-as-a-service and cut out the middle man and six figure salaries?
- usewik
> If your variable is not named well and you need a comment, name your variable better.
100% agree. While you are at it, consider naming and writing your functions in such a way that doesn't require a wall of comments. Clean Code uncle Bob style.
- ventana
Just an idea which I haven't personally tried: AI agents understand technical limitations, such as CI failures. Maybe make a CI job which checks that a PR has a reasonable size, and auto-reject with a polite message if it's not? Something like, "This PR size exceeds the limit of N lines that we accept for review; if you implement a big feature please consider splitting it in several smaller PRs." There are chances that it won't help, but it might!
- albatross79
The whole point of using AI is to generate more code more quickly. If you cant keep up, then step out of the way. Some people think being a reviewer is a privileged position. Well now you've got your work cut out for you.
Ultimately the solution will be to get rid of reviews and reviewers, and put the responsibility for the code on the "author" (prompter). If you're using AI to generate code you're already mostly just a reviewer, putting more reviewers on the same code just slows everything down. What's needed is more accountability.