Scale by Subtraction: Why Senior Engineers Must Be “Chief Deletion Officers

In the age of AI-generated code, the most valuable architectural skill isn’t knowing what to build, it’s knowing what to remove.

As engineers, our natural instinct is to build. We solve problems by addition: a new feature, a new microservice, a new caching layer, or a new library. We measure our productivity by lines of code written or tickets closed.

But in 2025, “adding” has become dangerous.

I recently saw this play out in a small experiment. I asked an AI agent to clean up and consolidate a chaotic internal Wiki. I expected it to merge pages, summarize content, and delete the fluff. Instead, it created more sub-wikis. It tried to solve the confusion by adding structure, which resulted in more pages, more links, and more noise.

The AI did exactly what many engineering teams do: it mistook volume for value.

We are entering an era where AI can generate code and dependencies at infinite speed. If we aren’t careful, our systems will collapse under the weight of “additions.” This brings me to a realization I had while working on a major service at Microsoft: the most valuable skill for a Senior Engineer or Architect today isn’t knowing what to build.

It’s knowing what to delete.

The “Geological Layers” of a Mature System

I recently stepped into a role working on one of the most famous, foundational services at Microsoft. This service had been built over many years, and everyone who touched it before me had done their best. They made the right decisions for their specific time and context.

But the nature of software development is that we almost always solve problems by addition.

The technology space had evolved, but the codebase hadn’t let go of the past.

• Old Constraints: We had code written to solve memory constraints from five years ago that didn’t exist anymore.
• The Framework Trap: The team had started migrating from Framework A to Framework B. But in the rush to build new features, Framework A was never fully removed.

When I looked at our dependency map, it didn’t look like an architecture diagram. It looked like a pile. We had accumulated massive amounts of technical debt, not because the code was “bad,” but because we never subtracted the old contexts.

I realized that if we didn’t stop and fix this, we were going to hit a wall. We were paying a “complexity tax” on every pull request. But here is the hard part: You can’t just delete dependencies on a Friday afternoon.

Boxing the Time: Making Subtraction a First-Class Citizen

The biggest mistake teams make is treating cleanup as “side-of-desk” work. They say, “We will clean up the dependencies when we have some downtime.”

Downtime never comes.

To solve this, I had to treat “Subtraction” with the same rigor as a new feature launch.

1. The Buy-In: I went to leadership and the Product Managers. I didn’t talk about “clean code.” I talked about ROI. I explained that we were bleeding efficiency on every incident investigation because of the noise.
2. Boxing the Time: We didn’t squeeze this in. We “boxed” the time. I made it clear to the engineers: “This is not extra work. This is THE work. You are 100% focused on this.”
3. The Execution: We went after one dependency at a time. We didn’t try to boil the ocean. We ruthlessly verified if a library was actually needed or if it was just a ghost from a past era.

The result? We removed about 10 major dependencies. And the metrics followed. We saw fewer incidents because there were fewer moving parts to break. Our “Mean Time to Resolve” (MTTR) improved because the system was easier to reason about. We were actually “saving work” by deleting code.

The 2025 Challenge: The AI “Addition” Trap

This brings us to today. The “Subtraction Mindset” is more critical now than ever because of Generative AI.

I see junior engineers (and even seniors) using AI agents to blast through tasks. The AI loves to add. If you ask it for a solution, it will often suggest importing a new library, creating a new helper class, or spinning up a new config file.

Just like the Wiki example, the AI tries to solve confusion by adding volume.

If you are a junior engineer reading this, here is my advice: Don’t just commit what the AI generates.

Before you accept that code, pause and ask the “Subtraction” questions:

• Do we really need this dependency? Or can we do this with what we already have?
• Who is going to maintain this? The AI won’t be there to debug it when it breaks in 6 months.
• Is this mature? It is okay to wait. You don’t need to use the bleeding-edge library just because the agent suggested it.

Conclusion: Be the Chief Deletion Officer

We need to change how we view seniority.

Junior engineers are often measured by how much they create. But as you grow, your value shifts. In a world where AI can create infinite complexity in seconds, the most valuable engineer in the room is the one who knows what to take away.

Don’t let your legacy be a pile of “additions.” Scale your system by subtraction.