While I agree with the main thesis here, I find this extremely worrying:
> I am amazed every time how my 3-5k line diffs created in a few hours don’t end up breaking anything, and instead even increase stability.
In my personal opinion, there's no way you're going to get a high quality code base while adding 3,000 - 5,000 lines of code from LLMs on a regular basis. Those are huge diffs.
Yes. From experience, for a relatively complex system, 1k+ line PRs from mid-level devs without tests are almost guaranteed to have bugs; often nasty ones which can take many hours to identify and fix.
I remember when I started coding (decades ago), it would take me days to debug certain issues. Part of the problem was that it was difficult to find information online at the time, but another part of the problem was that my code was over-engineered. I could churn out thousands of lines of code quickly but I was only trying to produce code which appeared to work, not code which actually worked in all situations. I would be shocked when some of my code turned out to break once in a while but now I understand that this is a natural consequence of over-complicating the solution and churning out those lines as fast as I could without thinking enough.
Good code is succinct; it looks like it was discovered in its minimal form. Bad code looks like it was invented and the author tried to make it extra fancy. After 20 years coding, I can tell bad code within seconds.
Good code is just easy to read; first of all, you already know what each function is going to do before you even started reading it, just by its name. Then when you read it, there's nothing unexpected, it's not doing anything unnecessary.
Yeah imagine one of your colleagues doing this to your code base...
Imagine a reviewer that doesn't block that patch immediately.
Of course, there might be some exceptions like if the codebase for some reason has some massive fixed tables or imports upstream files that may get updated occasionally. Those end up as massive patches or sets.
Well it's possible the LLM is re-creating the file to do it's updates. I've noticed in the past that LLMs tend to prefer doing that.
Not to different from how a college CS student who hasn't learned git yet would do come to think of it.
Still pretty bad if the author isn't taking the time to at least cull the changes. Though guess it could just be file renames?
So history is going to be impossible to understand because every change is a total re-write of all affected files? I suppose that doesn't matter if you never actually try to investigate yourself and instead just tell your computer to fix the bug. You'd better hope it can though.
As long as at least half of the lines are well-written tests, this is more achievable than you'd think.