This content originally appeared on DEV Community and was authored by Yurii Rashkovskii
Everyone cheering AI coding tools says the quiet part out loud eventually:
“So… when can I fire my developers?”
That’s the real subtext no one puts in their blog posts.
“A new class of builders is emerging” → (Translation: maybe we don’t need expensive engineers?)
“Focus on outcomes, not methods” → (Translation: maybe we don’t need people who care about methods?)
Under the polished veneer of empowerment, the motivation is clear: cut costs, move faster. And there’s nothing inherently wrong with that.
Except we’re focusing on the visible output of software developers, and confusing that with their value. Simulating the output doesn’t eliminate the role — it just replaces developers with something fast, unpredictable, and equally expensive in other ways.
You're still left with messy, brittle, over-complicated systems – just built faster and broken differently.
The real move isn’t to replace developers with AI.
It’s to stop needing so much software engineering, operations, and maintenance in the first place.
The Fantasy of Fewer Engineers
Every few years, a new wave of tooling arrives that promises to make engineers obsolete. Even in the early days. COBOL. 4GLs. Visual Basic. No-code. Now, AI.
Each time, the hope is the same: let someone else (or something else) do the building. But the underlying complexity doesn’t go away. It just gets hidden. Until it leaks.
AI today is like hiring a half-drunk junior developer: fast, tireless, and unaware of consequences. It can spit out working code, but it can’t reason about tradeoffs, edge cases, evolving requirements, or failure modes.
Software isn't expensive because of syntax. It's expensive because systems live for years, not minutes.
The Problem Isn’t Developers. It’s Over-Engineering
If you're trying to build business systems cheaper, the goal shouldn't be firing developers.
The goal should be to need less bespoke code in the first place.
Too many products are weighed down by:
Separation of concerns
Over-abundant, over-dependent microservices
Ongoing maintenance and migration tax
We've been chasing clever architectures instead of asking whether we need this much architecture.
Data, Not Software, Is the Core of Business Systems
That’s what I’m working on.
Since 2004, for over 20 years, I haven’t been able to shake the belief that the real heart of most business systems isn’t the code.
It’s the data.
Business workflows are usually just data state machines: records moving through stages, reacting to events, triggering outcomes.
But data has been:
Misunderstood by app developers
Constrained by layers of abstractions
Boxed away in the realm of DBAs and managed services
What if we stopped pushing data to the edges of the system? What if we started with data and let systems emerge from there?
The Future: Data-Native Architectures
Not AI-generated code. Not yet another abstraction layer. But a fundamental shift in how we model, build, and reason about systems.
If we want cheaper, more maintainable business software, we need to stop repeating the cycle: new tool, same mess, slightly better.
We must reduce the need for software and understand that data is not buckets of "things" but a structured and fluid representation of reality.
Let’s stop asking, "When can I fire my developers?"
Let’s ask, "What can we build so we don’t need as many developers in the first place?"
Let’s stop hiding the complexity.
Let’s eliminate it.
This content originally appeared on DEV Community and was authored by Yurii Rashkovskii
Yurii Rashkovskii | Sciencx (2025-07-08T17:31:22+00:00) Firing Developers Won’t Make Software Cheaper. Retrieved from https://www.scien.cx/2025/07/08/firing-developers-wont-make-software-cheaper/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.