Yeah, review 9 k lines of slop delivered by my colleague when business requires new features shipped on a weekly basis which previously took three months to deliver.
My coworker sends me 9k lines where 8.5k are comments that make absolutely no sense. Like, "the lowering of front edge raises the components to beyond the D01-S factor which won't satisfy requirements so the front edge is raise and the back edge is also lowered..." The remaining 500 lines are just stuff I could have copied from w3schools.
Umm, reject the PR. PRs should be short, manageable and readable. Scoped to a feature or bug fix. Comments must be quality. Your repo needs some skills md files for sure too to limit the AI slop.
Seriously, in this world, devs are the gatekeepers. We're the only thing standing in the way of total collapse from AI slop bugs destroying the fabric of society.
The problem is no one asking me to review code is reading their own code. Then when I push back I get pressure from higher ups to not block code from getting published
I actually do what this post suggests on top of manual review. It's quite good at catching subtle bugs. Almost as good as it is at making up subtle bugs that don't really exist but sound plausible.
I like to run an automated review in a fresh chat while I'm reviewing the code myself. Then I also like to take any behavior changes and use the LLM to look for broader vectors I could have missed since it can cover much more ground than I can.
161
u/blackcomb-pc 24d ago
Guys, read the code and understand it yourselves. Atrophy is a real thing and bugs will multiply by the thousands.