There has been a very active debate (<a href="https://news.ycombinator.com/item?id=48019025" target="_blank" rel="noopener noreferrer nofollow">1</a>, <a href="https://arxiv.org/abs/2505.19443" target="_blank" rel="noopener noreferrer nofollow">2</a>, <a href="https://addyo.substack.com/p/treat-ai-generated-code-as-a-draft" target="_blank" rel="noopener noreferrer nofollow">3</a>) 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.
<img src="https://s3.unstack.io/theseus-slop-2.png" alt="Theseus Slop: Code replaced line by line">
Maybe you've seen this by now: a legacy service gets &quot;modernized&quot; 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.
<h2 id="wherethenamecomesfrom">Where the name comes from</h2>
The term comes from the <a href="https://en.wikipedia.org/wiki/Ship_of_Theseus" target="_blank" rel="noopener noreferrer nofollow">Ship of Theseus</a>, 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:
<ul>
<li>Is the ship with all new parts still the same Ship of Theseus?</li>
<li>If it is not, at exactly what point did it stop being the original?</li>
</ul>
<img src="https://s3.unstack.io/theseus-slop-1.png" alt="Theseus Ship: A ship repaired plank by plank">
There is no clean answer. It depends what you mean by &quot;the same&quot;. 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.
<h2 id="thequestions">The questions</h2>
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 &quot;yours&quot; 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.
<h2 id="whendoesitmatter">When does it matter?</h2>
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.
<h2 id="whynameit">Why name it</h2>
My attempt to coin the term &quot;Theseus Slop&quot; 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.

Scott Robinson

Theseus Slop

I have never watched the AMC show Halt and Catch Fire, and for a long time I only knew the title, but nothing about the show. Something about it always reminded me of programmer humor: somewhat dramatic, a little absurd, and weirdly precise. Turns out, the show really is about the computer industry in the 1980s and 1990s, but the phrase itself is much older than the show, and it started as some engineering humor.
<h2 id="whatitmeans">What it means</h2>
In the context of computers, Halt and Catch Fire (shortened to HCF) has been generalized to describe machine-code that causes the CPU to stop doing anything useful, forcing you to only recover by resetting (or power-cycling) the machine. In a pretty literal sense, it &quot;halts&quot; the machine. Sure, the &quot;catch fire&quot; part is a joke, but it's not as far-fetched as it might seem. Take the IBM System/360 for example. Apparently when this system would encounter a certain invalid opcode, it would constantly access a specific location in the magnetic core memory, which caused it to get very hot and even catch on fire.
Over time, HCF also became a catch-all label for undocumented or invalid opcodes that lock up the processor, intentional test modes that look like a hang, and real hardware bugs (you might even recall that some early Pentium-class chips could be locked up with a carefully chosen illegal instruction, known as the F00F bug - more on that later).
The phrase was created, in part, because of the standard of using three-letter assembly mnemonics: <code>ADD</code>, <code>CMP</code>, <code>JMP</code>, etc. The joke spread in various publications, including HCF alongside some other personal favorites of mine:
<ul>
<li><code>EPI</code>: Execute Programmer Immediately</li>
<li><code>DC</code>: Divide and Conquer</li>
<li><code>CRN</code>: Convert to Roman Numerals</li>
</ul>
<h2 id="themotorola6800">The Motorola 6800</h2>
So HCF was mostly just a joke, until it wasn't.
The Motorola 6800 has 256 single-byte opcodes, but not every bit pattern corresponds to a documented instruction. Hit the wrong one and the chip does whatever the silicon &quot;decodes&quot; into — sometimes nothing much, sometimes something significant.
Gerry Wheeler's BYTE piece &quot;Undocumented M6800 Instructions&quot; ran in December 1977, volume 2 number 12, in the Technical Forum on pages 46–47. He starts from Motorola's own docs: 197 documented opcodes, which leaves 59 bit patterns unaccounted for in the official story. Some of those behave like NOPs, some change the condition-code register in patterns Wheeler said were still &quot;undeciphered&quot; at the time, and two bytes — <code>$9D</code> and <code>$DD</code> — share one especially nasty outcome he chose to call Halt and Catch Fire. He is explicit that &quot;The mnemonics are, of course, assigned by me.&quot;
What actually happens, in hardware terms, is that the part stops behaving like a normal fetch–decode–execute engine: the program counter keeps advancing and the chip issues reads while the address lines march through memory like a hardware counter. Interrupts will not stop you from your path of self-destruction - you only get out of the loop with a reset or power cycle. Wheeler's own description is worth reading in the original, rather than paraphrasing:
<blockquote>
When this instruction is run the only way to see what it is doing is with an oscilloscope. From the user's point of view the machine halts and defies most attempts to get it restarted. Those persons with indicator lamps on the address bus will see that the processor begins to read all of the memory, sequentially, very quickly. In effect, the address bus turns into a 16 bit counter. However, the processor takes no notice of what it is reading... it just reads.
</blockquote>
On the &quot;catch fire&quot; half of the phrase, he adds, &quot;Well, almost.&quot; While the IBM system did catch fire in cases, it seems that the Motorola 6800 did not.
Outside BYTE, the same opcode family picked up other nicknames. David J. Agans, in Debugging (2002), remembers <code>DD</code> as what his team called the &quot;Drop Dead&quot; instruction—same bus-walking trick, different name—and notes that engineers used it deliberately because &quot;all of the address and clock lines were nice, cycling square waves&quot; on a scope.
Most machines only feel like they hang. On at least one early 6800 microcomputer with finicky memory-mapped video, the pattern can show up as visible &quot;snow&quot;. Ben Z's <a href="https://sphere.computer/news/2025-04-04-halt-and-catch-fire.html" target="_blank" rel="noopener noreferrer nofollow">Sphere News article</a> is a great rabbit hole to go down (video RAM arbitration, timing, CRT artifacts).
Years later, Motorola engineers wrote more about this same issue. In IEEE Design &amp; Test (1985), Daniels and Bruce describe an illegal opcode that customers found on the MC6800, internally nicknamed HACOF, where the program counter could increment forever until reset. They also tell of a detail that's almost hard to believe: product engineering wanted a fast way to scan RAM during bring-up, recognized this behavior already did something like that, and basically kept it instead of paying to remove it. So, in the words of Bob Ross, this turned out to be a &quot;happy accident&quot;.
More recently, someone actually put a real MC6800 on hardware and actually measured the thing instead of just trusting scans of old magazines and Wikipedia pages. Doc TB's <a href="https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/" target="_blank" rel="noopener noreferrer nofollow">lab write-up</a> notes an interesting detail: after the opcode is fetched, there is a delay on the order of tens of milliseconds before the address lines settle into the famous fast counting pattern, and there are other undocumented opcodes that look like slower or glitchier versions of the same idea.
<h2 id="beyondmotorola">Beyond Motorola</h2>
Motorola wasn't the only modern processor with this issue: illegal 6502 opcodes that lock the CPU, the Pentium <a href="https://en.wikipedia.org/wiki/Pentium_F00F_bug" target="_blank" rel="noopener noreferrer nofollow">F00F bug</a> (if you remember that era), pairs of instructions on some architectures that wait forever for an interrupt that cannot arrive, and modern x86 fuzzing talks where people still turn up invalid states in huge processors.
Basically, with fuzzing they're trying to set random or unexpected data to the processor to help identify vulnerabilities or bugs in the processor. Unsurpisingly, it's a pretty effective strategy, and not just for processors, but for all kinds of software as well.
<h2 id="haltandendpost">Halt and end post</h2>
This was a fun bit of history to research - and there turned out to be much more to it than I expected, even regarding the &quot;catch fire&quot; part. As a lot of software moves up the stack, it's easy to lose sight of the hardware from our 10,000 foot view. In the end, it's just a bunch of silicon wired together in a way that can sometimes go wrong.
All I know is that this phrase is too good to not use - expect a future project (or company) to use the &quot;HCF&quot; acronym.
<hr>
<h2 id="sourcesandmoreinfo">Sources and more info</h2>
To keep you busy, here are some links to the sources and more info:
<ul>
<li><a href="https://archive.org/details/byte-magazine-1977-12/page/n47/mode/2up" target="_blank" rel="noopener noreferrer nofollow">Gerry Wheeler, &quot;Undocumented M6800 Instructions,&quot; BYTE Dec 1977</a></li>
<li>David J. Agans, Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (AMA, 2002), p. 77</li>
<li><a href="https://sphere.computer/news/2025-04-04-halt-and-catch-fire.html" target="_blank" rel="noopener noreferrer nofollow">Ben Z, &quot;Sphere News: Halt and Catch Fire!&quot;</a></li>
<li><a href="https://retrocomputing.stackexchange.com/questions/15289/behavior-of-lesser-known-illegal-m6800-opcodes" target="_blank" rel="noopener noreferrer nofollow">RetroComputing SE #15289</a></li>
<li><a href="https://x86.fr/investigating-the-halt-and-catch-fire-instruction-on-motorola-6800/" target="_blank" rel="noopener noreferrer nofollow">Doc TB, &quot;Investigating the HCF instruction on Motorola 6800&quot;</a></li>
<li><a href="https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)" target="_blank" rel="noopener noreferrer nofollow">Wikipedia: Halt and Catch Fire (computing)</a></li>
</ul>