If the whole thing is really all or nothing (very rare), at least break it up into sensible commits that can be reviewed individually.
Stop sending me huge PRs; a rant
31–40 of 116 posts
Re: Stop sending me huge PRs; a rant
#32There's only one way out of this predicament. AI reviews. It's what we have to do.
Adversarial review is a thing, but it’s not the thing. Slop begets slop.
Re: Stop sending me huge PRs; a rant
#33> 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 w…
Pretty much this. In OSS, review is mostly about convincing the others that your change is good and useful enough to merge. In corporate, it's seen as a blocker to change the ticket status to done. The vibe of the latter is mostly "it's working on my computer, approve it so that we can reach the quota for the sprint".
Re: Stop sending me huge PRs; a rant
#34Earlier quoted context omitted.
It's all we got at this point. Even as SRE, I just got 2000-line Golang change to something I think should be 150. However, the boss is already bouncing around happy we are going to deliver something that's been in Jira backlog for 9 months.
Why even bother then? Just feed Jira tickets into Claude Code and have it write the code, open the PRs have Claude in a GitHub action that does a code review on PRs, a routine that resolves the reviews, rebases the code and fixes conflicts and finally another that just merges anything that’s green in CI, no outstanding review and no conflicts. Then just spin in your chair whistling all day I guess. Surely your boss w…
Pretty sure that's what a group in my company is working on now.
Except, I won't be spinning in my chair, I'll be out of a job. At least until cost skyrockets and outages get much worse.
Re: Stop sending me huge PRs; a rant
#35In 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,…
I mean, sometimes I don’t know how I want to write something until I’m finished. Huge refactors are often like this. So, just like you said, rewrite the whole thing, THEN break it apart into bite size chunks that tell the story and feed it to others with acceptable and reasonable context. It’s a skill that engineers need, and it pays dividends to all on the team, including you, when your coworkers ALSO start doing th…
And then some of the time while breaking it up you realize you should have done it another way.
Re: Stop sending me huge PRs; a rant
#36In 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,…
I've had no trouble getting small PRs. No idea if I'm doing something different than you or the things I asked for just happened to be small. Next time I get a big one I'll consider trying to ask the AI to break it up after it's finished.
Re: Stop sending me huge PRs; a rant
#37> 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 w…
I would back up. If leadership is not committed to real reviews, it’s not your job to make them happen. Don’t try to fight an impossible fight no one cares about.
Personally, I would leave. But that’s not always an option for everyone.
Re: Stop sending me huge PRs; a rant
#38while we are at it, stop filling in the PR body with a mini novella of text generated by ai. they are hard to review and are unnecessarily verbose. the description should be there to benefit the reviewer.
Re: Stop sending me huge PRs; a rant
#39In 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,…
I think LLMs are actually great at breaking up work into workstreams and tasks. The issue is that tasks do not equal good PR stacks on their own. You’ll need to use feature slices instead (like do backend part -> PR it, etc). LLMs can do that, but you need to harness them into it.
Re: Stop sending me huge PRs; a rant
#40> Small PRs were never asked for because they're easier to write, it's always been for the benefit of the reviewer I think they were asked before AI and even they were not easier to write. Its same as with commits. Usually when implementing a new feature I'm just in flow, so I don't think how to properly separate changes to different commits. I mean - not always, but usually maintaining git history in a beautiful and…
Then you may need to improve your git-fu (or $vcs-fu). I use magit, so it's always easier to select only the lines/hunks/files that is for one specific change, stage and commit that. Before magit, I use sublime merge, Intellij vcs feature, and fugitive.
My flow state is for editing files. Once that's done and I've got something that work. It's always easy to convert those into sensible commits. Do not that the logs is not the like of "write database schema * add the index page * add the details page * add the new object form". They're more like "show the list of objects * allow object creation * show the details of a specific object". Those breaks to create the commits are more natural to the general flow state.