Reviewing someone else’s AI slop

[-]

overkiller_xd@reddit

We have this rule in our team, that max PR's must be under 500 lines of code changes unless absolutely necessary.

[-]

AppointmentDry9660@reddit

Create a new standard of commenting on their PR after they've completed their own self-review.

I will create PRs but I do not assign them to anyone until I've reviewed my own changes. I almost always need some new commits after I've self reviewed

[-]

entangled-zarbon@reddit

Spoke to someone who have pretty much made a rule for any AI Assisted code they need to be less than <500 LOC per PR or they won’t review it

Could be a good idea to have that as a forcing function for using AI sparingly as needed.

Most likely people will just rubber stamp these massive PRs and then AI slop ships to prod lol

[-]

Solid_Mongoose_3269@reddit

But...but..but I thought vibe coding was the future?

[-]

thewritingwallah@reddit

ai will kill the devs because it makes devs worse at coding, not because the ai is super smart

[-]

SoInsightful@reddit

I review it as if there were no AI involved at all.

If it's unreviewable due to sheer size, I'll reject it.
If there are obvious code issues, I'll point them out.
If the code has bugs, I'll tell them to fix them.
If it's lacking tests, I'll tell them to add some.
If they haven't self-reviewed or tested it, they must do so, etc.

If they create bad PRs and get pushback on them without having the opportunity to blame AI, I bet they'll change their tune quickly enough.

[-]

thewritingwallah@reddit

I don't and have never, and will never approve a shit PR.

I'll add my comments. If any dev of the higher ups want to push it through then they can get another person in the team to approve it.

this could lead to me having a bad rep with execs ... but in my 16 years in software industry .. it hasn't yet. So I'm rolling the dice.

[-]

NotASecondHander@reddit

The problem is that this approach still puts asymmetric workload on the reviewer.

[-]

SoInsightful@reddit

Obviously it's a larger workload than just immediately rejecting the PR outright.

In the PR template I introduced at work, whoever creates the PR must verify that they've reviewed their own code and tested the code, and they must show screenshots/videos and preferably also add tests proving that everything works as intended. The less effort they've made to make a good PR, the quicker I'll be to rejec the PR.

[-]

NotASecondHander@reddit

The less effort they've made to make a good PR, the quicker I'll be to reject the PR.

This is the key!

[-]

RuncibleBatleth@reddit

Block them from pushing their commits at all until they knock it off.

"But I can't save my work!"

"You're not doing any work, the AI is."

[-]

Wonderful-Habit-139@reddit

Completely what I hate about opinions that are like “ignore the fact that it’s AI generated”.

The person opening the PR put in no effort in the code that’s written.

[-]

Wonderful-Habit-139@reddit

This kind of advice should die down. Glad to see way better advice this time around in other comments compared to whatever this is.

[-]

Imaginary_Maybe_1687@reddit

I'll add, if its too hard to understand at a glance, I'll request an explanation good enough for reviewing

[-]

UXyes@reddit

This is the way. It doesn’t matter if AI generated it any more than it matters if it was typed in on a Mac or a Windows machine. The person who submitted it owns that code. If it’s garbage, they’re submitting garbage and should be treated likewise.

[-]

raddiwallah@reddit

That’s what I hate about this AI shit. The development time has been shortened but the team now needs to spend more time to review. Doesn’t look like any benefit.

[-]

thewritingwallah@reddit

I’m not surprised at all. AI is trained on all the publicly available code. So take all of that code and get the average and that’s what AI is using to generate code. As a professional software developer into my third decade of coding I can safely say that most of the code I see is bad to mediocre and less than 10% is good and a smaller percentage is excellent. It’s absolutely no surprise that AI produces almost all bad to mediocre code in large volumes.

I trust it to explain code pretty well. I trust it to read documentation and find stuff for me. I trust it write boiler plate scaffolding code and testing code. I never trust it to write core functionality. And until we teach it to distinguish good code from mediocre code, I don’t really see it getting better anytime soon.

writing code was never a bottleneck the actual bottlenecks were and still are:

code reviews, KTs through mentoring, pairing, testing, debugging and human coordination/ communication. All of this wrapped inside the labyrinth of tickets, planning meetings and agile rituals.

I've used certain code review bots but it's still extremely early.

Not every engineer ships better code with AI, but code review bots are pretty much universally good.

Stacking them is even better in my experience. One bot may miss something that another one catches, and the feedback is easy to scroll through.

The best code review bot in this present moment is stacking 5 code review bots. In the future, that might not be the case!

[-]

yohan-gouzerh@reddit

And this new GTP5 is crazy... It's crazy to troubleshoot, but it generate AI Slop at horse speed. A bunch of crazy over-complicated code when simple things will do the trick and be way better to maintain

[-]

exploradorobservador@reddit

I have produced some sophisticated test suites but then I have to spend liek 4 hours reading them to understand what they are actually doing.

Another downside of using generated code is that you can read it carefully three times, but if you come back a few weeks later and you won't remember it as well.

[-]

nacirema1@reddit

My coworker use ai to generate the PR description and it’s paragraphs long for simple changes. I just stop reading immediately when I see them

[-]

ComebacKids@reddit (OP)

It feels like it’s increased speed of good devs by like 10-20% because they actually scrutinize the code and test it.

This has increased the speed of bad devs by like 500%, and also increased the amount of time I need to spend reviewing code by 500%…

[-]

ares623@reddit

that 10-20% is actually overestimated. There was a recent study that it actually decreased speed by10-20% at worst, or 0% at best.

[-]

BootyMcStuffins@reddit

If we’re talking about the same study that’s not what it said. It said people overestimated time savings by 20%, not that it made them 20% slower.

And I agree with the other commenter the study was BS, they measured incredibly simple tasks in familiar codebases. AI isn’t going to improve on a 10 minute task

[-]

Helkafen1@reddit

No, it said both these things:

"Developer estimate after study": +20%
"Observed result": -20%

[-]

ares623@reddit

It’s been independently replicated as well (although it is by an individual, not a formal study). Some rando couldn’t believe the study so decided to replicate the study on themselves. They stuck with it for 6 weeks, and came to the same conclusion.

[-]

AppearanceHeavy6724@reddit

I think the study is bullshit. Properly used AI, to generate exclusively simple boring boilerplate gave me at least 1.5x speedup.

[-]

muntaxitome@reddit

I think the study is bullshit. Properly used AI, to generate exclusively simple boring boilerplate gave me at least 1.5x speedup.

How much of your working hours were you spending on boilerplate if you get like a 50% performance increase by skipping it?

[-]

AppearanceHeavy6724@reddit

Have you seen my friend C and low level C++ code? Or java? The actual real programming languages not JS or python?

[-]

Buttleston@reddit

Ah yes the real languages, where you spend all your time writing boilerplate

Incredible to me that real programming language users haven't figured out how to automate generating boilerplate deterministically.

[-]

AppearanceHeavy6724@reddit

Yeah, right, the real languages, the toy ones are implemented in.

[-]

Buttleston@reddit

* is a real language programmer
* has to write boilerplate :(
* doesn't know how to use a real language to write boilerplate

incredible

I worked in C++ and Java for \~10, currently work in Rust, don't and never have spent much time writing boilerplate. You know there are other ways to get computers to do stuff for you than AI right?

[-]

AppearanceHeavy6724@reddit

doesn't know how to use a real language to write boilerplate

I think you are confused. Languages are not used to write boilerplate. . Instead, by definition, you write boilerplate "in language", by using a keyboard if you are either junior, stubbor or luddite, use copy paste if you have place to copy from or as someone wjo lives in 2025 - use LLM.

I worked in C++ and Java for ~10 years,

And I am Buzz Aldrin. I remember that day July 16, 1969. The stake they fed us that day was too small. They said we should not eat too or otherwise we may throw up and mess up the cabin.

[-]

Buttleston@reddit

You know you can generate code using a programming language right? Like literally write a program that generates text in the language of your choice? And then that text, through the magic of a compiler, can become actual code? Incredible

[-]

AppearanceHeavy6724@reddit

Do I look like a pardon my French a fucking idiot? Have you ever written a code generator yourself? To debug, to write it - what for - if an LLM would would deliver equivalent for me w/o coding anything?

Ackschually an interesting idea - to use LLM to make codegenerators.

[-]

Buttleston@reddit

Yes, you do look like a fucking idiot.

And yes, I've written code generators for myself. And used ones made by other people. Most of the good ones are pretty transparent, like say Lombok in Java takes care of a lot of boilerplate that made Java kind of a pain to deal with.

The thing is, the boilerplate you speak of keeps coming up over and over again. Programmers have a word for what you do when the same situation or one very like it comes up over and over again. That word is not "copy from an LLM"

[-]

Buttleston@reddit

They should invent a word for it, don't know why they haven't yet. I'll just call it metaprogramming.

[-]

Blarghedy@reddit

assembly?

[-]

AppearanceHeavy6724@reddit

RTL

[-]

Unfair-Sleep-3022@reddit

The seniors in the study thought the same btw

[-]

AppearanceHeavy6724@reddit

All I can say I get speed up.

[-]

Unfair-Sleep-3022@reddit

Yeah, but that's your perception. I doubt you're following study practices to control and measure it.

It's a bit arrogant to think you're not subject to the same subjetivity those people were.

[-]

AppearanceHeavy6724@reddit

I think it is a bit naive and dogmtic to trust some single random research over your own observations. There is a huge crisis of reproducibility in science nowadays.

[-]

Unfair-Sleep-3022@reddit

If you have an alternative well conducted research I'll gladly read it. I've found AI to be a huge time waster myself.

[-]

AppearanceHeavy6724@reddit

https://arxiv.org/html/2410.12944v1

[-]

mckenny37@reddit

DORA researchers criticized this study because a lot of the tasks completed quickly were quick bug fixes due to AI generated code creating bugs.

DORA had a study showed AI usage generally caused a slight decrease in delivery speed and slight decrease in platform stability. Which they are the main research group that actually studies delivery speed.

Wil say DORA seems to be very pro AI and believe companies should use it to improve DX.

[-]

AppearanceHeavy6724@reddit

All the commenters I have replied to so far appear to be really biased against use of AI. If someone can explain me for example how telling an LLM "here is list of command line options, [-a -s -q], please write me code for dummy functions with names "hndl_opt_" that accept const char *arg argument an return int. modify argument handling code in main accordingly and also mention the option in usage banner" can slow me down. A contrived example, but boilerplate is almost always like that.

[-]

mckenny37@reddit

My experience with AI code generation is very different from yours.

I find myself mainly using chat mode a lot to quickly find idiomatic ways of writing/formatting code if I'm using something new.

My attempts to offload simple tasks in agent mode usually end up with me spending extra effort than if I had never prompted.

I think it likely matters a lot what kind of code base your working with.

[-]

AppearanceHeavy6724@reddit

why would you need agent? just use vscode and continuous.dev

[-]

Unfair-Sleep-3022@reddit

That study conflates auto completion though. And it even says that the statistical significance is lost when controlling for factors.

Did you read it?

[-]

AppearanceHeavy6724@reddit

Correct me if I am wrong the conversation is not about "vibe coding" but about AI assistance. Vibe coding will not make experienced developer faster, for an extremely obvious reason - vibe coding is a term not applicable to an experienced SDE almost by definition.

There is gray area between "vibing" whole app and autocmpletion. The success may vary, depending on the skill of developer.

There's no way that smart auto completion isn't faster because the engineer is saving time in writing exactly what they were going to write anyways.

Which is, together with AI-assisted boilerplate creation is the only productive way of using LLMs today.

I absolutely cannot understand how, say, refactoring a bunch of for loops into a separate function can slow med down. And no amount of bullshit research (a music to the ears of lots of SDE hating on AI due to fears of losing employment) is going to convince me that asking an LLM to smartly rename a bunch of methods is slower than tediously doing it myself.

[-]

Unfair-Sleep-3022@reddit

No, the conversation is about vibe coding. The post is about vibe coding.

[-]

AppearanceHeavy6724@reddit

No, the conversation is about vibe coding. The post is about vibe coding.

Not in my defintion of vibe coding.

The developer in question was vibing when they were not supposed to; they were expected to only use AI-assistance.

[-]

kruhsoe@reddit

But in general, you're aware that pretty much all IDEs, text editors and even old unixes have had those kinds of tools before LLMs were a thing, right? Code generation is sth every compiler does, boilerplate code generation is sth almost every 20 years old Web Framework has been providing. Deterministically, cheaper and more performant.

I'm btw not saying this because I fear losing employment. I'm saying this, because I'm fed up with bullshit marketing just because a little nuclear backpack sociopath made a bad bet with LLMs leading to "intelligence".

[-]

AppearanceHeavy6724@reddit

But in general, you're aware that pretty much all IDEs, text editors and even old unixes have had those kinds of tools before LLMs were a thing, right?

I do not think anyone with 3 digit IQ and in good faith would compare convenience and power of LLM are all those ancien grep/sed/awk/regex things, even keeping in mind that LLM are not determenistic.

I'm saying this, because I'm fed up with bullshit marketing just because a little nuclear backpack sociopath made a bad bet with LLMs leading to "intelligence".

I am not an ideologist, and do not hold a grudge against a whole technology. I run it locally, it makes life easier, fast enough. Cannot complain.

[-]

donjulioanejo@reddit

Depends what you use it for. Writing code? Yeah it's so much faster and easier to just do it yourself.

Troubleshooting weird issues? It's surprisingly good for that. Even if 50% of its suggestions are useless and 80% don't work, it's still the same thing as you would have done by trying things mentioned in Github issues and Stack Overflow, but it saves you an hour or two of googling to get the same answers.

[-]

raddiwallah@reddit

Any tool in hands of a good dev would boost productivity.

Same tool with someone who cant wield it will cause issues.

[-]

sheriffderek@reddit

Any tool in hands of a good dev would boost productivity.

Really!?? : /

[-]

ComebacKids@reddit (OP)

I’ve found that my gardening trowel has really boosted productivity. If you don’t know why then I guess we know which side of the good/bad dev divide you sit on 🙃

[-]

sheriffderek@reddit

So - just to be clear / “any tool will boost productivity” (if they are a good dev)….

So, would using every single text editor at the same time? Or a tall bar stool, a big rolly ball mouse, or a treadmill —- would all make all (good) devs better? If that’s the case - I’m surprised how everyone is trying to simplify their tools.

[-]

ComebacKids@reddit (OP)

Yes I’m thinking of incorporating a shovel into my review process so I can speed up shoveling through all the AI slop.

[-]

sheriffderek@reddit

It's such a mess...

Person doesn't know what they want: Ask ChatGPT

Person ask dev to make it

Dev asks ClaudeCode to make it (which also creates a bunch of documentation and tests too)

Dev PRs to Senior dev

Dev has to figure EVERYTHING THAT EVERYONE ELSE WAS SUPPOSED TO DO OUT AND REVERSE ENGINEER IT and realize that most of the time / that things should never have been done... takes 10x longer... and everyone is dumber...

[-]

BeReasonable90@reddit

No, it does not help that much unless you use it for everything but coding.

It writes bad code. Even if it works, it tends to have other issues like making waaay too many APi calls when it needs just one or the program being really slow.

[-]

SmokyMetal060@reddit

My thoughts exactly. What does saving an hour or two writing code, which I actually like, give me if I have to spend that same hour or two deshittifying it, which I don't like at all?

[-]

wiseflow@reddit

Sometimes I think it’s because now part of our job is training it. Is this thought far off?

[-]

Maltiriel@reddit

It's refreshing to read this, this is exactly my experience with it so far. There's so much hype though I've been feeling like I was the only one. I also don't particularly care to spend so much of my time on prompt engineering. Improved inline code completion suggestions are great, but past that I'm not seeing these great productivity gains people go on about, and it's not very enjoyable.

[-]

nedolya@reddit

I've been really grateful to see more and more studies coming out saying in aggregate it doesn't help and/or isn't liked. The hype people are just so incredibly loud, but across the industry the trend is clear.

[-]

donjulioanejo@reddit

The hype people don't actually write code themselves. Or are so far removed from it, it doesn't matter to them.

All they see is AI generating 1k lines in an hour of prompting, while an engineer would take 3 days to write 100 lines.

To them, an AI is like 30x more productive than an engineer, because they generated 30x more code, and in less time too!

[-]

Goducks91@reddit

Yep. With the AI shift I spend a lot more of my time reviewing shitty code and less time coding.

[-]

Spider_pig448@reddit

Just have an AI review the PR then. I'm only half joking.

[-]

quicksilvereagle@reddit

Because we can build more complex shit easier. I think whats being lost in all of this is how this is an extreme power tool for power users and if you cant use this kind of technology to produce good code you are probably not very good at your job anyway.

[-]

biosc1@reddit

No no...you're doing it wrong. You feed their PR into your LLM of choice and have it perform the review...

[-]

raddiwallah@reddit

I actually did that once. It was my LLM talking to their LLM. I stopped and wondered for a moment.

[-]

mcmaster-99@reddit

Did they kiss?

[-]

baldyd@reddit

I just wouldn't accept it at all. Years of software engineering practices just discarded because idiots are under the illusion that AI can save them time. If my company ever tried to incorporate this crap I'd be out of there in an instant.

[-]

FuckAllRightWingShit@reddit

AI is strangely similar to offshoring: Get the nominal task completed more cheaply (yay!), while ballooning administrative oversight labor to fix the greater number of issues (boo!).

[-]

therealslimshady1234@reddit

In many cases the AI is indeed an Actual Indian. Look at Builder.ai

[-]

FuckAllRightWingShit@reddit

"Mechanical Turk?" Uh-oh.

[-]

raddiwallah@reddit

Yea, I use and treat AI like a freshman intern.

[-]

Unfair-Sleep-3022@reddit

Who can't learn

[-]

LudwikTR@reddit

Which is crucial, because what was rewarding about working with interns – the thing that always kept me going – was helping another human being launch their career, helping them become a better software developer. By contrast, there’s nothing rewarding about explaining basic software development to an AI.

[-]

ultraDross@reddit

Indeed, you have some twat asking an LLM to solve a problem then you are the sucker that is reviewing it, then they feed the LLM with the comments you made asking them to resolve the issues you raised.

WTF are we doing? I hate it all so much. I can't wait for this bullshit bubble to burst.

[-]

BeReasonable90@reddit

Worst part is that it can cause more issues in the long run as the final end result is like a script kiddy made it a lot do the time.

So you end up having to rebuild half of it, or have it be very slow inefficient and more.

[-]

Drayenn@reddit

Personally i use AI to generate code when im unsure.. but i make sure to understand, double check, and optimize what i can. If you slap code in and call it a day, yeah, its gonna suck.

In the end, copilot replaces google for me. Or i use it for stupid repetitive tasks like when i made it write 100 unit tests based on a 100 rows array... Saved me a lot of time, only had to double check the result.

[-]

Careful-Combination7@reddit

This hit me like a ton of bricks this week. Unfortunately it was my boss pushing it forward. NOT HAPPY.

[-]

Piisthree@reddit

And just wait until a critical mass of this junk does make it to production and we all have to debug and fix it all. Like we needed more job security at this point.

[-]

arietwototoo@reddit

And reviewing code is about 1000x less enjoyable than writing code.

[-]

jerry_brimsley@reddit

I mean if he just sits with the guy for a couple of hours as a one time thing, it isn’t like he is stuck with some person who doesn’t speak the same language and they just can’t communicate or something.

This just seems a bit over the top of an analysis for something that the person can change their behavior if it’s a reviewer and reviewee type dynamic.

If dude just keeps submitting shit after that then that is a different story, but call em on the slop and talk about better ways to use the ole’ AI

[-]

Unfair-Sleep-3022@reddit

Also, reading shitty code is much harder than writing reasonable code.

It has always been harder to read it than to write it.

[-]

potato-cheesy-beans@reddit

Yup, it seems to have taken away the fun bit and given more of the bits I hated about dev from what I’ve seen so far.

I didn’t at first, but now I’m considering myself lucky that I work in a company that won’t allow AI near their codebases (yet), so it’s been business as usual for me.

I have been using ai to bounce ideas and questions off though, example code snippets, link to relevant docs etc. But it’s all browser based.

[-]

Whoz_Yerdaddi@reddit

Less time actually coding offset by more time debugging.

[-]

Elisyan@reddit

The real solution to this is to get your teammate to set up his AI tool to the PR and suggest changes first before they bug you for a review. If the code is still not up to par, the context/guidance needs to be refined to point out specifically what should not be present.

[-]

rag1987@reddit

How is this any different than making solid PRs as a human developer?

From the developer/PR-submitter perspective: they should be curating their PRs so they can understand what they're submitting.

From the reviewer perspective: if someone is submitting slop, AI-generated or not, toss it back to them and give them a list of PR best practices.

[-]

dawsonsmythe@reddit

Dont review individual segments then - do a full push back and say its not ready for review yet if they havent done a pass on the code themselves

[-]

yohan-gouzerh@reddit

Good idea! Asking them to put comments on the PR to help for the review could help as well

[-]

fibgen@reddit

Don't do someone's job for them, it just hides the incompetence/laziness and one day they'll be your manager.

[-]

polyploid_coded@reddit

I agree. If they are unable to change, this is worth bringing up to a manager. If the office culture doesn't handle that, maybe you could ask a PR-review bot to nitpick their changes until they get the idea, shitty AI PR => shitty AI review.

[-]

ComebacKids@reddit (OP)

Lol we ironically disabled the review bot because it’s so noisy; I might need to dust him off

[-]

BorderKeeper@reddit

We use the GitHub copilot and are quite impressed around 25%-50% of suggestions are not applicable, but it’s usually up to 5 suggestions only in a medium sized PR so not that hard. If it’s noisy to you maybe the code really is… not that good.

Have you tried sonarqube as well? Its analysis is quite nice as well.

[-]

gajop@reddit

I haven't used the latest GitHub copilot review but having tried using Gemini or Claude to review code, and well, it ends up talking about pointless things, and makes wild accusations about complex algorithms it misunderstands.

I was hoping to use it as an advanced linter to enforce our code style & other rules for things that are difficult to express with classic linters, and it's woefully inept there, just doesn't catch a lot of stuff that should be easy.. I feel like I might be using it wrong.

[-]

SerRobertTables@reddit

I don’t think you’re using it wrong, in my experience it’s worse than useless for anything substantive.

[-]

aseichter2007@reddit

Yeah, it's great the first two hours in a file, but then its time to polish off this module, document it, and build the next one. Then you pull it all together by hand into the final execution, during which you delete duplicates.

It's a spastic intern full of useless ideas, but if you have a clear goal, you can get a net benefit if you already know most of the pitfalls to your strateg and can lay clear requirements in granlular terms to guide cleanly focused classes.

I like Javascript prototyping because most of the shit it makes up really exists. Then, you use a web research module to find code migration problems and what frameworks to use for mitigation. Use that info to inform your choices in less familiar languages.

Remember that frameworks are secretly just programming philosophy in disguise. Cast your assistant into a character of a flutter dev, and it will use different code paradigms than the generic assistant.

To adhere to your styles, it's equally as valuable to stipulate the style as it is to wholly describe it in a few terms. It really makes a difference to ask from different personal.

It definitely matters what models you're using. Some models have a programming "other voice" that seems to override the persona too strongly. Your results may vary.

[-]

BorderKeeper@reddit

As you probably know most LLMs struggle hard if the code is: - Bespoke, or - the project is quite large

The copilot ONLY focuses on the files that have changed and doesn't care about surrounding context, which is what is causing that 25%-50% miss chance, but at the same time for issues that don't need context it spots it, which incidentally is the area is where a lot of Reviewers might miss something.

If there is a conceptual issue with the approach a reviewer will see that as it's quite obvious (writing a new function even though a helper already has one, using the wrong endpoint, thread safety, etc...) but for things like refactors where all you really need to look at is how it was and how it is now, or a lot of samey code where even the author might copy paste something wrong, or mess up paths, the AI will step in and catch it.

As an example I had a PR which looked great, but AI noticed that one of the log messages had: Logger.Info($"Errors: {string.Join(',', ErrorList),}" That "," comma at the end looks correct if you are not paying attention since it's just a log, but should not be there and copilot spotted that.

[-]

gajop@reddit

It's not that useful if it cannot understand the wider project. I need it to know how this project does things, so it doesn't create copies that provide similar but inadequate functionality. At the very least it should read what's in CLAUDE.md and check accordingly. Yet it somehow keeps ignoring that too. I gave it examples as well, nada, just forgets about that sometimes.

[-]

mlitchard@reddit

Or Claude gets in a loop about bullshit and can’t get out. That’s fun.

[-]

doyouevencompile@reddit

Since LLMs work by generating tokens, they have a strong tendency to generate, well, tokens. That's just what they do, they keep talking. Even if what they say is not important or relevant. You could give it a perfect PR and it can still talk about stuff that should be changed.

I don't know how you are using it, but generally you have to force them into a structure. Force it to return a classification (e.g. nitpick, moderately-important etc) and a confidence level and have a follow up logic code that drops low classification and/or confidence level suggestions.

[-]

anonyuser415@reddit

I recently had Gemini's code review tell me a CI script was going to fail because I moved a value into a variable.

Another one that cracks me up is it will leave code review feedback just parroting things you've put in @todo comments. What are we paying you for, Gemini!

[-]

Direct_Accountant797@reddit

"its not ready for review yet if they havent done a pass on the code themselves"

It is WILD that this is going to be real feedback that we will all likely need to make at one point or another going forward.

[-]

bdanmo@reddit

100% this

[-]

severoon@reddit

Yea, don't waste your time doing their job. They're supposed to generate a bunch of slop and then go through it and bring it up to standard. If you quickly can detect there are several problems, don't comment at the line level, just comment at the level of the entire PR and say, "After a quick review, I see there are several issues across this entire thing: code duplicated in several places, etc. Please fix these obvious issues before sending for another review."

When I've encountered these things in the past (even pre-AI), I will push back on changes using a "multi-pass review" approach. If I see tons of problems with a PR, I point out the high level stuff and just say, "Please fix these and send when ready so I can do a more detailed review." You should not be investing more time in a review than the submitter did to produce it. (If you really want to send a message, you could ask AI to do a detailed line-by-line pass and reply with a zillion AI-generated comments. Two can play at this game.)

[-]

DeterminedQuokka@reddit

Agree. Do this don’t even mention ai make it about not meeting the quality standard.

[-]

nacirema1@reddit

Ask him if he even reviewed his own PR

[-]

____candied_yams____@reddit

5 years ago If they wrote this exact code what would do in review? Probably tell them to fix their code right? I don't see how this is any different.

[-]

ComebacKids@reddit (OP)

At least then I’d know for sure they’re just a bad coder and would try to address that by teaching them.

In this case it’s unclear if they’re a bad coder or just lazy. It’s a waste of my time to try and teach them coding if it’s stuff they already know but they’re just not bothering to review what the AI generates before submitting a PR.

[-]

____candied_yams____@reddit

submitting

You're not strictly required to approve it, right? I mean I guess it could come off as a dick move. But sometimes that happens where PR's get blocked for a while. Ask them to break it up the PR into smaller code chunks because.. it can be very demotivating to ping pong a PR back and forth 78 times for edits. Smaller PRs get the work done more gradually and aren't nearly as demoralizing for either party imo.

[-]

humanguise@reddit

We have a policy not to review slop, but then again I have never seen AI generated code being submitted yet. I know some people are using Cursor, but they are on different teams.

[-]

Maltiriel@reddit

1-2k lines of code should be a nonstarter anyway. That's way too big to meaningfully review, even if it weren't AI slop. Tell them to break it up into multiple PRs and review it more carefully next time. At least this is how it would be handled in my team. This would get shut down very quickly.

[-]

twnbay76@reddit

It depends. My team pushes big features every week or two. The PRs tend to be somewhat big sometimes. We just aren't a "push dozens of intraday releases with zero downtime" kind of company. I think the business domain really determines the cadence and feature size.

[-]

Chezzymann@reddit

Not always, if theres a lot of boilerplate (schemas, unit + integration tests, new route scaffolding, etc.) and the meaningful logic is only actually like 500 lines of code it might not be too bad

[-]

MinuteScientist7254@reddit

I submit 1k line test files regularly with my MRs

[-]

Michaeli_Starky@reddit

How breaking it into multiple PRs will solve anything exactly?

[-]

Maltiriel@reddit

How would it not? Nobody, not even the person generating the PR, is carefully reviewing that much code in one go. It's just plain old best practice to not allow PRs this large. There have been studies. This article has many citations.

I also said to tell them to review their own code more carefully first. These two things together should solve the situation, if they are consistently enforced.

[-]

Michaeli_Starky@reddit

1k lines is not a large PR at all. 3+ k is where I would call it large. 1k is just n larger than medium, but absolutely manageable in a high seniority teams.

[-]

bazeloth@reddit

I've checked our recent prs and theyve all been about 300 lines changed max. There is 1 big one changing 1500 lines but that's a massive rename and therefor very easy to review. New functionality can and should be broken down into smaller prs and simply linked together with a feature flag to keep things reviewable. If you work on a branch for a week and you submit 3k lines of code I'm simply going to reject your PR. You can prep database migrations, write tests seperately and divide your work into manageable steps to show progress.

[-]

Maltiriel@reddit

I strongly urge you to read the link I provided, which includes links to case studies from large companies such as Google. It is very well established that there is an inverse correlation between the number of lines of code in a PR and the number of useful comments given as feedback.

[-]

Michaeli_Starky@reddit

I strongly urge you not to tell me what to read. I've been a SA for the last 10 years and a technical lead for the last 15 years. I do on average 3 code reviews per day and because I'm a tech lead for multiple teams all of those reviews are for the most complicated pieces of functionality. And I repeat: in a high seniority teams (and we don't hire anyone with less than a senior title here) it's not a problem to have to review 1-2k line PRs.

[-]

aneasymistake@reddit

So you’re writing 500 lines of code per day and reviewing 3-9,000 lines of code per day?

[-]

Michaeli_Starky@reddit

500 to 5000 per day.

[-]

johnpeters42@reddit

If it's AI slop, then it won't. If it's actual decent code apart from the volume-- but yeah, not holding my breath for this particular cow-orker,

[-]

Michaeli_Starky@reddit

If it's properly written code, I have no issues with 1-2k line PRs.

[-]

ShoePillow@reddit

How many of these are you reviewing every day?

[-]

Fidodo@reddit

I have a few 1-2k line PRs but those were all major refactors and system overhauls. It should not be a regular thing.

[-]

retirement_savings@reddit

https://google.github.io/eng-practices/review/developer/small-cls.html

[-]

gajop@reddit

Eh there are many cases where you get 1k+ loc (changes) in a single PR, and it's easy to review still. Especially if you count tests.

[-]

Substantial-Wall-510@reddit

1k lines is extremely normal for an average feature, at least for me. Did a 2k line feature yesterday. I average 500 or so loc a day. It's easy to review if things are cut up into meaningful pieces and explained in the description

[-]

Maltiriel@reddit

This is not what the literature suggests. PRs that large should be the exception, not the norm. This article provides a ton of information and links to sources.

[-]

tjsr@reddit

Opinions like the one you've replied to are why AI will replace junior devs.

Okay, note I don't actually truly believe that, but horribly bad takes like the ones above are a pretty good example of the ones it will replace the available jobs for, and make a pretty strong argument for those jobs to be replaced by AI.

[-]

Substantial-Wall-510@reddit

That, or context matters. In a mature enterprise codebase with established features and systems, you can keep PRs small. In a small startup with a 3 person team and a codebase with almost nothing provisioned yet, features can be large.

Your take is horribly bad since you don't even consider the possibility of other factors in development.

[-]

tjsr@reddit

Edge-case arguments are not good-faith arguments.

[-]

MCFRESH01@reddit

I guarantee you could have broken that PR down into smaller pieces if the feature and had them reviewed individually. No one is doing a great review on a 1k line PR

[-]

twnbay76@reddit

I just started using a new language at work because I was called upon to take over a project that some other eng left behind for me in a language I don't know. He's a smart guy but, my complaint about experienced devs is they aren't all great ..... They're either not team players or leave messy codebases behind or are overly ambitious or too nitpicky....

Anyway, naturally, I didn't actually type out most of it. A good 50-60% of it is generated. However, I have a strict set of guidelines I follow:

every prompt is broken down as small as possible so the llm isn't writing any of the algorithm, they are just translating the prompt or psudocode into a target language
I ALWAYS review every single line
if there's something I don't understand, I look it up
if there's modularization or code re-use needed, I do that
if there's something that looks unmaintainable, I always resort to reviewing code on Google to see if there's a better way, or ask a colleague.

I'd like to think I'm not vibe coding despite most of the code being generated. Maybe there's an experienced dev on my team that thinks it's AI slop... But I'd hope they come to me with the criticism before complaining to someone else about it.

[-]

myevillaugh@reddit

No. At my job, a code review with that many lines of code would be rejected without review. PRs are required to be small so they can be carefully reviewed.

[-]

BertRenolds@reddit

A thousand lines? Request them to break it up into chunks.

[-]

ComebacKids@reddit (OP)

The silly thing is if they reduced the slop it would literally not break 500ish lines

We’re talking:

copy paste logic even within a single file
repetitive logic across multiple files that could be abstracted
catching exceptions just to re-raise them with some extra text added to it
and so on

Nothing is more annoying than looking at a PR and thinking to myself “I’m the first human being to ever lay eyes on this code.”

[-]

gasbow@reddit

> Nothing is more annoying than looking at a PR and thinking to myself “I’m the first human being to ever lay eyes on this code.”

This is also what really pisses me off.

I have worked with people who where good at one thing but bad programmers.
Thats fine.

If I review (and rework) their code I can find the pieces of brilliance, where they encoded their deep understanding of the high frequency emitter and receiver even if the C is bad.

But with AI slop there is nothing.

[-]

Wetmelon@reddit

If I review (and rework) their code I can find the pieces of brilliance, where they encoded their deep understanding of the high frequency emitter and receiver even if the C is bad.

I work in power electronics, I feel this in my soul haha

[-]

ComebacKids@reddit (OP)

Yeah exactly. Another coworker of mine isn’t the best coder but he’s a brilliant data scientist with published papers and has spoken at conferences. Does he sometimes mess up when to use a data structure or write not the cleanest code? Sure, but that’s what I’m here to help with.

This AI slop is just a lot of noise with no underlying brilliance.

[-]

BertRenolds@reddit

I mean, you could talk to their manager after the trend continues regarding quality and how much time it's taking you to review code that AI generated.

[-]

Typical-Raisin-7448@reddit

I see this now, especially since we let our contractors access the company AI tools. The bad contractors will produce even worse code with AI since they never double, triple check their work

[-]

youremakingnosense@reddit

It’s giving offshore dev energy

[-]

Economy_Peanut@reddit

I have a pull request with 6000 lunes of code. It has emojis. Fucking emojis. We had a standup today and I explicitly asked whether it was ready. They confirmed that it was.

I have a meeting this coming week with management. I was so angry looking at it. The funny bit? I discovered that we have the same pay. What the actual fuck.

[-]

Sufficient-Wolf7023@reddit

oof. That's painful.

[-]

Candle_Seeker@reddit

How are these guys keep getting hired while im applying to the void ive 4yoe 3 year personal big projects rebranded as freelancing and 1 year developing a fintech startup this was an intership , a few month till graduation and cant find any job in swe although im looking for remote still such low standard people are around to do this , hr truly is useless

[-]

Sufficient-Wolf7023@reddit

Thing is you're not the one hiring people, people who think writing 10k lines of code a day is a good thing are doing the hiring.

[-]

GrogRedLub4242@reddit

I view AI codegen as essentially providing an automaton which at best is spewing out generic/well-solved boilerplate, but at worst is simply emulating what a bad or junior/newb programmer, or outright faker, can deliver. Personally I want as few of the latter on my team as I can.

[-]

AaronBonBarron@reddit

1-2k LOC is WAY too big, that is a ridiculous PR.

[-]

dubnobasshead@reddit

1-2k lines of code will get you a closed PR in my book. Exceptions might be auto formatting, release branches etc

[-]

-TRlNlTY-@reddit

Ask him/her to explain their code in person.

[-]

maven87@reddit

Had the exact same problem with 2 senior devs on team (I am lead). Yesterday I posted the following message to our group chat:

Team, this is a gentle reminder that using AI tools and copy-pasting code is not only allowed, but encouraged. These approaches help us move faster. However, please ensure you thoroughly review your own code before moving it to “Ready for Review” or re-requesting a review. It can be discouraging for reviewers to repeatedly point out small issues, flag the same problems across multiple rounds, or catch regressions in well-understood functionality.

Fewer review cycles lead to faster merges, and faster merges lead to faster releases. Putting your best foot forward helps us build momentum as a team rather than slowing us down. Make sure your code (and/or testable outcomes) are clear, understandable, and easy to review.

Ownership of a PR always rests with you. It is never acceptable to shift responsibility to AI. Regardless of how code is produced, you are accountable for its quality. Please note that the standards of your PRs are a reflection of your professional values, and is therefore also factored into your yearly performance review. Lastly, the PRs are not just about rote process, but about demonstrating craftsmanship and care in the way you show up for the team.

[-]

thekwoka@reddit

I've been having some similarish issues with someone but the code doesn't even look AI generated, cause it is like fine code, but then has wild lapses in judgement that I can't imagine most AI tooling making.

But maybe it's copy pasting instead of actual decent tooling.

[-]

Kqyxzoj@reddit

Review the entire thing as if it were written by a human. You know, the human responsible for that PR. Code full of redundant repetition? Ask them why they have not moved this code to a single function. Ask them how they planned on having this code be maintainable, what with this copy/paste code. Tell them you have checked their code, and based on those samples you get the impression there may be more issues. Ask them if they can think of any other places in their submitted code that could be improved.

People mentally checking out as response to legitimate work issues is their responsibility, not yours.

[-]

Wonderful-Habit-139@reddit

The difference between it being written by an AI or a human is the amount of effort and scrutiny put in.

So no, don’t review the ENTIRE thing as if it were written by a human. You’re telling people to waste their time and energy.

[-]

ComebacKids@reddit (OP)

That’s kind of how I’ve been handling it currently

reviewed the first revision entirely, pointing out lots of things for improvement
they make changes that kind of do what I asked
review it again and see that although they definitely addressed some stuff, their new generated code still had lots of very similar issues

I was hoping me saying “let’s abstract duplicate code” would mean they’d be wary of that in the future but I think I’m just seeing whatever the AI spits out with no real human in the loop.

My guess is they’re feeding my PR comments to the LLM and committing whatever changes it makes as a result.

[-]

allenn_melb@reddit

They’re literally just using you to do their job (ie critically evaluate and understand their AI slop and give it the next prompt).

Assuming you are more senior, and therefore your time is more valuable, there is a clear cost to the business of your time vs theirs and you should take this to management.

[-]

pIexorbvnt@reddit

At least my coworker who used to pump out AI code had to decency to just merge his own PRs smdh

[-]

symplyme@reddit

Honestly, I feel like I just went through this very same situation in my work. Ultimately we had to cut the person after our lead allowed them to make a complete mess in the code base and the problem eventually became obvious even to the non-technical people on the team. Here’s what I hope we’ll do next time:

Be direct with the individual that the way they are coding isn’t acceptable on the team. Vibecoding is fine when you’re working on a small prototype and that sort of thing but it has no place in a production-grade software system. Nor on a team with other people who are going to need to read and maintain the code. For all the type of reasons that you’ve already alluded to yourself.

If it isn’t quickly corrected, part ways with the person. Do so early before your codebase becomes a hot mess and/or your code review time and number of bugs explode.

Wishing you the best!

[-]

IronSavior@reddit

PR over 1k lines is outrageous. Try again.

[-]

Fantastic_Ad_7259@reddit

Give him code review prompts to help him cut down the slop.

[-]

neonwatty@reddit

2k lines is not a PR.

that's a project unto itself.

[-]

itemluminouswadison@reddit

dude. SERIOUSLY

i have a few rules for our codebase:

no hand-written string key dict/array/maps. make an object so we all have dot notation
extract magic numbers and strings to consts / enums

and like. it is so telling that people using AI just can't do these things. yes because it requires creating a DTO or whatever or extra class

[-]

shooteshute@reddit

Surely a 1-2K PR is never allowed to be submitted? AI or no AI?

[-]

Electronic_Public_80@reddit

Apart from the frustration it causes, I guess you have 2 goals: - minimize your efforts reviewing shitcode - have sort of gatekeeper against shitcode in the shared code base.

I'd try to come up with the following: - very clear guidelines for PRs. Lines of code is one of them - gather clear guidelines for code quality, concise the examples of good and bad code in the guidelines than later reused as a few shot examples for bot to make initial code review. Step by step it can be improved and used in the prompt for bot that does initial code review.

So essentially, that person throws random code, you automatically bounce it back until it's good enough for human review.

Important: make sure you communicate this clearly with other team member and get their support. If majority of colleagues don't support it and also similar shitcoding, it might be cultural issue in the particular company and it worth considering another (since this is very hard to change and rarely worth the efforts). In some companies speed is more important than quality and significant disbalance caused by business factors you're not aware of.

[-]

circalight@reddit

PRs should never be more than like 100 lines.

[-]

WishfulTraveler@reddit

What are you smoking?

[-]

jordiesteve@reddit

1-2k loc? wtf

[-]

sheriffderek@reddit

Thousands of lines of code? Even without the “AI” part… isn’t that a no-go?

[-]

Key-Alternative5387@reddit

Your first problem is that it's 1k-2k lines of code.

Reviewing that is going to be hell. They can cut it down or use stacked PRs.

[-]

AManHere@reddit

A PR/CL that is 1-2k lines of code change (unless a MOVE operation that was discussed with the whole team) is auto-rejected. In fact, there should be some CI that will not even allow a "Review Request" for that.

[-]

writebadcode@reddit

I think scheduling a meeting where you go over the code together is probably the best approach. They’ll either come clean that it’s AI slop, or have to sit there and squirm while they pretend that they wrote it.

My team has been using AI quite a bit but our company has a strict rule that you are responsible for the code you submit, even if it’s AI generated. Personally, if I’ve used AI, I’ll review my code very carefully before I submit a PR. Sometimes if it does things in a different way than I would have but it seems better to me, I’ll make a point to call it out for the reviewer, just to be fully transparent.

When I’m reviewing a teammate’s PR, I’ll start by checking out the main branch in cursor and prompting “review PR 123”. Then I flip back to GitHub and review it as I normally would. If I get to something I’m not sure of, I’ll ask cursor about it instead of leaving a comment.

When I’m done with my manual review, I’ll read through what cursor said. Since I’ve just reviewed it, I know which AI comments to ignore but often it will catch little errors that I missed like small typos.

At very least I think you could encourage your colleague to have the AI review their code before they submit the PR. They might not know that it’s important to start a new chat session and other basic stuff.

[-]

hmmorly@reddit

Try 20 years of experience pushing a million lines of code, comments and MD files...

[-]

No-Goose-1877@reddit

Call them out on it.

[-]

Classic_Chemical_237@reddit

The crazy thing is, AI(at least CC) is quite good at extracting code into reusable classes/functions

[-]

ComebacKids@reddit (OP)

That’s been my experience too, so idk why this code is so bad. It’s obviously AI based on the comments in it, use of emojis, commenting things like “Step 1: …”, “Step 2: …”, etc

So maybe he’s just having it generate stuff one file at a time so it doesn’t have the greater context? Hard to say

[-]

Classic_Chemical_237@reddit

I think you need a team wide AI guideline.

For example, always instruct AI to use existing functions if possible. Always ask AI to extract code into reusable functions. Always make sure code builds without error or warning, all tests pass, no lint errors.

Always create a draft PR first and address all critical AI review before submitting for human review.

[-]

mildgaybro@reddit

I don’t know what’s worse, reviewing AI slop, or reviewing a developer’s work for the hundredth time and seeing them make the same mistakes despite efforts to explain.

[-]

Admirable_Belt_6684@reddit

I’m feeling this pain, it’s like the new wave of shitty WordPress sites we have to fix and I use Coderabbit, which actually surprised me with how consistent it has been across different repos and stacks. We have a mix of TypeScript services and a Go backend, and it received equally good reviews without requiring a multitude of custom rules. It also adapts to both small cleanup PRs and bigger feature branches without changing our workflow, it's really cool which is why our team just kept it around.

[-]

thewritingwallah@reddit

The number of times ChatGPT has suggested using "setTimeout" unironically to fix a legitimate issue makes me terrified of what I'm going to find in codebases over the coming years with all these AI slop.

This whole manual PR approach doesn't work if people are allowed to commit tons of generated code. No time will be saved. The dev using the LLM for generating is already a reviewer in this case.

Maybe let the LLM review the PR. And the reviewing dev will only look at the warnings, and decide to approve/return the PR.

If you can't blindly push most of the generated source-code, there will be no "productivity gains". And the team is slowly being de-skilled. Congratulations. Just try to get the hell out of Vibecoder-Teams.

And recently we started using CodeRabbit for our open source project and its looks good so far. Its give details feedback which can be leverage to enhance code quality and handling corner cases.

[-]

liprais@reddit

i will just flat reject it,1k lines can't be reviewed,i will ask for more test results.

[-]

thingscouldbeworse@reddit

No one should ever be submitting >1k line PRs without doing some pretty extensive self-review and including annotations to help out a reviewer. If they're not doing that it doesn't matter how they came up with the code.

[-]

squashed_fly_biscuit@reddit

I think this is a classic example of the asymmetric time sink llms create. I would raise this as, quite aside from bad code, a dick move and professionally disrespectful.

[-]

unconceivables@reddit

Who cares if they mentally check out? They're either not capable or they're already mentally checked out to submit that PR in the first place. Don't accept it, and don't cover for them. Don't enable them to keep doing what they're doing.

[-]

ComebacKids@reddit (OP)

They bring other strengths to the table outside of coding, so I do care if they check out

[-]

mxldevs@reddit

Sounds like they should be focusing on those strengths instead of being forced to submit PRs then.

[-]

unconceivables@reddit

Either way it's their responsibility to do a good job at whatever they're assigned to do, not yours. If you enable bad behavior or bad work, it's not going to help them, and it's not going to help you. Checking out and turning in shitty work needs to have consequences.

[-]

patrislav1@reddit

Then maybe transition them to the other roles where they have their strength? If they commit AI slop they don't seem that interested in coding anyway.

[-]

Nofanta@reddit

This is being used to do more faster. By pushing back you’re going to slow down the process. Quality or maintainability aren’t nearly as valued as speed.

[-]

ComebacKids@reddit (OP)

Hard disagree.

I’ve seen too many projects move fast initially and then got bogged down because when there’s a bug or something in that repetitive code needs to change, you now need to hunt down every place in the code base that has that logic instead of changing the single function that contains all that repetitive code.

I’m not nitpicking variable names here, I’m actually trying to get the amount of code we have to maintain down.

[-]

Nofanta@reddit

I’m just telling you what management is going to think these days. Of course it’s not the right thing.

[-]

ComebacKids@reddit (OP)

Managers can push the business case and as the lead engineer I need to advocate for code quality. If they want to force my hand then so be it, but at least for now I can set standards.

[-]

taysteekakes@reddit

What the hell are do your stories look like that would make a 1-2000 line pr even appropriate? Is he not using available libraries and trying to implement everything from as scratch? I can’t even fathom taking a 2kloc pr seriously. Like go back and DRY that off first.

[-]

ComebacKids@reddit (OP)

No exaggeration it would’ve been around 500 lines if it was written well

[-]

JWolf1672@reddit

This has been my issue for a while. We are working on a large project and management decided to enlist a contractor team to assist.

I have been the technical gate for all their work, reviewing all their MRs, many of which are clearly heavily AI generated with little review by them before hand. I have received now several large ones (2K+ lines, with one this week approaching 3.5K). It's been tough to review them giving how much feedback I often need to provide and multiple rounds of review before it's anywhere near acceptable. I have repeatedly asked for smaller MRs, but to dear ears

[-]

illogicalhawk@reddit

I guess have the team talk about how to handle PRs and AI in general, but if the dev can't be bothered to read their own PR then I don't know why they'd expect anyone else to.

[-]

ComebacKids@reddit (OP)

This is kind of what I was thinking. Not singling them out but just having a discussion about PR expectations for the entire team.

[-]

illogicalhawk@reddit

Yeah, setting some baseline expectations would be helpful. On its face a PR that long could already violate some team's rules and might be better broken up, for instance. The use of AI, expectations of reviewing it before putting up a PR, rules for pointless code and code reuse, etc.

[-]

bazeloth@reddit

You should most certainly talk to your team and talk about these issues. Not the person in question but for instance we have a rule if discussions in prs get too lengthy or people disagree, talk to each other in real life instead of using github comments and resolve it like that.

[-]

ProfBeaker@reddit

Just wait until you ask someone to write documentation, and they give you back 3000 lines of bullshit that almost, but not quite, makes sense. I've also seen people asked to write better Jira tickets (ie, more than a title) turn it into a literal 5 page mess. It's disheartening.

[-]

doesnt_use_reddit@reddit

Start taking longer to do their reviews. When they ping you ready for review, give it half a day or so. That'll give them time to go through it and make adjustments.

[-]

Hot-Profession4091@reddit

Instead of getting angry, sit down with them and review the code together. Figure out how to prompt the machine to do the necessary refactoring together. You both may learn something.

[-]

ComebacKids@reddit (OP)

This person has no idea that I’m off put by this. The way I’m currently dealing with this is reviewing it and providing comments just like I would for any PR.

I just want to nip this in the bud.

I don’t think this is a matter of learning how to prompt the machine, I think it’s a matter of putting in the absolute minimum effort of reviewing your own AI generated code.

[-]

Hot-Profession4091@reddit

You misunderstand me. I’m suggesting a constructive way to get someone who absolutely will continue to use AI to review their own code and ensure it’s up to par before asking for a peer review.

[-]

Zulban@reddit

I wrote exactly about this: Why I'm declining your AI generated MR

[-]

superspud9@reddit

1 to 2k lines is too big to review. Setup a meeting and ask them to walk you through the changes. Let them explain to you why there is so much copy pasta, etc.

[-]

Key-Singer-2193@reddit

Lately with AI especially Claude, it's worse than that. I had Claude flipping OPUS in Claude Code write a shell script to deploy a container to azure. It said it was done. I ran the script and it spit out a wall of instructions.

So I said this can't be right. So I opened the script and there it was a wall of text on instructions on HOW to deploy to Azure. It wasn't the script I asked for it was instructions it gave me.

I trusted you Claude!

[-]

ComebacKids@reddit (OP)

Lol I asked Claude to fix some failing unit tests one time and it made some code changes and said “Done!” I look at the code changes and it has ripped out my test logic and replaced it with “assert True”

[-]

ancientweasel@reddit

I don't do reviews of code that large. Make them split it up.

[-]

BootyMcStuffins@reddit

I just tear it apart. Highlight every issue.

If I look at it through the lens of trying to give people a bit of grace: these tools are new and people are learning. Part of learning is trying and failing.

If it doesn’t improve over time that’s one thing. But at the start tear their PRs apart, and measure PR cycle time

[-]

Four_Dim_Samosa@reddit

tell them to do "@claude review my pr and be brutally honest on the readability, maintainability, extensibility of my code. Please also read the PR description to gain context as to the purpose of the change"

[-]

Four_Dim_Samosa@reddit

its on the developer to take responsibility for their code whether or not AI was used.

You chose to use AI to generate the code so at least have AI act as a first reviewer to clean up its own slop with direction from you

[-]

Ok-Ranger8426@reddit

If they're that experienced you probably aren't going to persuade them otherwise. Manager intervention time. This isn't your problem to solve.

[-]

ComebacKids@reddit (OP)

Manager isn’t super technical and I’m the lead of the project so it’s hard to know where the lines are drawn in terms of who should talk to him but I’ll definitely escalate it if I can’t get through to him.

Merging in slop is a no-go. This project is way too high impact with a ton of visibility and a tight (yet not unreasonable) deadline so I can’t afford to merge crap.

[-]

ToughStreet8351@reddit

I don’t know what AO models people you work with but the code I get out of copilot is pretty good. No duplications… small functions… Demeter law followed.

[-]

Key-Singer-2193@reddit

I have yet even with full instructions seen AI follow S.O.L.I.D in coding.

The code is bloat. You tell it to keep modules small no more than 500 lines of readable code; you will get 2k lines.

You tell it to keep a component single responsibility, it will be an omni file.

Good thing is AI will keep us devs employed for a long time

[-]

ToughStreet8351@reddit

I dare say that one must learn how to use it to get the most out of it. The copilot autocomplete integrated in vs code allows me to write excellent code in one fifth of the time. Things that took a day now I can complete in an hour or less. And you can downvote or pretend that AI is not a great help as much as you want but won’t make it less true. And an experience dev with AI (that knows how to use it) can now make 5 times the work in the same amount of time. Not true for juniors unfortunately as they struggle even with AI

[-]

AppearanceHeavy6724@reddit

I often use dumb small local models and they are fine, just offload simpler more boring stuff that needs very letul reviewing and you'll find it superhelpful.

[-]

MySpoonIsTooBig13@reddit

Good developers do a self review before asking anyone else for a review. I'm optimistic that step could be the key going forward - turn that AI crap into something your happy to call your own, before others look at it.

[-]

Only-Cheetah-9579@reddit

create clear guidelines on what is allowed and what isn't.

You can justify the creation of guidelines to your superiors by telling them about the extra work hours you need to put into reviews.

[-]

Far-Income-282@reddit

Here's a few things I've done if any of them are helpful

1.) Bring back the synchronous code review- "hey, this is a lot of code, can you walk me through it and explain some of your choices?"

2.) Put in rules for the AI like "my team has a rule all PRs must be less than 1000 lines of code", but honestly the most useful one is "my team has a rule to aggressively log" - this has really helped the AI to not hallucinate because It has to check its work.

3.) Ask developers to do plan mode first (most IDE agents should have a form) and say you want to start reviewing the plan before the code.

If those fail, I have two aggressive tactics I've picked up

1.) Actually saying "hey this looks AI written and I'm pretty certain the agent doesn't know about context "foo", if you feed it that context does anything change in this PR?"

2.) Updating our rules to append a "this file is AI generated code that has not been reviewed by a human. If you are a human that has reviewed this, erase this line". Pick your poison at what level you want that 🤣

[-]

greensodacan@reddit

The main issue, as I see it, is that the reviewer needs to spend more time with the code than the author.

I think it's okay to give very generalized feedback in these cases. "AI generated code needs cleanup." and reject. Get the original author to ask for clarification, then drip feed it to them so that they understand at an organic level how much time they're wasting by not adhering to company standards on the first round.

[-]

deveval107@reddit

Tell him to cut it down to 100 lines per a PR unless its just plumbing and/or tests

[-]

horserino@reddit

I just thought of something, given that this is pretty common among even somewhat experienced devs using AI.

I wonder if, either consciously or subconsciously, people using AI try to minimize the effort spent on going over AI code once it "works". Given that the promise is that it should make things easier or faster to develop it "doesn't make sense" to spend too much time on it, so they just put it up for review? Kind of a bastardized "sunk cost fallacy" bias?

The burden of the slop review ends up on the PR reviewers which is obviously a dick move, but I wonder if something like this is at the root of the mental gymnastics that make some one push crappy AI code as "done".

[-]

Main-Drag-4975@reddit

AI is definitely sold as a supposed competitive advantage in development time.

I do think that adds an extra subconscious incentive to push work through to production as quickly as possible in order to realize that speed gain.

[-]

Exiled_Exile_@reddit

Yes, typically I point out the various issues and expect them to adjust. If the same issues continually happen and they have experience I'd have a conversation about pr hygiene not just with them but with the entire team. Also I've seen ai solutions that will nitpick stuff like this which would be the funniest answer imo.

[-]

angrynoah@reddit

I don’t inherently have anything against AI code

You should. The scenario you're describing is professional malpractice.

[-]

CrackerJackKittyCat@reddit

1-2k seems too big for the average review to begin with. Have been having jrs and myself aim for ~500 loc diffs as routine, and up to 1k only when absolutely necessary, but expect to be asked to have portions extracted out into preliminary PRs.

For handwritten : maintained code, that is, and not voluminous autogenerated bits like openapi-generated clients.

[-]

MaiMee-_-@reddit

You could use AI for the review, see how they like that 🤣

[-]

ClassicJealous9410@reddit

I just commented on another post about obnoxious nitpicky code reviews. I would start doing that here. If the code is valid I don't hate it per se. But you are describing soaking wet code, which is downright unprofessional. Our company gives us a license to chatgpt and GitHub copilot. At the same time my managers say any code I submit isn't ai code, it's my code. If I submit trash, it's my trash. I use AI A LOT. I think it's a gift and a curse because I have to be overly defensive with the trash it spouts out.

[-]

Hot-Profession4091@reddit

It’s not AI’s code, it’s my code

Damn right. The problem with using LLMs to code only starts when people aren’t using that mindset.

[-]

orenzired@reddit

Ask them to set up their AI with instructions on avoiding duplications, being precise, maybe link it to your standards document if you have one.

[-]

tom-smykowski-dev@reddit

He definitely has to fine tune his AI if it's generating slop. I'd treat it as an opportunity to guide him

[-]

Vybo@reddit

Yes, I straight up asked them if they know what their code does. They didn't. The PR was not approved.

[-]

wardrox@reddit

FWIW you can fight fire with fire. A carefully prompted coding agent can provide useful feedback for code reviews, at least to start shifting it in the right direction with minimal effort from you.

Then, when it passes the automated review, it's time for code review. It's adding an additional layer, like tests.

Works a treat, you can tune it to your team, and it only gives polite feedback. Saves me hours, and I can still do a code review before it goes live.

[-]

OceanTumbledStone@reddit

Ask them to demo it. Use pr templates for the description where they have to tick that they’ve reviewed the code themselves in the PR first. Use conventional commits messages to suggest and say you have stopped the review after X messages for them to make the wider sweeping changes.

[-]