Sometimes a merge request (MR) doesn't 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 discussions on it I know that AI can be helpful in writing code. However AI misuse is also a new phenomenon and we need guidelines to help identify 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 both 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 discussing AI news and breakthroughs.
5. I don't need a job and I'm not selling anything. I'm not an investor or CEO shilling AI slop and I don't get ad revenue for flaming AI.

There's thousands of opinions and articles. Here's a good one from Google. Instead of rehashing that, let's focus on what AI misuse threatens. With good code reviews:

1. Authors learn and improve.
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. Authors take responsibility for their code and can justify it.

1) Code deletion would improve the MR a lot.

Can code be trivially 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 in our 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 improve you as a software developer 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 violates "reviewers learn" and "make the project better".

If an author didn't trim or even read the AI generated documentation I think "they don't value my time or the time of my team". It's not the responsibility of a reviewer to edit 300 words of AI slop because the author didn't write 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 instead? Failing to manage complexity and consistency paralyzes a project once no human or AI is smart enough to improve it further.

5) Edge case overload.

This violates the CR goals "sanity check" and "make the project better". Handling many new unusual edge cases likely means the author didn't 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 requirements. 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 them, 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 clear to me when it's a good use of AI that I should support with a full CR, or when it's a bad use of AI that I need to confront by rejecting it entirely. For me, just writing this page has 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.