The discipline of splitting them up helps in almost every dimension.
To add to my openspec shilling above, I've been known to "fix" large PRs by reverse engineering specs from them and building each spec out in a separate PR.
Last week me and a coworker turned a 15k line PR into 10 x 1.5k line ones that went in smoothly.
For a rewrite, I guess sometimes it's better to have a spec then write to that, and PRs might be larger.
That was a comment written in a particular context, where the original commenter was concerned with large PRs.
>> how can we review gigantic PR generated by AI.
It was not a comment written in a vacuum saying that all PRs should be small (or not large, whatever that means). Though grey-area does provide some reasonable commentary for why it's good to shrink them (easier to roll back, easier to isolate bugs, etc.). Maybe grey-area does mean to ban all large PRs, but that's not evident in this thread where they wrote a response to a specific comment offering their take on how to resolve the problem raised in that first comment.
> You're loosing big swing aggressive efforts to make sweeping progress.
Just a tip: "losing" not "loosing". We loose arrows at our enemies, we let loose the dogs of war, we loosen our purse strings. But we do not "loose big swing aggressive efforts", we "lose big swing aggressive efforts". It's funny that you get it right once, but mix the two up in the very next sentence.
What are the PRs you're thinking of though. If you mean a full clean rewrite, they'd probably proceed with spec first then just write it in bits to the spec. No reason it has to be large prs or smaller that's a design choice.
Often an exercise I find useful is do a quick big PR, then split it into small chunks that make sense independently for review. Or you can chain prs. Both those things can be done.
You're welcome to do large PRs, I'm not a fan of huge PRs though and would not pretend to review them (as pretending is what it would be), nor would I like to work somewhere where this is the culture.
Zed's delta (https://delta.dev/) seems to be solving this problem by extending the version control to the conversation layer. I don't know if I'd want all my conversation to be tracked, some stuff belongs to the draft sheet.
1. PRs come with "the prompt". In openspec parlance this is a set of docs: a proposal, design, specs, task list.
2. I have a tiny skill to slice and dice PRs, so I can review each part of the system separately by rewriting commits in order of reviewal: specs/docs, production code, tests, evidence. I sometimes pull DB queries to a separate commit for focused review.
3. The evidence bit is built by another skill: go over all added spec scenarios and produce a markdown document with links to the code implementing the scenario and the tests proving the implementation works. Emacs helps me jump back and forth via those links and read the parts I'm interested in.
My next goal is to extend openspec schemas with custom workflow steps to make PRs land in my preferred review structure and contain the evidence report, so I don't have to build it.
I also think that might not be everything you need to really vet/recreate those PRs since there's a lot of strategic and operational stuff that goes into the pre-composition runs (sometimes I actually throw everything away and restart), so something a little more sophisticated would be interesting.
However, having a rigorous spec process which ends up giving lots of details to the agent seems to me the right way to build stuff with LLMs. Rather than iterating and piling changes after changes.
Claude absolutely loves to reimplement the wheel locally instead of just calling a method in a library we already depend on. Every doc comment and README.md update is bloated by 2-5x what's needed to communicate intent or to actually be read by a human later. It makes random drive-by edits that aren't necessary and weren't asked for in the prompt. It's a well oiled machine for producing astronomical bloat by default if you don't supervise and rein it in!
I had a recent case where I, being the lead, sliced up the work real good into an epic and what not and a guy on the team just did a "hurr durr, Claude, go wild with all that" and threw a huge PR over the wall linked to 5+ stories.
Well, we got to have "the conversation" after that and learned how to fix these kinds of PRs together...