logoalt Hacker News

kentmyesterday at 8:07 PM3 repliesview on HN

Its exactly this. I have had a few LLM coding sessions where I reviewed the resulting work and thought "I don't think my team can safely PR this." I then went back and broke it down into smaller PRs, still using LLMs but at a size that is easy to review. And I reviewed the output myself before I asked a reviewer to commit their time.

The problem is that this is increasingly seen as a non-productive workflow slowing everyone else down, so the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable. I suppose those advocates have more faith in LLM output compared to humans than I do.


Replies

greiskulyesterday at 10:04 PM

Thats the thing with giant PRs. They never really needed to be reviewed anyway. In cultures with strong review culture I have worked at, if you send me a thousand line PR and ask me to review it, I will look at the giant blob of text, and immediately fire off a "it's too long, can you cut it into smaller PRs?".

Because I don't trust myself to review a giant PR. It takes too much cognition to properly review it.

And now that people are making PRs with AI, this is even more important. If the AI was good enough to have coded it, please instruct it to make the changes in reviewable chunks.

majormajoryesterday at 9:45 PM

> the pressure is growing for writers to just shove massive PRs out the door and reviewers to use LLMs to make that tractable

Even in these move-fast envs, it should be reasonably apparent for people to realize that the author should be using the LLM to make the PR tractable, not solely using the LLM to shovel out a giant PR + slop PR description.

And the LLMs can often do this - if you ask to restructure or break up a big change differently, they can often make quite reasonable suggestions and help with it. That's just not what you're gonna get if you're lazy. If you want a small LLM-generated change, often you have to start with a big one then ask it to figure out what it can get rid of, since many times it doesn't have perfect model of all the code in it's "head" before it starts spitting stuff out. The big companies have been doing their best to automate this for the last couple of years vs the even-more-blind attempts you used to get, but there's still the issue of the models+tools following generic advice aimed at median codebases vs being intimately familiar with this codebase.

You can go fast without being lazy. And when going fast, in some ways, it's more important than ever to put in that effort to not blowing things up.

show 1 reply
gedyyesterday at 8:50 PM

> I suppose those advocates have more faith in LLM output compared to humans than I do.

Some of this is the funny situation where the faithful will state: "This writes better code than I do!" and miss the irony of: "yes, yes it does"

show 2 replies