This struck me too, but I think it is intentionally a high limit to prevent problems like relatively low impact/high LoC tests from tipping a small change into a large one. That would encourage gamification like skipping useful scenarios to keep a change "small".
It can be even more lines as long as the hunks are continuous. Once you lose the context of change and have to “zoom out” to see where it fits in, the review time grows significantly.
> Only my personal view but even 1000 LoC is not a "small change".
To make matters worse, they effectively implemented a YOLO allowlist to allow a specific developer to batch 1k loc changes to the set of services they are working on without requiring any scrutiny.
Crazy stuff.
They could achieve this in a much simpler way by just removing PR requirements from those users in those projects.
I disagree with their criteria that they couple with it, but I could come up with some of my own that I'd like better.
"This has 900 lines but 850 of them are in codegen boilerplate that changed", for instance.
"This has 900 lines but they're mostly updating a bunch of test fixtures along common patterns."
"This is 800 lines because we bumped ten version dependencies and that bumped a lot of other things + they changed the package naming for some so we had to rewrite a bunch of imports."
"I added two panels to a Grafana dashboard." (ok slight exaggeration)
Of course it's relevant: your statement is a strawman ... they didn't claim that 1000 lines is a small change, that was part of a conjunction. Basic logic here.
I did bother to read it (and that ad hominem charge is an explicit violation of the HN guidelines) and you're mischaracterizing it. In any case they did not say that 1000 lines is a small change.
Despite the name, the label isn’t is only added if it meets about 5 other criteria, files and folders can be excluded meaning any PR with a change in them isn’t eligible for the label, and the PRs still need to pass all the non-AI quality checks.
Even if it’s not perfect, I think it’s the right idea. There’s some category of changes that are low risk and simple enough that a human reviewer isn’t needed and if you can identify those then you’re going to be able to save human review for the things that really need it.
We arrived at a similar concept, though ours it the negation of this: we have a series of deterministic checks that can potentially add the `needs-human-review` tag to a PR. If that tag isn't present, you can merge your own PR; otherwise you need at least one human.
I think we're probably around 50/50 needing human review vs not.
Our rules for whether something needs a human review are currently mostly filepath-based: are you touching the api, or an important internal contract, or adding db migrations? Though I'd like to make it a bit smarter as we're definitely getting false positives.
I thought for sure you might be one of my coworkers based on this comment, we do pretty much the same thing with our “LLM Review” tool. It tries its best to determine what needs human eyes (mostly through file paths and the model’s own “discretion” for changes outside the “important” paths).
We have something similar. I made a service that you install in your GitHub repo. It has configuration where you can set the review bar for specific paths. That review bar could be an AI agent with a specific prompt has to bless the change, so you can do stuff like "any change except to billing is okay.” If that passes you can merge your own PRs, no review needed.
Something like 30% of PRs in our company are merged like this. It's a huge velocity win when you don't have to wait around for a review.
IIRC this is also somewhat verified empirically. I think it was in Steve McConnell's I saw a plot of fault injection rate as a function of change size based on real data (probably collected in the '80s, but still!), and the number of bugs per line of code were by far highest in the 1–5 line change range.
This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...
> In my experience, the “small change” merge requests tend to be the most consequential.
I think you're confusing things. The "small change" refers to the diff size. It's far easier to review a one-liner because the impact analysis is limited to that local change.
Of course if your change is something like "mutex.lock()" or "rm -rf *" then these changes will be more consequential than 500 files worth of whitespace changes.
Oh no! This is going in the wrong direction, isn't it? From the headline, I'd assumed the takeaway was encouraging small changes (and 1000 LoC is not "small" by any definition) and maybe encouraging the author to refactor at larger sizes to make human review easier. Instead it's just bypassing human review entirely?
Code review is such a key step to the feedback loop and helps keep people current on the changes as they come out. Skipping that entirely is just inviting disaster.
Every bad change here, that has been merged in the last 6 months, correlated with a lack of human review. Sure, someone hit the approve button, but it was done within 30 seconds of the PR creation time, clearly no review was performed. This is in repos that have deterministic as well as ai driven review CI checks.
And that doesn't even get into the "features" that were implemented without reviewing the design or requirements were actually hit (they were not).
I would love to replace all of these useless meat bags with more ai. But I would absolutely still want to be in the loop to review things.
The lesson I've learned about AI is that lazy/bad engineers without AI are still lazy/bad engineers with AI.
Okay, sorry, I don't know what I'm arguing anymore, this turned into a rant.
I introduced a similar change at work for Terraform changes. One big PR can create many planned changes in many different root modules; one tiny requested change in that PR can thus hold up a lot of stuff that doesn't need to be held up. So I added Claude rules/skills that instruct AI to break up the PR into the smallest possible functional/mergeable units of work, make one PR for each, and stack PRs on inter-dependencies. The result may be 40 PRs, but 38 of them can be approved and merged immediately. This lands more changes sooner, so work being started by others incorporates more current work, leading to less rework/refactoring/rebase fixes. It's Continuous Integration on autopilot. (https://martinfowler.com/articles/continuousIntegration.html)
The author is only seeing 10% as small-change, but my version has 80% as small-change. This is due to Terraform forcing you to be intentional about the borders of functional software. There is a minimum-viable-deployable component in Terraform called a Resource: you can add more resources to your module (increasing the scope), but you can't get any smaller than one resource. So it's relatively easy to define what makes a module functional, and reason about how big it gets, before deciding to break the module up. (Technically you can -target specific parts of a single resource but it's quite frowned upon)
Compare to traditional software design, where there is no absolute minimum functionality. You can make "minimum functional software" as huge or as tiny as you want. Different people design their software different ways (often unintentionally) resulting in low cohesion and a very large scope of changes required for minimum function. If you want smaller changes, you have to intentionally design your software for it.
Only my personal view but even 1000 LoC is not a "small change".
The other criteria are more important.
To make matters worse, they effectively implemented a YOLO allowlist to allow a specific developer to batch 1k loc changes to the set of services they are working on without requiring any scrutiny.
Crazy stuff.
They could achieve this in a much simpler way by just removing PR requirements from those users in those projects.
But this has "agents".
"This has 900 lines but 850 of them are in codegen boilerplate that changed", for instance.
"This has 900 lines but they're mostly updating a bunch of test fixtures along common patterns."
"This is 800 lines because we bumped ten version dependencies and that bumped a lot of other things + they changed the package naming for some so we had to rewrite a bunch of imports."
"I added two panels to a Grafana dashboard." (ok slight exaggeration)
I won't respond further.
If you bother to read the blog post, the other conditions in the "AND" are who posted the developer and which project the PR is updating.
This does not make it better. It's a YOLO bro allowlist.
I won't respond further.
I do not think this is a good metric
Even if it’s not perfect, I think it’s the right idea. There’s some category of changes that are low risk and simple enough that a human reviewer isn’t needed and if you can identify those then you’re going to be able to save human review for the things that really need it.
If something is low risk and simple enough then it can be quickly judged in 1 to 5 minutes. Not sure why someone can’t review it.
I think we're probably around 50/50 needing human review vs not.
Our rules for whether something needs a human review are currently mostly filepath-based: are you touching the api, or an important internal contract, or adding db migrations? Though I'd like to make it a bit smarter as we're definitely getting false positives.
Something like 30% of PRs in our company are merged like this. It's a huge velocity win when you don't have to wait around for a review.
Sure, they look harmless, but it’s all the external pieces (not shown in the diff) impacted by the “small change” tend to make such a disaster.
This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...
I think you're confusing things. The "small change" refers to the diff size. It's far easier to review a one-liner because the impact analysis is limited to that local change.
Of course if your change is something like "mutex.lock()" or "rm -rf *" then these changes will be more consequential than 500 files worth of whitespace changes.
What kind of change impacts fewer than 1 services or applications? Is this meant to say “at most N”?
Code review is such a key step to the feedback loop and helps keep people current on the changes as they come out. Skipping that entirely is just inviting disaster.
And that doesn't even get into the "features" that were implemented without reviewing the design or requirements were actually hit (they were not).
I would love to replace all of these useless meat bags with more ai. But I would absolutely still want to be in the loop to review things.
The lesson I've learned about AI is that lazy/bad engineers without AI are still lazy/bad engineers with AI.
Okay, sorry, I don't know what I'm arguing anymore, this turned into a rant.
The author is only seeing 10% as small-change, but my version has 80% as small-change. This is due to Terraform forcing you to be intentional about the borders of functional software. There is a minimum-viable-deployable component in Terraform called a Resource: you can add more resources to your module (increasing the scope), but you can't get any smaller than one resource. So it's relatively easy to define what makes a module functional, and reason about how big it gets, before deciding to break the module up. (Technically you can -target specific parts of a single resource but it's quite frowned upon)
Compare to traditional software design, where there is no absolute minimum functionality. You can make "minimum functional software" as huge or as tiny as you want. Different people design their software different ways (often unintentionally) resulting in low cohesion and a very large scope of changes required for minimum function. If you want smaller changes, you have to intentionally design your software for it.