Hacker News Reader

Comment by philbo | Hacker News Reader

If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks. Large dumps of code are basically unreviewable by humans, but it seems like a lot of people have forgotten about that when it comes to LLMs.

View on HN

I think it's worse than that. At least if I dumped 5k LoC on somebody in 2021, you knew I spent the time to write it, so it's "fair" to ask you to read it. But I didn't write it in 2026, so you shouldn't read it.

I think it's less about "break it down" and more about "let's communicate at the same altitude."

I wrote a (bait-titled) post about it: https://tern.sh/blog/stop-reading-prs/

113 files +22913 −2423

305 files +15075 −13110

153 files +21934 −8698

125 files +28120 −2398

43 files +11188 −63

118 files +21564 −647

These are the largest (6 of 35) in the past 30 days. added: 190079 removed: 39696 in the last 6 months

from one person.

I hope 99% of that was documentation and testing.

You aren't allowed to block PRs for being too large anymore. The objective that every engineer should be 2x/3x/5x more productive can only be achieved if you go totally lax on code reviews.

Because if all your SWEs produce 5x more code, it also means they have to review 5x more code. But LLMs don't really help with code reviews. Then it becomes a Metcalfian paradox unless you just rubberstamp PRs, which is what is expected of you.

its pretty easy to point your terminal agent to your giant pr and ask it to break it up into small prs

if youre being asked to rubberstamp prs thats a management skill issue

Breaking up a giant PR can be a tedious, time-consuming hassle, and in the past I could sympathize in practice if someone had a giant PR they didn't have time to decompose once they got it working.

But it's also the exact sort of thing that LLMs are literally perfect for in my experience so there's really no excuse anymore. I've never seen Claude fail to turn a 5k PR into a well-decomposed Graphite stack.

Hell, I've hand-written a large PR as a single commit and then asked claude to break it down for me at least once. But I think the fact doing this task by hand is a tedious, time-consuming hassle is not because it inherently has to be but because the tooling for doing it has barely changed in the past 15 years.

Now you get not just the 5 LoC to review but a 5 page essay to read in the form an auto-generated review as well. Which makes the submitter even more indignant when you start nit picking things about how it's implemented.

> If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks.

I would, and all my training at Google told me to do that. But what I found after I left that comfortable box was that somehow this kind of practice is acceptable in the industry at large and you're expected to just Deal With It(tm). 5k lines isn't even high by what I've seen.

Worse the "code review" tools that people have access to in GitHub make this absolutely and totally unworkable to incrementally improve review. Messy merge commits full of "responding to code review" comments. Threads impossible to follow. Just bad tooling.

So a lot of shops, from what I've seen, are just yeeting it with very shallow reviews.

This is my observation pre agentic AI. LLMs just threw kerosene on that dumpster fire.

I think they expect you to also use an LLM to review, and I bet they are doing exactly that when asked to review someone else's code.

That gets you 90% the way there. So, it it only really works if you accept the cruft and the risks associated with that last 10%. Been doing this day in a day out for the last few months and no matter how much and how good we get the automated reviews, we still can't skip the manual ones.

Theres really no diff between a rubber stamp and an llm review, they both do the same thing.

In terms of knowledge sharing and gathering hard-won human context I agree, sort of. An LM review can at least prompt some reasonable changes, catch performance issues, etc.

It is not so much forgetting as much as it is acceptance that when welcoming AI into a codebase, the code can no longer matter; that all that matters is that the properties of the system are validated. That isn't a change that comes free, so nobody should be expecting magic, it is a different set of tradeoffs. There is no such thing as a panacea.

How can the code no longer matter? It literally is the logic (not to mention performance, and reliability) of the software.

You might say in the same way that machine code stopped mattering when programming languages gained in popularity. Almost nobody will ever review machine code. I anticipate 90% of all programmers today wouldn't even know how. The move again is towards a higher level of abstraction; this time validation. Instead of describing how the program is to function, you define the properties of the system and let the fancy compiler figure out what the code should look like. If that means something that a human would call spaghetti, oh well.

I can be 99.99999999% certain when I write an if statement like "if (x > 1) do y" that the compiler will turn that into the equivalent machine code. So, yes, unless I hit some crazy performance bottleneck, I'm not concerned about reviewing the machine code.

However, LLM outputs change with slight re-wording of prompts and with each new model release. I could hand write a test that says if x > 1 make sure y happens, but then what productivity was gained?

Just like you can be 99.99999999% certain that your properties will eventually be satisfied when the fancy compiler turns it into equivalent code.

If your program is truly nothing more than that "if" statement then there is unlikely to be any productivity gain, just as there is no real productivity gain using a programming language over flipping toggle switches for something so simple. Programming languages would have never been invented if that bit of logic summed up the entirety of computer science. In the real world, the calculus starts to change when you are trying to solve bigger problems. A lot of solutions require way more code to implement than to describe the necessary properties of. That is where you can gain some huge productivity gains by being able to focus on declaring the properties over having to define the full implementation.

But, again, it is not a panacea. No such thing exists. Every abstraction brings its own set of tradeoffs. Your job is to find the tradeoffs you can accept for your unique circumstances. What others are doing is irrelevant to your situation, but it remains that others are doing things and it can be fun to learn about it.

You're over-indexing on the (erroneous) idea that my example meant that the program would be a single if statement.

> A lot of solutions require way more code to implement than to describe the necessary properties of.

That's true to an extent, the additional code often define the emergent and undiscovered properties of a system.

> the additional code often define the emergent and undiscovered properties of a system.

That's the cost of abstraction. Everything has tradeoffs.

> all that matters is that the properties of the system are validated

I don’t think this is possible in practice without leaning on the stability of the code base.

Reply on news.ycombinator.com