Live data from Hacker News

Stop sending me huge PRs; a rant

getsmall.xyz

81–90 of 116 posts

Re: Stop sending me huge PRs; a rant

#81

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 con…

> why do we put it up for human review? I would wager that [...] a human has placed themselves as a gatekeeper

Well, yes, presumably because the maintainers have an obligation to their users (or whoever else they answer to), so I doubt they're overly willing to relegate themselves to being a rubber stamp for whatever some LLM hallucinates as looking good to it.

Re: Stop sending me huge PRs; a rant

#82

Earlier quoted context omitted.

> Clean Code [U]ncle Bob style Without starting a flame war, in 2026, is this still really a thing? I cannot recall any developer that I thought was excellent ever quoting "Clean Code [U]ncle Bob style" as gospel for how to write your code. There are just so many silly rules that he touts.

Like all extremists, he takes a mild view "if you have to explain the code, maybe it needs to be refactored" to "no comments ever". Never mind business logic or footguns that can't be fixed right now because of Reasons or "I tried to change this and it blew up because of some remote script calls it that isn't in the codebase" or any number of other very useful comments that inform engineers (and now LLMs) as guidepos…

You raise some good points here. When I write comments, I only write what is not obvious from code. Example: Imagine there is some bizarre business rule that some insurance contract is 6% cheaper to write on the last business day of the month. That is exactly the kind of thing I will write inline code comments about. Someone without deep knowledge of that code would be clueless about that specific business rule.

I forgot about the no comments rule. Yeah, that sounds insane.

Re: Stop sending me huge PRs; a rant

#83
post #59

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,…

I can't be happier seeing how many posts are about AI making PR terrorists unhappy. They can no longer bully their teammates so they rant about it here

We've banned this account.

Re: Stop sending me huge PRs; a rant

#84
I'm surprises GitHub haven't added a mechanism to donate tokens to let a project maintainer inspect, verify, explain and test PRs.

For big PRs it would make a difference if I didn't have to check everything for malicious links and junk without spending my own money or time.

Re: Stop sending me huge PRs; a rant

#85
There's also another approach: Not all PRs should introduce new, functioning features or complete rewrites. Thus you can just introduce a handful of functions, some of the functionality behind a feature flag, a new db schema... and then introduce the rest in follow-up PRs. GitHub even does stacked PRs for this reason, so you can start big, organize your commits into these chunks and do the stacked PRs.

Having AI generate massive code and shoving it to your teammates' plates should be considered irresponsible. Yes, test code is verbose, but it should be accompanied with an adequate description of what is currently tested. Otherwise it's just AI having fun in your codebase.

Automated PR merges could still work, please just don't with multiple thousands of LoC changes. Both LLMs and humans have a context size limit.

Re: Stop sending me huge PRs; a rant

#86
post #42
post #16

>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.

As a maintainer just saying no and closing PRs is largely the solution

Sure, for FOSS. But at a business I'm not sure you'll stay employed long if you do this regularly and don't try to find ways to adapt to the new world we live in.

To be clear, I don't have an answer either. Reviews have definitely become a bottleneck, and the agent-created code has absolutely not reached a "broadly trustworthy" state for complex problems and maintainable contributions.

Re: Stop sending me huge PRs; a rant

#87

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 con…

I like this comment. I also have a lot of experience with lazy (my accusation!) reviewers who ask me to split a PR into smaller PRs. At some jobs, I felt like it was a strategy to sabotage my work (slow me down). In my experience, the best was to ensure your code will be approved (ok, maybe some minor tweaks) is to assign a code reviewer before you start writing code. You (the coder) performs some quick analysis, the…

Yes this. As an author I see it as my responsibility to socialise my work early and get buy in from reviewers.

The more I think about PR review, which I've been doing a lot lately thanks to AI, the more I see it as social in nature. Built on trust and reputation. It's no wonder OSS is tending to ban AI contributions - they don't have trust and reputation to fall back on as a heuristic.

Re: Stop sending me huge PRs; a rant

#88
post #62

Isn’t having humans review every PR only realistic for smaller systems? If AI is generating all these PRs, but humans still have to review every one of them, doesn’t that ultimately leave the humans responsible for everything?

Someone has to be responsible, because it sure won't do to call Anthropic at 4 am and ask why Claude caused your service to rack up $5m on AWS and delete all backups.

Re: Stop sending me huge PRs; a rant

#89

Apparently I'm in the minority, but if a single chunk of functionality legitimately needs a thousand lines of code, I'd rather see it all up front than have to review 5 separate PRs that don't do anything until they're combined.

If a massive PR can't be broken up into multiple small but meaningful sub-PRs then it's normally good manners to say something like 'here's what I want to change, this is why it needs changing, and I think it needs this massive overhaul which touches these million and one things'. But I don't think that's a likely scenario unless a codebase is poorly designed and the prevailing wisdom of 'to make a difficult change: first make the change easy, then make the easy change' will usually be applicable.
Post reply on HN