Remember ProGuard? Variable names gone, control flow flattened, string constants encrypted. Code unreadable by design. That was obfuscation — deliberate, adversarial, obvious. You knew you didn't understand the code. You acted accordingly.
Now imagine this. You open a pull request. Clean variable names, proper abstractions, tests passing. It looks professional. You approve it. Three weeks later something breaks and nobody on the team can explain why the code works. The author prompted an AI to build it. He understood the spec. He didn't understand the implementation.
Sound familiar?
That code is also unreadable. Not by design — by accident. And that's worse.
The claim
AI-generated code is functionally equivalent to obfuscation.
Not intentional. Not adversarial. But the effect is the same: code enters your repository that resists human comprehension. Obfuscated code looks suspicious. AI slop looks professional. One triggers scrutiny. The other passes code review.
How obfuscation works
Traditional obfuscation increases the cognitive distance between source and intent:
-
Rename variables —
userBalancebecomesa - Flatten control flow — structured logic becomes a switch inside a while loop
-
Encrypt strings —
"connection_timeout"becomesdecrypt(0x4F2A...) - Insert dead code — meaningless branches that confuse the reader
The reader sees valid code but can't extract the purpose.
How AI slop works
AI-generated code increases cognitive distance through different mechanisms, same result:
- Over-abstract — a three-line function becomes a Strategy pattern with an interface, a factory, and two implementations (one never used)
- Defensive boilerplate — null checks on values that can never be null, try-catch around code that can't throw
- Unnecessary indirection — a direct function call becomes a message bus or middleware chain
- Inflate — what a human writes in 40 lines, the AI writes in 200
In practice:
// Human version
async function getUser(id) {
const user = await db.users.findById(id);
if (!user) throw new NotFoundError('User not found');
return user;
}
// AI version
class UserRetrievalService {
constructor(
private readonly repository: IUserRepository,
private readonly validator: IRequestValidator,
private readonly logger: ILogger,
) {}
async execute(request: GetUserRequest): Promise<UserResponse> {
this.logger.debug('UserRetrievalService.execute', { requestId: request.id });
await this.validator.validate(request);
const entity = await this.repository.findOne({
where: { id: request.userId },
relations: ['profile', 'preferences'],
});
if (!entity) {
this.logger.warn('User not found', { userId: request.userId });
throw new EntityNotFoundException('User', request.userId);
}
return UserResponseMapper.toResponse(entity);
}
}
4 lines vs 18. Three injected interfaces, a mapper, a logger nobody asked for. Both do the same thing. Both pass tests. Both get approved. Only one is comprehensible at a glance.
The comparison
| Property | Obfuscated code | AI slop |
|---|---|---|
| Syntactically valid | Yes | Yes |
| Passes tests | Yes | Yes |
| Looks readable | No | Yes |
| Author understands it | Yes (intentional) | Often no |
| Team can safely modify it | No | No |
| Fails code review | Usually | Usually not |
| Detected by tooling | Yes | No |
Last two rows are the problem. Obfuscation is detectable because it looks wrong. Sloppification is invisible because it looks right.
Why this is worse
With obfuscated code you know you don't understand it. You respond appropriately — reverse engineer carefully, or replace entirely.
With AI slop the situation is ambiguous. Code looks fine. Tests pass. PR author says it works. You approve. Months later something breaks and you discover the last three people who touched this code — including you — approved output they didn't understand.
Parnas described this in 1994 as "software aging" — degradation from changes by people who don't understand the design. AI didn't invent this. It industrialized it.
Osmani at Google called it "comprehension debt" earlier this year. Unlike regular technical debt — which announces itself through slow builds and angry Slack messages — comprehension debt is invisible. Tests pass. Code looks clean. Nothing is wrong. Until it is.
The test
Pick a module in your codebase that AI substantially modified in the last six months. Answer:
- Why does the retry logic use exponential backoff with jitter?
- What invariant does the validation on line 247 protect?
- If you removed the abstract base class, what breaks?
- Why three layers of error handling instead of one?
If you can't answer confidently — that's ghost ownership. Git blame says it's yours. You can't explain how it works.
We measure who changed code. We measure how often. We measure complexity. We measure bugs.
We don't measure whether anyone can explain how it works.
The module nobody can fix
Think of the module in your system that nobody's touched in a year. The one that "just works." If it broke tonight, who on your team could debug it?
If the answer is nobody — that's invisible rot. Doesn't show up in dashboards. Nothing is failing. Nothing is changing. Sits there until the day it needs to change, and then you discover the "owner" can't explain any of it.
AI accelerates this. Every approved PR that nobody understood is a deposit into the invisible rot account.
Now what
We measure who changed code. We measure complexity. We measure bugs. We measure churn.
We don't measure whether anyone understands it.
If you've found a way to deal with this, I'd like to know. I haven't.
Originally published at totalslop.ai
Ride the slop.
References:
- Sonar, "2026 State of Code Developer Survey." sonarsource.com
- Lightrun, "2026 State of AI-Powered Engineering Report." lightrun.com
- METR, "Measuring the Impact of Early AI Assistance on Developer Productivity." arXiv:2507.09089
- CodeRabbit, 13M+ PRs analyzed. coderabbit.ai
- Addy Osmani, "Comprehension Debt." O'Reilly Radar, 2026
- David Parnas, "Software Aging." ICSE 1994.
Top comments (0)