There’s a culture in software development today that I absolutely despise: the cult of shortcuts.
You need X? There’s a library for that!
It’s the software equivalent of living off McDonald’s. Quick, cheap, and everywhere — but empty calories. Need to left-pad a string? Install a package. Need to format a date? Pull in an entire library that drags half the ecosystem with it. Need a debounce function? There are a dozen options on npm, none of which you actually need if you understand how closures and timers work.
Too many developers today are microwave chefs: they don’t know how to cook, only how to reheat. They glue together someone else’s ingredients and hope the dish is edible. And worse, they defend it as though reheating packets is the pinnacle of cuisine.
The Epidemic of Dependency
This isn’t just a bad habit — it spreads like cancer.
Developers who can’t solve small problems with core language features join greenfield projects and bury them in dependencies. I’ve seen projects where trivial functionality that’d require less than 10 lines of code, comes from third-party libraries.
Six months later, the “kitchen” is overflowing with expired ingredients. Merging Dependabot pull requests becomes a full-time job, performance tanks, and nobody on the team knows what the system is actually doing because the code all came from someone else’s repository. Instead of having 5 contributors, you have 500… and no, more is not better.
When the project inevitably collapses under its own weight, those same developers leave and repeat the process somewhere new. Bootcamps have industrialized this cycle, flooding the industry with copy-paste type-monkeys who outnumber everyone else at least 100 to 1.
The Dogma of “Nobody Knows Anything”
The cultural dogma makes it worse.
The industry runs on the joke: “Nobody knows what they’re doing.” What used to be a harmless laugh has become the industry’s comfort food — a way to excuse mediocrity.
If nobody knows anything, then suddenly bad code is “just how the industry works.” Dependency hell is fine. Promoting someone who’s never written a clean function in their life? Fine, and if you dare to suggest otherwise, you’re “not a good team player”.
Meanwhile, the people who actually give a damn — the ones who enforce real standards in code reviews — are treated like villains for “slowing things down,” as if fixing a bug later is magically faster.
Promotions for Renters, Not Builders
The upside-down nature of promotions is the final insult.
The people who “rent” code from npm are celebrated as seniors — apparently “npm install” counts as industry experience now. I’m sorry, it’s called “knowing the ecosystem”. They’ve never built a foundation, but somehow they’re put in charge of designing houses. The builders — the people who actually understand wood, nails, and concrete — get told to stop nitpicking.
This is how projects rot: the landlords are promoted, the carpenters are silenced, and everyone acts shocked when the house caves in.
AI: Gasoline on the Fire
As bad as the dependency culture has been, AI is accelerating the problem.
Instead of developers outsourcing small problems to a library, now they outsource their thinking entirely. Don’t understand how to write a loop? Ask ChatGPT. Need a sorting function? Copy-paste whatever the model spits out. Although even copy pasting might become esoteric knowledge with all the agentic IDEs.
Generate it. Ship it. Never mind what it’s actually doing.
It’s like every developer now has their own ghost writer to generate their dream libraries — one that works instantly, doesn’t ask questions, and lets them slap their name on the commit. They get all the credit for code they didn’t write, and none of the responsibility for understanding it.
Good luck having a meaningful code review with someone like that. You’re not reviewing their work — you’re reviewing the ghost’s work, with a proxy in the room who can’t explain the design choices because they never made them.
AI isn’t just another tool. It’s gasoline on the fire. We already had an epidemic of dependency addiction. Now we’re mass-producing developers who can generate a mountain of code without ever learning how to tell if it’s any good.
Build, Don’t Reheat
Software development is supposed to be about building software, not just gluing libraries together or copying from a bot.
Yes, dependencies have their place. Nobody’s suggesting we rewrite cryptography libraries from scratch. But we’ve swung so far in the opposite direction that pulling in a package for isEmpty() has become normal. That’s not engineering — that’s cargo culting.
The industry doesn’t need more microwave chefs or ghost-assisted contractors. It needs cooks. It needs builders. It needs people who can think, design, and solve problems with the tools already at their disposal. Otherwise, we’ll keep choking down greasy leftovers, pretending it’s gourmet, and wondering why every project gives us heartburn.
Choose the Hard Way
None of this is easy — and that’s the point. Building real software takes effort. It takes learning your tools deeply, making trade-offs consciously, and being willing to say “no” when the quick fix looks tempting.
But that’s the job. Our job is not to blindly glue together libraries, or to ship whatever an AI coughs up. Our job is to build things that last.
If you think the code AI generates is better than what you could come up with, you don’t need AI — you need practice. You have a lot of work to do.
Every shortcut we take today becomes someone else’s nightmare tomorrow. You can either be the developer who leaves behind a landfill of half-baked code… or the one whose work people can actually rely on.
Stop reheating. Start building.