DEV Community

Gil Pham
Gil Pham

Posted on

The Most Valuable Skill in 2026 Isn't Writing Code. It Is Deleting It

I build & run a dental tourism marketplace with 2,000+ clinics listed. I have been writing code for over a decade. And the single best thing I did for my codebase this year was mass-delete 40% of it.

Not refactor. Not archive. Delete.

Let me explain.

The Age of Effortless Creation
We live in 2026. Claude Code will scaffold an entire Laravel module in 90 seconds. Cursor autocompletes your tests before you finish naming the function. GPT writes your migration files, your API routes, your validation logic.

Writing code has never been easier. And that is exactly the problem.

When the cost of creating something drops to near zero, people create too much. I watched it happen in my own projects in real time.

Over the past two years I built:

A full RBAC system for our electronic health records
A CRM with lead scoring across two custom roles
A payroll automation engine compliant with Vietnamese labor law
A patient registration flow in Angular and Laravel
A 156-topic content calendar generator
An automated deployment pipeline pushing to 30+ static hosting platforms
A URL indexer dashboard for IndexNow and Google Indexing API
Every single one of these was a reasonable thing to build at the time. Every single one added lines to a codebase that a small team has to maintain forever. And some of them, honestly, should never have been built at all.

What AI Taught Me About My Own Code
Here is the moment that changed how I think about this.

I was using Claude to audit our SmileJet marketplace codebase. Laravel, Vue, MariaDB. Around 180K lines across the whole project. I asked it to identify modules with zero or near-zero usage over the past 90 days.

The answer was brutal.

Fourteen controllers. Twenty-three Vue components. Nine middleware classes. Two entire Blade template directories. All technically functional. All doing nothing. Some had been written by AI tools. Some I had written myself during late-night "productive" sessions. The AI did not care who wrote it. Dead code is dead code.

I deleted all of it in a single afternoon.

The test suite still passed. Deployment was faster. The new developer I onboarded the following week had 40% fewer files to navigate. And most importantly, when I asked Claude to help me build a new feature the next day, its suggestions were cleaner because there was less noise in the context window.

Deleting code made the AI better at writing code. That is not a minor observation.

The Real Cost Nobody Talks About
Every line of code you keep is a line of code that:

Someone has to read when debugging at 2 AM
AI tools have to parse when generating suggestions
Your new hire has to understand before they can contribute
Your CI/CD pipeline has to test on every push
You have to worry about when a dependency gets a CVE
We treat code like an asset. It is not. Code is a liability. The asset is what the code does. The liability is the code itself.

I learned this the hard way running healthcare software. When you have patient data flowing through six clinics across four cities, every unnecessary module is not just technical debt. It is a compliance surface. It is an attack vector. It is a place where something can go wrong at 3 AM when a dentist in Da Nang is trying to pull up a patient record and something, somewhere, is throwing an exception in a service that nobody remembers building.

The Three-Question Framework
Before I write anything now, or before I let AI write anything for me, I ask three questions:

  1. If this module disappeared tomorrow, who would notice?

Not "who might theoretically need this someday." Who would actually notice, this week, that it was gone. If the answer is nobody, it should not exist.

  1. Can this be a configuration change instead of code?

I used to build custom logic for everything. Bonus calculations for dentists, commission tiers for assistants, pricing rules for different markets. Now I ask: can this be a JSON file? A database row? An environment variable? Every time you turn code into configuration, you remove something that needs a developer to change.

  1. Am I building this because it solves a problem, or because it is interesting?

This one hurts. I am a developer. I like building things. The automated deployment pipeline to 30+ hosting platforms? Genuinely needed for our SEO backlink infrastructure. The experimental GraphQL layer I started prototyping for our API? That was me having fun. I deleted the branch.

AI Makes This Worse Before It Makes It Better
Here is the uncomfortable truth about AI-assisted development in 2026.

AI tools are incredible at generating code. They are terrible at knowing when not to. Ask Claude or Copilot to solve a problem and they will solve it. They will not say "actually, you should delete that entire service and handle this with a 3-line middleware."

The developer who can look at a growing codebase and say "no, we are removing this" is more valuable than the developer who can spin up a new microservice in an afternoon. Because in 2026, everyone can spin up a new microservice in an afternoon. Very few people have the judgment to know which microservices should not exist.

This is especially true if you are a founder or a small team. I have six clinics, a marketplace, and a team that is not Google-sized. Every feature I keep alive is competing for the same finite pool of attention, maintenance, and cognitive load. The discipline is in subtraction.

What I Actually Deleted (And What Happened)
Here is a concrete list of things I removed from production codebases in the past year, and what happened after:

A custom analytics dashboard that duplicated what Google Analytics already showed us. We had built it because "we might want custom metrics someday." We never did. Deleted. Nobody noticed for three months until someone asked "hey, where did that dashboard go?" I said it was gone. They said "oh, okay" and went back to GA.

A notification microservice that sent internal Slack alerts for patient registration events. Sounded useful. In practice, the channel had been muted by every team member. Deleted. Slack got quieter. Nobody complained.

An A/B testing framework I had built for our clinic landing pages. We ran exactly two tests in 18 months. Both were inconclusive. The framework had its own database tables, its own middleware, its own Vue components. I replaced it with a simple feature flag in our .env file. Deleted. Page load time improved by 120ms.

Three different PDF generation approaches that had accumulated over time as different developers tried different libraries. We standardized on one. Deleted the other two and their dependencies. Composer install dropped by 15 seconds.

Every deletion made the codebase healthier. None of them caused a single user-facing issue.

The Skill That Matters
Junior developers add code. Mid-level developers add good code. Senior developers remove code.

In 2026, AI has commoditized the ability to add code. What it has not commoditized is the judgment to look at a system and know what should not be there. That requires context. It requires understanding the business. It requires the courage to delete something that took three weeks to build because it is not earning its place anymore.

If you manage a codebase, I challenge you to do this today: pick your largest project and ask an AI tool to identify the modules, routes, or components with the lowest usage over the past quarter. Then ask yourself honestly which of them you would rebuild if they disappeared.

The ones you would not rebuild? Delete them.

Your future self, your team, and your AI coding assistant will thank you.

I am building healthcare tech and a dental tourism marketplace in Vietnam. If you are curious about the technical side of running clinics and marketplaces in Southeast Asia, follow me for more posts like this.

Top comments (0)