There has been a very active debate (1, 2, 3) on how useful AI is for programming. It speeds up development, but sometimes at the cost of quality and understanding what you are building.
I'm seeing more and more cases where engineers take an existing or legacy codebase and use AI to refactor, optimize, and improve it. Over time, the codebase hardly resembles the original in design, implementation, and sometimes architecture. Sure, it still deploys and passes tests, and it still lives in the same repo. But in many cases the developers don't actually understand how it works anymore.
I want a term for this: Theseus Slop.
Theseus Slop is what happens when LLMs gradually replace the code in a system you already had, eventually replacing almost every line of code, function, and file, until it feels like a different codebase altogether. Unlike vibe coding a project from scratch, this usually begins with code that you understand and ends with code that you do not.
Maybe you've seen this by now: a legacy service gets "modernized" over a few months, the domain is still the same, the repo name is unchanged, but the auth flow, API integrations, error handling, and even folder layout feel foreign. You can ship features, but you can't explain why a particular guard clause exists.
Where the name comes from
The term comes from the Ship of Theseus, also called Theseus's Paradox, a thought experiment about identity and change. In the paradox, a ship is gradually repaired by replacing each part with a new one, until nothing of the original remains. That raises two questions:
- Is the ship with all new parts still the same Ship of Theseus?
- If it is not, at exactly what point did it stop being the original?
There is no clean answer. It depends what you mean by "the same". Same exact design? Same functionality? Same crew or name on the boat?
Vibe coding does something similar at a glance, but Theseus Slop is the slower version on code you already owned: each piece swapped out until the whole is unfamiliar, with no single moment where anyone called it a rewrite.
You cannot name the exact commit where your understanding ended, any more than you can name the plank that ended the original ship.
The questions
The same two questions apply to codebases.
Is it the same codebase? You can see the Git history and how the codebase has evolved over time. The product name and deployment target are all the same. But the structure of modules, the patterns for I/O, and the implicit conventions or even overall style may not be. Under one set of criteria - continuous version control, same overall functionality - you have one system. Under another - shared mental model among the people who maintain it - you may have replaced it without ever declaring a rewrite. You might not even realize it until you try to explain how it works to someone else.
Is it still yours? You wrote much of the first version. You approved all of the AI's generated diffs. Ownership in that sense is intact. Yet "yours" also means you made all of the design decisions and can reason about it when asked: trace a bug, reject a bad abstraction, explain a tradeoff in review. Theseus Slop is the gap between owning the repo and understanding how it works. The code is in your repo, but the design decisions are not in your head.
When does it matter?
What's the counterargument?
The old ship (code) needed replacing. If it's truly a legacy project, then it's already a liability. If AI-assisted refactors fix bugs, remove dead paths, shrink modules, or align the system with how the product works today, the replacement may be an improvement in every measurable way. Yes, potential confusion among maintainers is a cost, but so was paralysis around code everyone was too afraid to edit.
I would guess some teams argue the gap does not matter much if the repo has a solid set of tests, types, and documentation. You don't need to keep the old architecture in your head if behavior is well known and well documented.
It seems to me that both points hold in many projects. The disagreement is not whether AI can improve code - it clearly can - but whether the remaining gap in understanding matters for your situation.
There are other factors to consider as well:
Stakes. Theseus Slop hurts when you must debug under pressure, review security-sensitive changes, onboard a new engineer, or work through an audit that requires you to know how the system works and not just what it does. It doesn't matter as much when you are throwing together a prototype, exploring an idea for a weekend, or just writing a one-off script.
Scale. A solo developer working on a small tool can better handle an unfamiliar structure. The complexity is usually less anyway. But a team on a long-lived, critical production system magnifies the problem: there is no subject matter expert who can answer questions about their section of the codebase and you must rely on AI to regurgitate an accurate explanation back to you.
Why name it
My attempt to coin the term "Theseus Slop" is not an argument against using AI on existing code. But it's a label for a certain outcome: incremental replacement (without thorough review) at the expense of comprehension. For any important project, it's a risk that needs to be understood and avoided. For everything else, it's a risk that needs to be managed.