By Evgueny Lemasov — Founder of ITFriends.AI. We build custom software and AI-augmented engineering teams for companies in Europe and the US.
In 2025, tech companies cut roughly 150,000 jobs while simultaneously posting record budgets for AI tooling and AI-fluent engineers. GitHub’s own research on Copilot found developers completing tasks up to 55% faster, and Stack Overflow’s 2024 survey reported that 76% of developers are already using or planning to use AI tools in their workflow. Read those numbers together and the headline writes itself: *AI is replacing software engineers.*
It isn’t. But it is replacing a specific kind of engineering work — and the gap between engineers who understand that distinction and engineers who don’t is about to define the next decade of hiring.
The hype cycle we’ve seen before
Half a century ago, when the IBM PC arrived on office desks, accountants were told their profession was over. Early programmers seriously discussed retraining as truck drivers. The predictions were dire and almost none of them came true.
What actually happened was the largest expansion of knowledge work in human history. The professionals who adapted — who learned to use the new tools instead of competing against them — became the highest-paid employees at thousands of companies that didn’t exist before. Whole industries were born. The total number of jobs didn’t shrink; it multiplied.
The AI moment looks identical from the inside. Same fear, same breathless predictions, same misreading of what the technology actually does to the work.
What’s actually being automated — and what isn’t
The work AI is genuinely good at today is the work that was already mechanical:
- Writing boilerplate CRUD endpoints and standard data access layers.
- Translating well-specified tickets into code in familiar frameworks.
- Generating unit tests for code that already exists.
- Summarizing documentation, drafting commit messages, and explaining unfamiliar code.
- Producing first-draft UI from a clear design.
The work AI is *not* good at — and shows no signs of being good at soon — is the work that was always the hard part of engineering:
- Decomposing an ambiguous business problem into a system that can actually be built.
- Choosing between architectural trade-offs whose costs only show up in production six months later.
- Debugging a failure that crosses three services, two teams, and a vendor.
- Making security and compliance judgments where the cost of being wrong is asymmetric.
- Translating between what a stakeholder asked for and what they actually need.
- Owning a problem from “we have a vague concern” to “it’s shipped, measured, and stable.”
Notice the pattern. AI automates *tasks*. It does not automate *problems*. Engineering, at the senior level, has always been the second one.
Two snapshots from the field
A European news and media corporation with several million subscribers asked us to design an AI-based system for automated content publishing, optimized to outperform competitors in the fast-moving news ecosystem across social platforms such as Facebook, Instagram, X, and others, with built-in intelligence for anticipating and maximizing content reach and engagement — under a fixed-bid contract most vendors would price in the high six figures. It was precisely this new approach to custom software development — 20 years of combined engineering experience compounded by three years of AI-first delivery — that let us win the bid on both cost and timeline, and then outperform expectations on both. AI wasn’t just a feature we shipped — it was the reason we could ship at all: it shaped how we estimated the work, how we built it, and how we delivered at roughly twice the efficiency of a conventional team. The judgment about *what* to build still belonged to senior staff; AI made that judgment go further, faster.
The second case is a Swedish logistics company moving thousands of shipments a month. Their operational side runs on tight, well-understood standards; their software development side did not, which meant cost and timeline estimates for new internal systems were unreliable. We introduced AI-based automation into the estimation and delivery workflow itself — not to replace the engineers, but to give them a far more accurate baseline to commit to. The result is the kind of predictability they already expect from their freight operations: reliable cost and timeline estimates, and faster delivery without sacrificing quality.
In both cases, the multiplier wasn’t on the tool. It was on the judgment of the people holding it.
The real filter
So yes, AI will replace some software engineers. But not the ones the headlines suggest. The engineers being filtered out are the ones who can only execute what is literally written in a Jira ticket, who do not independently analyze a problem, and who do not own outcomes beyond their immediate code. These have always been an expensive bottleneck. AI is accelerating a selection process the industry needed for a decade.
On the other side of the filter are the engineers who think quickly, propose unconventional solutions, and carry a problem from “we don’t fully understand it yet” all the way to a working, measured system in production. For them, AI is not a threat. It is the largest force multiplier their careers will ever see.
What this means for CTOs and founders
If you run an engineering organization, four things should change in your planning this quarter:
- Re-weight your hiring rubric. Stop optimizing interviews for syntax recall and standard algorithm puzzles — that’s exactly the surface AI now covers. Test for problem decomposition, system design under ambiguity, and debugging across boundaries.
2. Restructure team composition. A team of four senior, AI-augmented engineers will out-deliver a team of ten mid-level engineers on most product work. Budget accordingly. The pyramid is flattening.
3. Treat AI tooling as core infrastructure, not a perk. Standardize on Copilot, Claude Code, or equivalent across the org, fund the licenses centrally, and measure adoption. Teams that use these tools well are pulling away from teams that don’t.
4. Invest in custom software development, not more SaaS.
The same AI leverage that makes engineers faster also collapses the build-vs-buy math. Workflows that were “too expensive to build, just buy a SaaS” two years ago are now economical to own — and owning them is where the real competitive moat is.
The opportunity
The transformation underway is not bad news for engineers, and it is excellent news for the businesses that move early. Companies now have an unprecedented chance to outpace competitors who cannot adapt — not because AI replaces their teams, but because their teams, augmented correctly, do work that used to require three times the headcount.
The question is not whether this shift will happen. It already has. The question is whether you are building with the engineers and the tooling that are on the right side of the filter.
—
ITFriends.AI builds custom software and AI-augmented engineering capacity for companies that want to own their critical workflows instead of renting them.
