Live data from Hacker News

Stop sending me huge PRs; a rant

getsmall.xyz

71–80 of 116 posts

Re: Stop sending me huge PRs; a rant

#71
I think this is more a symptom of the problem than the actual problem.

The issue is that we can generate tons of code using AI, but then are blocked on having humans review all of it.

I don’t think we should auto-approve all of this code without human review - that clearly doesn’t work either.

What I do think we need is probably at least two-fold 1) better ways to explain these big PRs to human reviewers. 2) better ways to verify the functionality of a piece of code. Things like auto generating walkthrough videos

I’m not sure that even this is enough. I’m sure there will be agents that try to solve this problem.

Re: Stop sending me huge PRs; a rant

#72

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 have had some success with asking the LLM to rewrite the commit history after the feature was written. I often have a good idea of a good conceptual split, and the LLM has no problem doing the soul-crushing work of manually pulling out individual files or hunks into a sequence of commits and making sure each builds.

I need to do this before I can even review the code myself, and I review everything before I send it to my colleagues for their review.

Re: Stop sending me huge PRs; a rant

#73
If you generate PRs too big to review for others, then they are too big to review for yourself. This means you are delegating the task of understanding the code to an LLM, and the end result is inevitably that noone in the organization understands the code better than someone who just walked in the door. They can write the next LLM prompt just as well as you because they know as little about the system as you.

In that situation I ask you: what is your moat as a software company? Why would your customers keep paying you when companies like Anthropic can just do your-software-company-as-a-service and cut out the middle man and six figure salaries?

Re: Stop sending me huge PRs; a rant

#74
post #71

I think this is more a symptom of the problem than the actual problem. The issue is that we can generate tons of code using AI, but then are blocked on having humans review all of it. I don’t think we should auto-approve all of this code without human review - that clearly doesn’t work either. What I do think we need is probably at least two-fold 1) better ways to explain these big PRs to human reviewers. 2) better w…

Or people could stop using LLMs to generate huge swaths of code, and companies could discipline those who refuse to stop. It's providing negative value at this point.

Re: Stop sending me huge PRs; a rant

#76
post #11

> If your variable is not named well and you need a comment, name your variable better. 100% agree. While you are at it, consider naming and writing your functions in such a way that doesn't require a wall of comments. Clean Code uncle Bob style.

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

Has it ever been a thing in most companies? I have seen definitely more bad code and negligance than serious, skillful attempts to write clean code.

Which rules do you think are particularly outdated?

Re: Stop sending me huge PRs; a rant

#77
post #12

Earlier quoted context omitted.

Then reject them for being incomprehensible? Look, if you don't think code review is worthwhile, don't do it. Just give everybody unfettered permission to merge. But don't pretend to do review if you're not trying to maintain some standard of quality.

I do think code review is worthwhile, not sure how you read that from my comment. A cap on PR size isn't inherently going to make an LLM do a good job of segmenting PRs. It requires careful prompting or manual action, the kind of effort typically exerted by people who already cared enough not to hit such a cap. You may as well just ditch the cap, to save yourself from having to reject a series of PRs rather than just…

This is defeatism. Reject unacceptable PRs, full stop. It's on the author to work to break them up.

Re: Stop sending me huge PRs; a rant

#78
post #71

I think this is more a symptom of the problem than the actual problem. The issue is that we can generate tons of code using AI, but then are blocked on having humans review all of it. I don’t think we should auto-approve all of this code without human review - that clearly doesn’t work either. What I do think we need is probably at least two-fold 1) better ways to explain these big PRs to human reviewers. 2) better w…

> Things like auto generating walkthrough videos

I'm trying to write this with respect, but please explain your thought process here.

If your PR description is a video instead of a written explanation, I'm rejecting it without even reading the code.

Re: Stop sending me huge PRs; a rant

#79
post #11

> If your variable is not named well and you need a comment, name your variable better. 100% agree. While you are at it, consider naming and writing your functions in such a way that doesn't require a wall of comments. Clean Code uncle Bob style.

> 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 guideposts along the way. But I worked at a company that loved Uncle Bob and enforced "no comments!" as a rule... just guess how clean and tidy that codebase was!

Re: Stop sending me huge PRs; a rant

#80

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 have had some success with asking the LLM to rewrite the commit history after the feature was written. I often have a good idea of a good conceptual split, and the LLM has no problem doing the soul-crushing work of manually pulling out individual files or hunks into a sequence of commits and making sure each builds. I need to do this before I can even review the code myself, and I review everything before I send it…

But the thin is that de dev don't review the generated code ... because, surely, that's the reviewer's job ... right ? /s
Post reply on HN