The Best Developer Now Is the One Who Deletes Code

For years we judged developers by what they could build. Can they write this feature? How fast? Do they know the latest framework? That made sense when writing code was slow and hard.

It isn't slow and hard anymore. A fresh grad with an AI tool can turn out more code in a day than a senior used to write in a week. So if everyone can write code, why are we still paying for it like it's rare? The developer worth paying for now is the one who can open your system, remove a big chunk of it, and on Monday the orders still come in, the invoices still go out, and nobody notices anything except a smaller server bill.

Writing code got cheap

Five years ago, adding a new report to your system meant a developer sitting down for two or three days. You'd think twice before asking. Today it's twenty minutes with an AI. So people stop thinking twice. Every request gets a yes, every idea becomes a screen, and every "can we also add" turns into another few hundred lines.

That feels like progress. More features, faster, for less money. But nobody's asking the other half of the question. Who looks after all this code next year? And the year after?

We've said this before in Code Is Cheap Now. Software Isn't. Typing the code was never the expensive part. Living with it is.

Every line is something you pay for

Think of your system like a shop's storeroom. Every time someone adds code, they put another box on the shelf. Some boxes you use every day. Some you used once, three years ago. Some belong to a manager who left in 2023 and nobody remembers what's inside.

You pay for every box, whether you open it or not. In software, that cost shows up in ways you don't always see on the invoice:

AI makes the storeroom fill up much faster. It doesn't help you empty it. That part still needs a person who knows what's in the boxes.

Why nobody deletes anything

If old code costs money, why don't teams just remove it? Because deleting is scary, and most teams have no good way to know what's safe.

Picture the conversation. The boss asks, "Can we get rid of that old sales report? I don't think anyone uses it." The developer looks at it. They didn't write it. They don't know who uses it. If they delete it and someone in finance needed it, it's their fault. If they leave it, nothing happens to them. So they say, "Better just leave it, in case."

Multiply that by every developer, every year. The system only ever grows. Nobody gets blamed for code that sits there. Plenty of people get blamed for removing something that turned out to matter.

On top of that, deleting doesn't look like work. A developer who adds three features this month has something to demo. A developer who removed 20,000 lines has a smaller number on a screen and a boss asking "so what did you build?"

Deleting means knowing the business

This is why deleting is the harder skill. To write a feature, you need to know how to code. To delete one safely, you need to know how the business works.

Take an "Export to Excel" button on an old screen. The logs show nobody clicked it in eleven months. Easy delete, right? Except finance uses it once a year, in March, for the auditors. Remove it in October and you find out in March, with the auditors sitting in your meeting room.

AI can't tell you that. It can read the code and tell you what the button does. It can't tell you who in your company needs it, or why, or what happens to them if it's gone. That knowledge lives in people's heads and in how your business runs, and a good developer goes and finds it before touching anything.

So a developer who can delete well has to understand the code, the data, the users and the money all at once. That's a much rarer person than someone who can prompt a new screen into existence.

What a good delete looks like

Good developers don't just highlight a folder and press delete. They do it in small, boring, safe steps.

None of this is clever, it just takes patience. It's also the kind of work that never shows up in a demo, which is why most teams skip it. We've written about what happens when nobody does this for years in The Server Nobody Could Turn Off. That's where "just leave it, in case" ends up.

Change how you keep score

If you judge your team by features shipped and lines written, you'll get more features and more lines. With AI, you'll get a lot more of both. Your system will grow fat, slow and expensive, and every number on the dashboard will say things are going great.

Try a different score. How much did we remove this quarter, and did anything break? A team that took out 30% of the code and kept every order flowing did more for your business than a team that added ten new screens nobody asked for twice.

A developer who answers these well is worth more than one who can build anything you ask. If you're hiring, we wrote more on this in AI Made It Harder to Spot a Good Engineer.

Smaller is the goal

We use AI every day. It's great at adding things. That's fine, as long as someone on the team is just as good at taking things away.

The best systems we've worked on weren't the biggest. They were the ones where every part had a reason to be there and someone could tell you what it was. Getting there takes a developer who's brave enough to delete and careful enough to do it without breaking anything.

That's the developer to look for now: the one who can remove the most while the business keeps running.