Live data from Hacker News

Stop sending me huge PRs; a rant

getsmall.xyz

91–100 of 116 posts

Re: Stop sending me huge PRs; a rant

#91

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.

A good middle ground is to have a large PR open for reference, and then split sections of it out into separate PRs. This way you get nice reviewable chunks while also having the broader context.

This is similar to stacked PRs except that it's much easier to tweak things as you split them out without rebase shenanigans although of course if you tweak too much it kind of defeats the point of the whole thing.

A nice thing about this is that you can put the large PR up while it's still very draft for conceptual review (socialisatuon etc etc) while you work on splitting out and polishing parts of it.

Re: Stop sending me huge PRs; a rant

#92
post #42

Earlier quoted context omitted.

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.

Agree, I was not talking about a business context.

But if people are submitting garbage in a business context you got other problems you need to address.

Re: Stop sending me huge PRs; a rant

#93
post #87

Earlier quoted context omitted.

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.

"There's no trust or reputation in OSS" is a pretty interesting take.

Re: Stop sending me huge PRs; a rant

#94
We were forced to merge 2 HUGE PRs this week because of a customer deadline. It didn't need to be this way, but our AI maximalist team member went full toxenmaxxing and we had 92 frontend files and 40ish backend.

Untestable, touched nearly the entire application stack, had several trivialities that were huge sticking points in review that obscured other more substantive issues we should have spent review time on.

Re: Stop sending me huge PRs; a rant

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

Re: Stop sending me huge PRs; a rant

#96

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

What does “accountability” mean to you here. Isn’t that the point of a reviewer to make them also accountable for the PR?

I think what you’re outlining here is an entire change to the code creation and merging process, not just adding an AI helper to the “coder”.

Re: Stop sending me huge PRs; a rant

#97

Earlier quoted context omitted.

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.

Hang in there, the competence crisis/slopocalypse is coming sooner rather than later.

Re: Stop sending me huge PRs; a rant

#98
post #96

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

What does “accountability” mean to you here. Isn’t that the point of a reviewer to make them also accountable for the PR? I think what you’re outlining here is an entire change to the code creation and merging process, not just adding an AI helper to the “coder”.

It means the stakes are higher for individuals. The coding task is easier because of ai, but because fewer people are going to review it you have more responsibility for it. You can't push out slop that "should work" or "works on my machine", etc. and put the burden on reviewers to catch edge cases. You own the result and what follows so you need to think ahead more. The coding is easier, the consequences are more personal.

Re: Stop sending me huge PRs; a rant

#99

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…

I find his particular style far from extrimist. I see the delivery as artistic style, serving to make a point. A kind of thought-bait, inviting one to consider the reason behind a jarring argument and hopefully arrive at a useful, even if milder and more practical conclusion on the no-comments only spectrum.

Re: Stop sending me huge PRs; a rant

#100

Earlier quoted context omitted.

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

The point of his argument is that if it isn't obvious from code, there is usually an opportunity to make it obvious by rewriting the code. This is often not practical, but it doesn't make it less true in the abstract. E.g., in your example one could make a constant for the 6% multiplier and call it LAST_DAY_OF_MONTH_DISCOUNT and take every possible other similar steps to have that idea of that comment embedded into the running code, not in the comments. This way everyone who reads the code can gain that deep knowledge by just reading it.
Post reply on HN