Resisting Enslopification

In the utopia of 2026, you press Tab, and two hundred lines of code appear. Just ask Claude or one of its pals to make something for you, they’ve got your back!

Those hundred-ish lines look alright, so you just skim through them, press merge, and move on. You do it again, and again, and at some not-so-distant point, you end up with code where nobody remembers how anything works anymore.

That slow decline is what we call enslopification. Take enshittification (yes, you’re seeing it correctly, it’s on Wikipedia) and point it directly at the codebase.

So, you’re probably here to figure out how to resist enslopification. Good news first: there’s no need to worry! Resisting enslopification doesn’t mean banning AI entirely. After all, the speed is ramping up, and giving up on AI would be silly.

The proper approach to AI is with humans in the loop. They measure the health of the 💩 you merge, so slop is caught early in the PR, not a year down the line.

What Enslopification Looks Like

Writing code by hand is slow. But that can actually be a good thing since slowing down forces you to understand the problem before figuring out a solution.

AI, on the other hand, removes friction in a jiffy. Our brains really don’t like friction, so… AI stonks. Describe the thing in a one liner and get working code. Output is out. Thinking, for the most part, goes down. But the thing is, the mess AI creates doesn’t exactly announce itself on a loudspeaker. No, no, no. It seeps in insidiously.

GitClear has measured that seepage. If you’re into numbers, check out the stats below (if you’re not, move along 😁):

• Across 211M line changes in 2020-2024, copy-paste went from 8.3% to 12.3%.
• Moved lines dropped down from 25% in 2021 to 9.5% in 2024.

In fact, 2024 was the first year on record where copy-paste beat refactoring outright, and duplicated code blocks jumped roughly eightfold.

No need to go for the 2026 follow up, it seems.

Why Eyeballing Isn’t the Way Out

Just review harder, right? Same as thinking harder?

Well, the thing is, AI slop doesn’t really look like slop. Code compiles and reads cleanly. It’s confidently, plausibly almost correct, which is arguably worse than it being obviously broken.

Now add volume. One reviewer, twenty AI-assisted PRs, each one a plausible wall of green diff.

Attention per line drops toward zero.

How to Resist Without Banning the Robots

So, how do you combat this? Not with instructions like “please do not introduce bugs. Do not make mistakes. Mistakes bad”. That’s for sure.

It all comes down to a few boring habits:

• Keep pull requests small: A reviewer will actually read a 200-line PR. A 2,000-liner? Not a chance. That bad boy is getting skimmed.
• Read the f’in diff, daily: Sounds obvious. But trust me, it’s rare. Reading your teammates' code (and your own AI’s) daily spots coupling, duplication, and “wait, why is this here” head-scratchers while they are still easy to fix. GitDailies has a good piece on making this a daily habit.
• Make the model clean up, not just pile on: The default mode of agentic operations is ADD. No removing. Beating the copy-paste reflex is half the battle, so ask the model to refactor, deduplicate, and delete.
• Demand a “why”: Require a sentence per PR explaining intent, not just what has changed. If neither the author nor the model can say why, then you’re in trouble.

When a Little Slop Is Fine

Not every repo needs the full treatment. GitClear has found that heavy AI users ship much more than their past selves. For a weekend prototype, a spike, or a script you’re planning to delete on Friday, slop is a perfectly rational trade-off. Ship the mess, learn the thing, throw it away.

If you do reach for tooling, it’s worth knowing what’s on the market.

If You’re Feeling a Bit Lazy…

You can wire all of this up yourself. Scripts against GitHub’s API, a spreadsheet tracking PR sizes… It works, genuinely. Until you are slammed. Which, let’s face it, is probably every week.

GitDailies comes in clutch, and its PR Metrics and Review Metrics are where it earns its keep. It installs as a read-only GitHub App in about 90 seconds, then turns your existing GitHub activity into daily digests, pull request and DORA metrics, and alerts that fire on the exact slop tells we’ve talked about above (a huge PR, a change to a critical file, or something merged with no review at all).

You get a nudge the morning it happens, not a postmortem next quarter. MongoDB used it to cut PR review times by up to 54% (the case study, in case you want the receipts).

It will not read your code, and it will not stop you from merging slop. It will make sure you see it first, though. As it turns out, that’s most of the fight.

Frequently asked questions

What is enslopification?

Enslopification is the gradual decay of a codebase (or product) as high-volume, low-scrutiny AI-generated code piles up.

Does using AI to write code always create slop?

No. AI is great for boilerplate, scaffolding, and throwaway scripts, and it genuinely raises output. Slop shows up when volume outruns review and refactoring, so the fix lies in better processes, not abstinence.

Which metrics reveal AI slop?

Rising average PR size, collapsing time to merge, PRs merged with little or no review, and a climbing change failure rate (a DORA metric). In-code duplication needs a source-reading tool; the flow signals come from GitHub metadata.

Can I catch slop without letting a tool read my source code?

Mostly, yes. The behavioral tells (PR size, review depth, merge speed, change failure rate) all live in GitHub metadata, which is what GitDailies works from.