We are currently living through the greatest inflation of software in history.
With the AI tools we have available in 2026, a Junior Developer can generate more lines of code in an afternoon than a Senior Developer used to write in a month. We have lowered the barrier to entry for creation to almost zero.
But we have not lowered the cost of maintenance.
If anything, we have created a crisis. We are drowning in "good enough" code, boilerplate, and features that "might be useful later."
Code is not an asset. It is a liability.
I used to measure my productivity by how many green squares I had on my GitHub contribution graph. I thought that writing more meant I was building more value.
I was wrong.
Every line of code you write is a commitment. It is something that needs to be:
- Tested
- Debugged
- Secured
- Updated when dependencies break
- Read by the next person (or yourself in 6 months)
The Hoarder Mindset
I recently realized that my codebase looked exactly like my "Read Later" list—a graveyard of good intentions.
I had features I built "just in case." I had abstractions that were "future-proof" (for a future that never arrived). I had utility functions that were used once and then forgotten.
It was digital hoarding. And just like hoarding physical objects, it creates a mental load that paralyzes you.
The Era of the Code Janitor
The best developers I know right now are not the ones spinning up 10 microservices in a weekend. They are the ones walking into a project and saying:
"We can delete this module."
"We don't need this library."
"We can solve this without code."
They are not Architects. They are Janitors. And I mean that with the highest possible respect.
The Art of Subtraction
I spent this past weekend doing nothing but deleting.
I removed a feature that only 2% of users touched but caused 50% of the support tickets.
I ripped out a complex state management library and replaced it with standard React hooks.
I hard-coded variables that I had made dynamic "just in case."
The result? The bundle size dropped. The build time was cut in half. But most importantly, my mental model of the system became clear again.
Conclusion
In a world where AI can write infinite code, the value of writing code approaches zero. The value shifts entirely to curation.
Your job is no longer to build the mountain. Your job is to carve the sculpture out of the rock.
If you want to be a Senior Engineer in this new era, stop asking "What can I add?" and start asking "What can I remove?"
Go look at your PRs from last week. Did you add complexity, or did you remove it?
The most satisfying commit message is not "Feat: Added X".
It is "Refactor: Deleted 2,000 lines".
Top comments (119)
I decided to refactor my code of 5,327 lines in main.py + 344 + 665 additional scripts + 7 + 358 + 226 + 378 lines of shaders. I feel like I haven't slept in a week. Seriously, I just tried using
__init__.pyand I don't even understand its purpose, other than burning my patience...?!Refactoring is an art. And apparently, the way I format the structure, it's safe to say I'm a bad architect. No. As Paolo Veronese said, "I'm an artist, I see it that way." And I'll say, "I'm a vibe coder, and I don't need architectural skills, I just need it to work." Maybe that's bad, but at least it gives me impetus to create something bigger (I hope).
@embernoglow Vibe coding builds prototypes. Deletion builds cathedrals.
The arc:
You're living the post exactly and great to see you finally did prune your codebase. BTW your sdf repo is just gold :) Love to see more open source contributions like this.
Thank you!
5,327 lines in main.py? That is not a script, that is a novel. Respect.
I love the term "Vibe Coder". Honestly, getting it to work is the hard part. Architecture is just what we do later when we are tired of scrolling up and down 5,000 lines to find a variable.
Don't let init.py break you. Python packaging confuses people with 10 years of experience. Go get some sleep.
Thanks!
This is not a 2026 skill, writing as less code as possible has always been the goal of programming.
Libraries and frameworks should be a considered solution in the application, not a starting point.
With AI the libraries and frameworks could become a thing of the past because it can produce custom code faster than setting up a framework.
In the AI experiments I'm doing I'm using a router for a front controller, the base of most web frameworks, to check how far I can push AI.
A router can come with one or more ways to identify the routes; config, a builder pattern, attributes. But an application will have a single way of router identification to make it predictable.
So you don't need the other options, which means you can remove abstractions that are made to make the other options possible.
Because the base isn't a framework anymore, the application doesn't force you to use the opinion of the framework if it has one.
The question is not can you delete lines, which is the worst metric you can use to measure code quality.
The question is how much code are you willing to maintain.
You nailed it with your last sentence. How much code are we willing to maintain is the only metric that really matters.
Your point about AI replacing frameworks is incredibly interesting. We used to accept framework bloat because we needed the development speed. Now that AI can write a custom router just as fast, we do not need to import all that extra baggage anymore.
The challenge now is just making sure the AI does not invent its own bloated abstractions when we ask it to build those custom solutions. Keeping it minimal is definitely a timeless skill.
You can instruct AI to write the simplest code, and the output always has to be reviewed.
The death of frameworks with AI is that they are opinionated, and everyone has their own opinion.
Like you mentioned we accepted the framework opinion, because it brought us speed.
Now we can start with the libraries and custom code, and let AI create the glue code in the same time that is needed to setup a framework.
That is why I took the router component as a base to experiment with AI. Does it reliably alters the router, Does it do a bit weird stuff like using FFI code for the route matching. Does it create the base for a maintainable application. Does it write tests an documentation that requires minor changes. And so on.
I'm late starting with the experiments but the tools we have today are much easier and diverse, and we also understand the pros and cons of AI use better. Most of the time it pays off not to dive in from the start.
The maintenance cost point is the one that doesn't get enough attention. We benchmarked AI-generated code recently and found that 65-75% of functions had security vulnerabilities — so it's not just that AI creates more code to maintain, it creates more risk to maintain. Every line you don't delete is a line you're implicitly agreeing to secure, and most teams aren't doing that audit. The "code janitor" framing is spot on. @the_nortern_dev
That 65-75% stat is terrifying, but honestly not surprising.
I absolutely love how you phrased this: "Every line you don't delete is a line you're implicitly agreeing to secure." That should be printed on every CTO's wall.
It reframes the "Code Janitor" from someone who just cleans up messes to someone who is actively reducing the attack surface. In 2026, deleting code is arguably the most effective security patch you can apply.
Thanks for adding that data point to the discussion.
That 65-75% stat is terrifying, but honestly not surprising.
I absolutely love how you phrased this: "Every line you don't delete is a line you're implicitly agreeing to secure." That should be printed on every CTO's wall.
It reframes the "Code Janitor" from someone who just cleans up messes to someone who is actively reducing the attack surface. In 2026, deleting code is arguably the most effective security patch you can apply.
Thanks for adding that data point to the discussion.
Great minds think alike! 😄 I actually published an article on the EXACT same topic yesterday — same title and everything!
Your take is more philosophical and really captures the 'inflation of software' idea beautifully. That line about junior developers generating more code in an afternoon than seniors used to write in a month? Chef's kiss. 👨🍳
My version took a more beginner-friendly, practical approach with before/after code examples and a 'Code Delete Challenge' for readers. Seems like we both recognized this is THE skill for 2026!
Curious — what's the one piece of code YOU'VE deleted that made the biggest difference in your career? Would love to hear your story!
It is funny how these ideas surface across the industry at the exact same time. It just proves how pressing this issue actually is right now. I will definitely check out your practical approach, having concrete code examples is always a great addition.
To answer your question: the biggest difference for me was ripping out a massive, over-engineered state management library in a recent project and replacing it with a simple, standard data flow.
Deleting that entire abstraction layer improved the actual performance of the app more than any new feature I had added that year. It was the moment it really clicked for me that complex architecture is often just a symptom of not fully understanding the core problem.
Great minds indeed. 🙂
Absolutely well said! When I started my career, I used to think that the more complex the architecture, the better developer I am. But the reality is that the best code is the one that's easiest to read and understand.
You're absolutely right about removing abstraction layers improving performance. I've also observed that many times we unknowingly slow down our applications by over-engineering.
"The simplest way to solve a problem is always the best" - this is the lesson I've learned too. Thanks for sharing the code examples, and yes, truly - great minds think alike!
Unlearning the desire to build complex architecture is definitely a rite of passage for every developer. It sounds like we have both learned that lesson the hard way over the years.
Thanks again for a great discussion. I look forward to crossing paths in the comments again.
Absolutely agree—sometimes the simplest solutions are the hardest lessons to learn. I really enjoyed the exchange as well. Looking forward to more great discussions in the comments!
Honestly, I don’t really like the vibe of "vibe coding". It’s great for scaffolding and getting something off the ground fast. But once you start leaning on it too heavily, it almost feels like the AI senses the dependency and starts churning out slop.
That is a perfect description. "Vibe coding" feels like borrowing time from the future at a predatory interest rate.
I have noticed that exact degradation too. Once the context gets complex, the AI starts guessing. If you do not have the deep knowledge to audit and delete that "slop" immediately, you end up with a codebase that is technically working but impossible to maintain.
i ran the same refactor task through five different models recently and most of them added code i didn't ask for. one restructured the whole file. another added a bunch of stuff that looked reasonable but wasn't in the prompt. the "code inflation" problem isn't just humans writing too much, it's AI tools silently expanding scope on every prompt.
the deletion skill applies differently now too. it used to be "delete the feature nobody uses." now it's "delete the three helper functions the AI added that you don't need but look reasonable enough that you almost kept them." the second one is harder to catch because the code actually works.
This is a fantastic observation. The silent scope expansion is exactly what makes reviewing AI-generated code so exhausting right now.
When the code is broken, it is easy to reject. But when it works and looks perfectly reasonable, it takes a lot of discipline to delete those three extra helper functions instead of just leaving them in.
You nailed the difference perfectly. We have gone from deleting unused features to actively defending the codebase against helpful but completely unnecessary additions.
This hits hard. Been building a data pipeline for the past few months and the biggest productivity unlock wasn't adding anything — it was ripping out a layer of abstraction I added "for flexibility" that nobody ever used.
The AI code generation angle makes this even more acute. When a junior can generate 500 lines in 20 minutes, the senior's job shifts from writing to triage. You're not the author anymore, you're the editor. And good editors kill darlings.
The 2% feature / 50% support tickets stat is brutal and real. I've seen the same pattern with API endpoints — the rarely-used ones are almost always the ones that cause incidents because nobody maintained them.
That point about rarely used API endpoints causing the most incidents is a hard truth. We always focus on our main flows, but the real technical debt is usually hiding in those ghost features we added just for flexibility.
Ripping out that unused abstraction layer probably did more for the stability of your pipeline than any new feature could. Good editors really do kill their darlings.
'ghost features' is exactly right. and the cost of a ghost feature isn't just the code — it's the cognitive overhead every time you touch something nearby. you have to remember it exists, consider whether your change might affect it, and verify it still works. that tax compounds across every future change.
the abstraction layer I ripped out was the same: it had never been used for its intended purpose, but it sat in the mental model of anyone reading the code, silently demanding to be accounted for. removing it didn't just reduce LOC, it removed a question that every future reader had to answer.
This is an excellent consideration to bring forward this year. The ability to simplify and create lean code that does more with less signifies a deeper understanding of the codebase and should be rewarded as such.
Spot on, Julien. I think the challenge for engineering leaders in 2026 is exactly that: figuring out how to reward the "negative space" in a project.
It’s easy to measure a feature launch, but it's much harder to measure the value of a bug that never happened because the code was simplified. We need to move away from "lines of code" as a metric and start looking at "reduced complexity" as the true sign of seniority.
Have you seen any teams successfully implementing metrics or cultures that actually incentivize this kind of subtraction?
In one of my previous teams, it would be taken as a positive to simplify/remove code whenever possible. However implemented as an actual metric no, it would be interesting to explore that further.
Making it a formal KPI is definitely risky. Goodhart's law kicks in fast and people might start deleting safety checks just to hit a number.
We just highlighted negative lines of code during sprint reviews. It was enough to signal that cleanup mattered without creating perverse incentives
Good point! Goodhart's law indeed!
Reduced complexity is our team main idea. That why I force even forget TS and choice jsDoc instead, because that is keep typesafe and compatibility with TS but we avoide a extra build complexity. But my main direction is dependency minimalism - in any language. That is very handy even rust, not just JS.
You're right, overengineering is a slippery slope that eventually leads to technical debt.
I understand what you mean about deleting code being a valuable skill, but I still wouldn't call it the most valuable one. Sometimes you need to add code sometimes tons of it, not to show off, but because it improves the product, performance, functionality, or security.
For example, last year I reviewed a friend's portfolio website. It was simple, clean, and had nothing "unnecessary" in it. But I quickly noticed it was vulnerable to all sorts of attacks under the surface, like XSS for example. I left detailed comments on the repository and he ended up spending two additional days adding safeguards and writing quite a lot of additional code lines to properly secure it.
My point is this: the most valuable skill isn't deleting code, it's still writing code and I think it will always be like that, but in the most sensible, thoughtful, and responsible way possible.
You make a very fair point, and that is a great example. Security is definitely one of those areas where adding lines of code is a non-negotiable asset.
I think we are actually talking about the same core skill: judgment. My focus on deletion is mostly a reaction to the massive wave of low-value, AI-generated bloat we are seeing right now. But you are absolutely right that being a responsible developer means knowing when to add the necessary safeguards, even if it makes the codebase bigger.
The goal isn't just less code, it is the right code. Thank you for bringing that perspective.
Absolutely, couldn't agree more. Great article!
Thank you Giorgi!
This resonates a lot with me.
As someone building AI-powered and full-stack products, I’ve realized that shipping fast is easy in 2026 — especially with AI — but maintaining clarity is the real engineering skill. Every abstraction, every dependency, every “future-proof” config adds cognitive load to the system.
In one of my recent projects, removing an unnecessary state library and simplifying the data flow improved performance more than any “new feature” I added. The code became easier to reason about — and that’s real productivity.
Writing code is creation.
Deleting code is judgment.
And judgment is what separates developers from engineers.
"Writing code is creation. Deleting code is judgment." That is a brilliant way to frame it. I might have to quote you on that in the future.
State management is the absolute perfect example. We always reach for the heavy libraries on day one, convinced the app will be massive. Ripping that global state out later and realizing standard data flow works fine is the best feeling.
Keystrokes are cheap now. Judgment is the actual bottleneck.
That really means a lot — feel free to quote it 😄
You’re spot on: premature architecture is just overengineering in disguise. AI made keystrokes cheap, but judgment, restraint, and knowing when not to abstract — that’s the real senior skill.
Consider the quote officially stolen.
Fighting the urge to build for scale on day one is definitely the hardest habit to break. Thanks for a great back-and-forth. See you in the next thread.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.