Live data from Hacker News

Stop sending me huge PRs; a rant

getsmall.xyz

21–30 of 116 posts

Re: Stop sending me huge PRs; a rant

#21

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

This is exactly how I have always worked. I personally don't operate well breaking things up into small, bite sized PRs like people want. So instead I do the whole big project, and then break it apart into logical segments for my colleagues.

And this is often how I proceed when working with an LLM as well. We build the whole thing, and if I think it needs to be split apart, then in another session I work with the LLM to break it apart into reasonable chunks.

Re: Stop sending me huge PRs; a rant

#22
post #3

Earlier quoted context omitted.

Yeah, that's a fun way to get massive stacks of PRs that are individually incomprehensible.

How? If one PR builds off another, won’t either: PR 1 is size 400 PR 2 is size 400 + 400 new PR 3 is size 800 + 400 new If they’re truly disjoint, would it be so bad to get them as unique? Because otherwise, when PRs depend on each other, you tend to get “one and then one and then one”. At least that’s how it’s worked on teams I’ve worked on that have soft size limits.

Size is an issue, but it isn't just about size. Ideally, agile development builds linearly in complexity. Rather than dumping a huge new feature, first introduce the building blocks and the reason you are introducing them, then the glue that ties them together, then the actual feature.

From what I've seen (not in software dev anymore, however I've been in it for close to 30 years), AI just tends to pile everything in, and it is very hard to review. No public model performs even average under the rules I've mentioned.

Also, simply breaking up a PR doesn't count if instead you dump all the PRs on maintainers at once. Humans are the bottleneck here, and can only review so much at once. If i were still involved in PR reviews, it doesn't matter if you gave me a single 4,000 line PR or 4 1,000 line PRs, I"d reject them.

What I want to see. Small, easily reviewable features with a build up to the main course, along with a good explanation for each. After that? I'd probably still reject it for a breach of code standards, or documentation, or because I don't like you sending me a PR at 4:59pm on a Friday. ;)

Humans also can't blindly rely on AI for review, so the models (more precisely, the folks building the underlying stuff) must adapt.

Re: Stop sending me huge PRs; a rant

#23
> 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 clean manner was extra work even before AI.

Re: Stop sending me huge PRs; a rant

#24

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

Yes, totally. This is how I work as well! Frankly, it seems like LLMs are pretty good if you tell them after the fact to divide work like this too, "make stacked prs with model a, then model b, then service c" has done wonders for my mental health.

Re: Stop sending me huge PRs; a rant

#26
Stumbled upon this the other day via my LinkedIn and now sanely look the jst code https://chromewebstore.google.com/detail/github-pr-focus/peb...

But the first thing I still check is consecutive comments and that goes very far as a signal whether the person sending it even tried to grok it or not

Re: Stop sending me huge PRs; a rant

#28

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

Yeah the one and only time I attempted an open source PR, it was for a performance improvement for one small part of the software but touched a zillion files. After looking at the PR I decided not to submit it because it just looked like a mess and I didn't really know how to split that sort of thing up at the time. AI might make this sort of thing more common, but it's certainly not new.

Re: Stop sending me huge PRs; a rant

#30

Earlier quoted context omitted.

CI by itself is not got enough because LLMs are extremely good at writing vacuous tests that don’t actually test anything but look like the test something. Even worse: they can write tests that make incorrect behavior part of your spec. Tests matter. Writing tests can be hard, boring, tedious. But if anything should still be written by hand in the age of LLMs it’s the tests. If you’re not looking at the application c…

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 will be ecstatic.
Post reply on HN