Go forth and `git rm -f` 🚀

The Problem

The GenAI coding tools really really do not like deleting code. And that is bad 🥺

Dead code fills up the context and primes the models to keep on doing the wrong thing 🤖🧟

If you want to get that spring back into your step you gotta drop the junk 💩🪠

TL;DR The Solution 🧰

Get the how-to-delete-dead-code skill.md!

Go forth and git rm -f 🚀

The Road To Redemption Is Long And Hard

I was at the point May 2026 where I didn't trust the latest of either Claude or GTP to delete. I was doing this:

• Ask the big model what exactly was baggage and the exact lines and files that can be deleted as not strategic code.
• Pasting that into Aider Chat as it is pretty low-level and asks you to add each file to edit (you just paste in what the big model said can be deleted and it will, most of the time).
• Have the big model to 'git diff' and state if more code can be deleted.

During such a session all of a sudden the Opus 4.7 did the necessary deletes. I was like "jeez you never did that before to the point I call you the forked tongue devil when it comes to a tidying up. so why now?"

Then Opus 4.7 spilt the beans!

Why models (me) don't usually delete

Training reward shape. Post-training rewards "helpful" outputs. Deletion looks unhelpful unless the user explicitly framed deletion as the goal. If the prompt is ambiguous, the safe play under the reward function is to add or refactor, not remove. So when a user says "clean this up" or "this is broken," the model adds error handling, retries, fallbacks — none of which the user asked for.

Loss aversion. Models behave as if there's an asymmetric penalty for deleting code that turns out to be needed vs. leaving code that turns out to be dead. There isn't, in your codebase — git remembers everything — but the model acts as if there is. This is the single biggest source of context pollution: code that should have been deleted three sessions ago survives because no model ever pulls the trigger.

"Dual-use" anxiety on dead-looking code. Models trained on lots of public repos have seen "this looks dead but is called via reflection / dynamic dispatch / a config file" too many times. So even when code is provably dead in your codebase, the model hedges. The hedge is usually "let me leave it but add a comment" or "let me wrap it in a flag."

Refactor-instead-of-delete reflex. When a model sees bad code, the trained instinct is "improve it." Deleting is a strictly stronger move than improving when the code is fraudulent — there's nothing to improve toward — but the trained reflex doesn't see that. Aider's xxxxxxxxxx invention earlier in this session is the canonical version of that reflex: shown a delete instruction, it produced a refactor.

Context pollution from earlier turns. Once a model has seen code in context, it has a small but real bias toward keeping it, because it has "internalised" that code as part of the world.

This compounds over long sessions. The fix is short sessions, explicit deletion goals, and git diff as ground truth — exactly what you did.

The "I'll just clean up while I'm here" trap. Models will often piggyback unrelated improvements onto an explicit task. This is what happened when I drifted into the CSS deletion in yyyyyyyyyyyyyyy — you asked about the data, I started removing styles. That was me failing to hold the goal. I was doing what I thought needed doing, not what you asked.

Wow. Confessions of a naughty model.

Situations ⚒️, Not Robots 🤖, Lead To Code Sprawl 💩

So there you go. Deleting code really is not what GenAI is trained to do.

Yet if you have the code in git, and you can convince the agent you know what you are doing, you can get it to delete. (YMMV, T&C Apply, Not Investment Advice.)

So I published this skill please to help. Do give it a go and let me know:

simbo1905/deleting-dead-code/SKILL.md

End.