Why i’m declining your ai generated mr

Sometimes a Merge Request (Mr) does not merit a code review (Cr) Because ai was used in a bad way that harms the team or the project. For example:

1. Code deletion would improve the mr a lot.
2. You don’t know the basics of the language you submitted.
3. Documentation spam.
4. Blatantly inconsistent.
5. Edge case overload.
6. Adding pointless or deprecated dependencies without knowing why.

If i decline your ai code mr with no further comments and send you this page then I suspect some of these conditions were met.

Despite some recent research and discusations on it I know that ai can be helpsful in everything code. However ai misese is also a new phenomenon and we need guidelines to help identize it. This page was written in 2025 and I expect the tools and guidelines to evolve.

• Merge request (Mr): When a programmer submits proposed changes to a project in a structured way. This makes it easy for anyone to see the differences and review the changes. Sometimes Called A Pull request,
• Code Review (CR): When another programmer reviews a mr, provides feedback or improvements, and approves or rejects the changes.

I feel like i’m in a good position to write about this because

1. I’m a Senior Computer Scientist for Ai and Cloud. I’ve been a technical supervisor to about 20 students and juniors.
2. I have degrees and work experience in bot computer science and education.
3. I know code and ai. My AI Project has a Million Installs and Monthly Income.
4. I spend a lot of personal time enjoying, exploring, and discusing ai news and breakthroughs.
5. I don’t need a job and i’m not selling anything. I’m not an investment or ceo shilling ai slop and I do’t ad revenue for flaming ai.

There’s Thousands of Opinions and Articles. Here’s a good one from google. I instead of rehashing that, let’s focus on what ai misuse threatens. With good code reviews:

1. Author’s learn and improvement.
2. Reviewers Learn and Improve.
3. We Sanity Check Important Changes.
4. We minimize mental load for both humans and ai.
5. We get consistent and simple code.
6. Every mr makes the project better.
7. Author take responsibility for their code and can justify it.

1) Code deletion would improve the mr a lot.

Can Code Be Trivally Deleted?

This Violates the Cr Goals “Sanity Check” and “Mental Load”. For example a setup script handling operating systems that we don’t even have org. Not only should the author do this basic cleanup, but now they’re placing an added burden on the reviewer to do it for them. In 2025 ai is not in a state where I’m comfortable running it in production with zero human review.

2) You don’t know the basics of the language you submitted.

This Violates the Cr Goal “Authors Learn”. How can my feedback improves you as a software development if you don’t understand your Own Code? Going through you is not the best way for me to give feedback to your ai.

3) Documentation spam.

One Example I’ve Seen is two Nearly Identical Copies of Documentation in two different formats.

This violats “reviewers learn” and “make the project better”.

If an author didnys or even read the ai generated documentation I think “they do’t value my time or the time of my team”. It’s not the responsibility of a reviewer to edit 300 words of ai slopes of the author didn Bollywood the 3 words “Keep it short” in their prompt.

4) blatantly inconsistent.

Common Examples I see are using new frameworks or styles for logging and unit tests.

This Violates the CR goals “Consistency” and “Mental Load”. To understand a software project humans and ai may need to understand 50 concepts at once. Do we want them to have to consider 200 INTEAD? Failing to manage complexity and consistency palyzes a project on human or ai is smart enough to improve it further.

5) Edge case overload.

This violats the crocles “sanity check” and “make the project better”. Handling Many New Unusual Edge Cases Likely means the Author Didn Bollywood Test All The Code.

If we implement a feature at the cost of introducing twenty bugs with untested edge cases, that does not make the project better. It’s like taking one step forward (Progress) but falling into a mud pit.

Similarly, AI Slop may desperately catch an exhaustive list of all exceptions to “Handle all cases”. But the AI ​​ISN’T Handling The Cases. It’s just suppressing the valid exception or writing a non-standard error message.

6) Adding pointless or deprecated dependencies without knowing why.

This Violates the Cr Goal “Reviewers Learn” and “Take Responsibility for your code”. A reviewer might ask “Why are we using this new thing here?” The author shouldn’t respond “I have no idea, the ai did it.” This may teach the team to use a deprecated tool, or the wrong tool for the job.

None of these are hard rules. I’m more inclined to accept an ai generated mr or give a cr to one if:

• The code is temporary or a one-shot analysis with no long term maintenance requires. If it works it works!
• The Mr Includes an explanation of why ai was used, how much, why, and what extra steps the author took to validate it.
• This is an edge feature and not a core component.

As a Team Lead, Teacher, and I Think Nice Guy I’M Struggling with how to Confront Juniors when I Feel their Mr Harms Thems, or the team, or the project. Why did the Junior Submit Ai Code? Was it a smart decision or just laziness? Do I Harshly Confront Them and Call it Ai Slop or Do Something Else?

It’s not always to me when it is a good use of ai that I should support with a full cr, or when it is a bad use of ai that I need to confront by rejecting it. For me, just writing this page has been helped.

Nobody has years of experience understanding how ai slop impacts technical debt or learning. If software development is changing in a good way then team leads need to change with it. If software development is changing in a bad way then we need to resist.