AI slop is hard to fork - Frank DENIS random thoughts.

Skip to main content

If you’ve ever maintained a fork of a project, or a pull request that takes forever to land, you’ve been there.

At some point, upstream moves. Then you run git rebase or git merge, and suddenly your nice isolated change is covered in merge conflicts

Sometimes this is manageable. A nearby function changed. A file moved. Someone renamed a type. Easy enough. You spend a few minutes fixing things, run the tests again, and move on.

Sometimes it isn’t fine.

The maintainer reformatted the entire project. Or reorganized every module. Or rewrote internal structures your change depends on. Now your fork isn’t really a fork any more. It’s an archaeology project.

And this has always been painful.

It’s not just boring mechanical work. It’s also risky work. The version you originally wrote was tested against a specific upstream state. You understood the code around it. You probably had a coherent reason for every line.

After three painful rebases, the goal quietly changes.

You’re no longer trying to preserve the quality of the original change. You’re trying to make the thing compile again. You’re trying to make tests pass. You’re trying not to lose your mind while resolving the same conceptual conflict in five slightly different files.

And boom, bugs and vulnerabilities that didn’t originally exist get introduced. The quality of the fork degrades after every rebase.

The annoying part is that this used to be relatively rare.

Big, sweeping upstream changes happened, but they cost real human time. A maintainer had to decide that a massive refactor was worth the pain. They had to do the work. So most projects had some natural friction.

But AI removes a lot of that friction.

Cheap experimentation is useful. But it also changes the shape of commits.

In vibe-coded projects, commits often get huge. Often enough that it becomes a pattern. A prompt produces a diff that touches a lot of surface. The maintainer looks at the result, runs the tests, likes the direction, and commits it. Single commit, large changes.

The cost of producing that diff was tiny. The cost of everyone else integrating with it was not.

A large AI-generated refactor may be cheap for the person pressing enter, but it can be extremely expensive for anybody maintaining local changes, a downstream patch set, or a long-running pull request.

The project didn’t just change behavior. It changed shape.

And forks depend on shape.

A fork isn’t only a copy of code. It’s a set of assumptions about where things live, how functions are split, which internal boundaries are stable enough to build on, and which files can be changed without touching the rest of the world.

When every other upstream commit reshuffles that shape, the fork loses its anchor. This is especially bad for changes that are important but not immediately mergeable.

Maybe the maintainer agrees with the idea but wants a different API. Maybe the change needs more testing. Maybe it’s useful for one deployment but too specific for upstream. Maybe the project moves slowly on review because everybody is busy.

And if the upstream project is constantly being rewritten by prompts, the window for a sane merge gets much smaller. Either your work lands quickly, or it starts rotting immediately. Not because the logic became wrong. Because the surrounding code was churned into another shape.

After a while, maintaining the fork becomes virtually impossible.

You can stop updating from upstream, which means the fork slowly becomes its own project.

You can keep rebasing, which means spending more and more time repairing damage caused by unrelated global edits.

Or you can give up and ask an AI to generate your own competing version from scratch.

That last option sucks, but it’s exactly where the incentives point. If upstream treats code as disposable text that can be globally regenerated whenever the mood changes, downstream users will eventually treat upstream the same way.

Why maintain a careful fork of something that refuses to keep a stable shape?

There’s a difference between intentional large changes and casual churn.

A human refactor usually carries some scar tissue. You can see the maintainer trying to minimize damage. The diff has boundaries. The commit message explains why this had to happen. Compatibility layers appear. Old paths survive for a while. Reviewers ask whether this will hurt downstream users.

AI slop doesn’t naturally care about any of that.

It optimizes for satisfying the prompt in the current checkout. It doesn’t know which patch series exists in someone’s fork. It doesn’t care that a small function rename creates conflicts in ten open pull requests. It doesn’t feel the social cost of making everybody else redo work.

Forkability is (was?) a project quality. AI makes it easier than ever to destroy it.

Related Posts

May 27, 2026<br>Pushing to a pull request that isn't yours

May 17, 2026<br>Bun's...