The AI Slop Crisis in Code Reviews: When ‘Claude Said So’ Becomes the New ‘It Works on My Machine’
There’s a moment in every engineering manager’s career that makes them question reality. That moment came during a routine code review when they challenged a technical analyst on why a particular approach had been taken. The response? “I don’t know, probably because Claude said so.”
This isn’t an isolated incident. It’s the symptom of a systemic problem that’s quietly undermining the foundation of software engineering: the erosion of developer ownership and accountability in the age of AI-generated code. And it’s spreading across the industry like a bad code smell through a legacy codebase.
The “I Don’t Know, Claude Said So” Epidemic
When developers submit pull requests generated by LLMs without understanding the logic, they’re not just cutting corners. They’re abdicating the core responsibility that defines their role. Your name is on that PR, which means you own it, regardless of whether the code came from a well-trained model, Stack Overflow, or pure unadulterated caffeine-fueled genius.
The problem goes deeper than individual laziness. It represents a fundamental breakdown in the trust relationship between developers, their code, and the teams that depend on them. When team leads challenge PR authors on their changes, the response increasingly sounds like a deflection of responsibility: “I don’t know, Claude suggested it.”
The prevailing sentiment in dev communities is clear: if you can’t explain the code, it doesn’t get approved. Period. Reviewers are rejecting PRs, even clean ones, when authors can’t articulate their reasoning. It’s not about being harsh, it’s about accountability. The developer-deploy relationship is a sacred trust, and AI tools shouldn’t be used as a shield to avoid responsibility for what ships to production.
Beyond Code: The Slop Cascade Effect
The “AI slop” problem isn’t confined to your repo. It’s cascading through the entire technical ecosystem. When we normalize unexamined AI output in code, we shouldn’t be surprised when the same logic failure propagates to other domains.
Consider what’s happening in peer review for machine learning conferences. A recent analysis by Pangram found that 21% of ICLR 2026 reviews, 15,899 reviews, were fully AI-generated, with over half showing some form of AI involvement. The zombie citations are even worse. An audit of 2.5 million biomedical papers by The Lancet found fabricated references rose six-fold in two years, from 1 in 2,828 papers in 2023 to 1 in 277 by early 2026.
The evidence is equally damning in security research. JFrog recently exposed a batch of 54 completely fake CVEs, SQLite “vulnerabilities” with CVSS scores as high as 10.0 that described flaws in functions that didn’t even exist. The GitHub repository behind these claims was traced to likely AI generation. That’s not just annoying, it’s dangerous. Security teams are now forced to spend time chasing hallucinated vulnerabilities instead of real threats.
This is the same pattern as the rise of low-substance AI-generated work output harming productivity we see across the industry: the act of producing output has become decoupled from the act of understanding it.
Why “Prompt Engineering” Is Becoming a Scapegoat
There’s a darker dynamic at play in some organizations. Tech leads are increasingly finding that when they push back on AI slop, the response is an endless loop of excuse-making. “The ‘revolutionary’ AI-driven workflow” quickly becomes a bureaucratic black hole.
One developer described the frustration perfectly: they challenged a team member on an approach, only to watch their review comments get fed directly back into the LLM, which then surfaced a “corrected” version that was just the same hallucination with different comments. The reviewer has become an unpaid prompt engineer for code they never asked to have generated.
This reflects managers promoting unreviewed AI-generated code without understanding the underlying problems. When organizations push AI adoption metrics without instilling responsibility for the output, they’re creating an environment where the tool matures faster than the people using it.
Building Guardrails Without Going Luddite
Let’s be clear: this isn’t an anti-AI screed. AI coding assistants are here to stay, and they can be transformative. Cybersecurity researcher Keith Jones captures the ideal use case: using Claude to generate three different solution approaches, then applying human judgment to select and refine. That’s a partnership. The problem emerges when the partnership becomes a surrender.
Practical guardrails that work:
1. Code review checks
Reviewers need to ask the uncomfortable questions: “Can you walk me through this change?” “What edge cases did you consider?” “What’s the runtime complexity?” If the author can’t answer these, the PR gets rejected, regardless of how many tests pass or how clever the code looks.
2. Testing as a gate
AI slop often comes wrapped in fragile unit tests that test the implementation rather than the behavior. Require property-based tests that validate behavior under random inputs. Require integration tests. Require mutation testing. The effort to produce these keeps LLMs as generators, not architects.
3. Enrichment tools that catch the signs
Open-source tooling is emerging to detect AI slop patterns in code. Some tools detect empty functions, fake documentation, and inflated comments in AI-generated code. The AI-SLOP-Detector project on GitHub even includes telemetry options, disabled by default, for static code and documentation signal analysis. Worth a look for teams looking to automate the first-pass filter.
4. Reject the “output without ownership” mindset
The root of the problem is cultural, not technological. If you can’t explain your code, you shouldn’t be checking it in, regardless of whether Claude, Copilot, or too much espresso generated it.
The Human-in-the-Loop Isn’t Optional
Academic research confirms what experienced devs have been screaming: blind trust in AI systems leads to systemic failures. A recent evolutionary game theory study on AI trust dynamics found something intuitive but important: when monitoring AI outputs is costly, users drift toward unconditional trust, and that’s precisely when systems collapse.
The same pattern we see with developers and Claude plays out at the population level. Safety emerges only when monitoring remains affordable and users stay at least partially vigilant. When you stop verifying, you’re not just putting yourself at risk, you’re creating conditions where corruption becomes evolutionarily stable.
The hard truth is that AI doesn’t reduce the fundamental cost of code review. It shifts it. You’re either doing deep code review at the PR stage, or you’re doing it in production at 3 AM when the monitoring alerts start firing. Given the choice, most of us prefer the former.
The Accountability Mismatch in Modern Development
The incentives in modern development are creating a perfect storm for slop. AI tools generate code faster than humans can review it. Metrics like “PRs merged per developer” and “lines of code shipped” reward quantity over understanding. The growing gap between enterprises rehiring after realizing AI couldn’t replace human judgment shows that we’re all still figuring out where the boundaries are.
The oracle at Worcester Polytechnic Institute put it starkly: “Don’t believe the machine is infallible. That’s when bugs will start working in.” Every developer’s least favorite comment now comes from the LLM with total confidence: “Here’s a solution that will definitely work”, except when it doesn’t.
What Should I Do About This?
At a personal level
Develop a “human-first review” ritual with every AI-generated diff. Run the code. Inspect its behavior. Read the documentation that the model generated and check it against what actually happens. If you can’t explain the change, you don’t understand the change, and you shouldn’t merge the change.
At a team level
Adopt the “no original thought” rule. If a PR author can’t articulate the reasoning behind each logical decision, they haven’t earned the merge. Add a checklist item as a reviewer to the PR process: “The propose… the author comprehends the change.”
At a leadership level
Consider how your metrics reward or penalize the depth of understanding. If you’re celebrating PR velocity while blocking review time, you’re optimizing for the wrong outcome. And be willing to reject the output that can’t be explained, even if it means slowing down the AI-generated juggernaut.
The Verdict
We’re not saying AI coding is wrong. We’re saying the failure mode of trusting AI output without verification is toxic, to codebases, to team culture, and ultimately to careers. As one developer put it: “In this job market, you want to be seen as more than someone that can be replaced by another open window in someone else’s machine.”
AI slop might ship faster, but understanding ships more reliably. And in a world where investor rejection of superficial AI-driven initiatives and ‘AI slop’ is real, the teams that maintain standards will be the ones that build something worth keeping.
The next time someone says “Claude said so”, ask Claude. Then ask them to explain it anyway. If they can’t, reject the PR. This isn’t just about the code. It’s about the discipline that makes software engineering a profession rather than a prompt playground.
Don’t let AI turn your codebase into the digital equivalent of a fast-food drive-through. The review process deserves better than “just wrap it in a bun and ship it.”
