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

It should be but often isn't. There's been a lot of threads on HN where the response to huge PRs wasn't "Don't do that, use AI when authoring better" but "The reviewers are actually the problem, they're missing the AI train". And I see this in industry too.