Hacker News Reader

Comment by xyzsparetimexyz | Hacker News Reader

If you get a 1600 line PR you just close it and ask them to break it up into reviewable chunks. If your workplace has an issue with that, quit. This was true before AI and will be true after AI.

View on HN

There are a number of cases where this is not really possible. For some classes of updates, the structure of the underlying application and the type of update being made requires that you do an "all or nothing" type of update in order to get a buildable result. I've run into this a lot with Large Java applications where we have to jump several Spring versions just due to the scope of what's being updated. More incremental updates weren't an option for a number of time/architectural reasons and refactoring the application structure (which really wouldn't have helped too much either) would have been time and cost prohibitive... Really annoying but sometimes you just don't have another option to actually accomplish your goals.

That has happened (and still happens) at my company, but in this case we are upfront about it. We communicate that we’ll have to do a very big PR, propose to peer-review it, etc.

There are solutions.

Some people can write 1-3k lines of good code (incl. tests) in a day when everything is just right. We used to be called 10xers lol. The 1600LOC PR is legit if trust is there, it's really a single change unit, it's not just being thrown over a wall (should have a great PR description and clear, concise commit history).

I automatically block PRs with LLM-generated summaries, commit messages, documentation, etc.

Some people get so precious about code bases and want everything to be 100 line digestable units that working with them is becomes near impossible when they dig their heels in.

It's like dealing an angry grandpa throwing mud over your newly cleaned car, "You gotta start at the wheels lad, not the windows, do it again".

Great, now you've broken the flow, I have to re-do everything, figure out which tests to introduce in which order and unravel them all, ironically this is where I've found more bugs creeping in, because you're no longer diligent - you're appeasing performatively.

I mean, there are some exceptions on when 1600 PRs are acceptable (Refactorings, etc) but otherwise agree.

What really bugs me is that today, it is easier than ever to do this (even the LLM can do this!) and people still don't do it.

I ended up overengineering a LangGraph workflow to handle this. It forces the LLM to generate and pass its own tests in a sandbox before I even see the PR. The API costs are significantly higher because of the retry loops, but it filters out the low effort attempts.

Or just have AI do it for you /s

If you can have AI review the PR, does this still matter?

Reply on news.ycombinator.com