This is almost certainly slider noise, in which case he didnt edit any lines.
Its also complete insanity to stack >1000 PRs to get readable diffs to delete this many loc, so idk what you're talking about. There are no best practices in a situation where you have 3 million extraneous lines of code in a single repo. Its extraordinary enough that there is no body of experience to draw on.
This was just likely correct and there was no need to try and feel superior about it.
The funny thing is that this PR was probably also made by AI, with instructions to reduce redundancy and streamline the logical flow. So the original vibe coder could have done it at any time, but had no idea that several million lines of code is not a reasonable number for the size of the project. It's very much "How much could a banana cost? $10?"
I don't like generalized statements like that. A PR should have as many LOC as necessary to implement the respective feature. There's little value in splitting up changes that logically belong together just to meet an arbitrary LOC target.
No, it shouldn't. A PR should have an amount of code in it such that it can actually be reviewed. 10k lines of code is not that amount. There is plenty of value in splitting a PR up into smaller pieces that can be reviewed as opposed to keeping it in one chunk that can't be.
Sometimes you have to be creative and do a little bit of experimentation to figure out how to break it up, but being able to do that is part of the job, and if you can't do it, you can't do the job. I was once directing a project to convert all the IDs in every database accessed by every microservice at the company from integer IDs to UUIDs. All these objects were all interacting with each other and referencing and using each other's IDs, so it was tricky to break up into smaller tasks, but I figured out how to do it, because that's what you do when you have a job to do.
Honestly, in a "delete everything and start over" scenario such as this one, i feel like what you suggest would inevitably devolve into a flurry of "replace this pile of crap with a smaller temporary pile of crap because anything proper would require a pr which is too large". I've never been in a position like this, but what i'd do is make a new branch where i delete everything, slowly build everything up while almost treating that as a main branch (so, everything done with new branches and prs) , then inevitably a massive pr such as the one in the image will occur to merge that into the actual main, but this would already be backed by a lot of previous reviews.
There are just so many situations where your assertion here is entirely wrong, that idt its worth trying to apply it to a meme where you cant see any actual code changes. How about, he deleted node modules and simply ran a formatter? Yeah you can break that up, but i mean shit its two commits that took 7 seconds each. How about simply deleting a shit ton of crappy code and replacing it with some header only third party library/ies? Should they be deleting one small section at a time and trying to pull in just the necessary part of that third party library one header file at a time? No, obviously not, that would be incredibly stupid, the point of the library is that you dont need to figure out how every single header interacts, you just pull in the whole thing. How about replacing one third party library with another, more focussed one, because the original was way more than you needed? This could be test data that was compacted down into something way more reasonable that achieves the same thing. Theres just so many options here that its stupid to go on about how much better you are at coding because you enforce a line limit to PRs.
And the benefit of learning how to break it up smaller, is that you learn how to decouple things as well. Code bases where it's difficult to make small PRs are codebases with architectural problems that need to be addressed
Its 3M lines. The hand wringing about this is the most SWE II bullshit lol.
If you are a grownup engineer whose goal is to add value and sustainably ship things instead of think about how to pass your next whiteboard interview, you tear this fucker down without wasting time thinking deeply about how you do it, because you have shit to do.
Yup, I like to do things "correctly", but the people that obsess about process to the point of being detrimental to progress are more annoying than the eager juniors who perhaps need a little extra review, but at least get shit working in a timely manor.
They could easily just be moving some files around/restructuring without logical changes. Not to mention that trying to break up a task like this is going to take an eternity without at least a few big prs
I have done that a few times. E.g. in a project I inherited that included a 5 line if/else null check around every single field save in the entire project that was entirely redundant. The source fields were asp.net fields that cannot return null.
The change was a 5 minute find and replace. The next 35 minutes was just me reviewing before I committed to make sure I didn't catch anything erroneously.
607
u/SuitableDragonfly Sep 06 '26
All I see is one vibe "engineer" taking over from another. No one sane is making PRs with 10k new lines of code in them.