AI Won’t Take Software Developer Jobs — But Bad Decisions Just Might 

So, no. AI will not take your jobs, but humans in charge may decide it should. 

This article addresses an urgent reality: not the speculative futures, but today’s immediate choices — how AI is defined, how interpretations are shaping decisions right now, and why these decisions pose the real danger to developers and organizations. 

The core argument is simple: AI is a powerful tool, but not understanding its role can lead to costly and irreversible mistakes. 

If you prefer a condensed version, see the executive summary at the end. 

Fear and Uncertainty 

Across the world, workers are uneasy. A recent ADP Global Workforce Confidence report (Today at Work, Issue 1 of 2026), based on a worldwide survey of more than 39,000 people across 36 markets, shows that fewer than 25% of workers feel confident that their jobs are secure. The anxiety is present despite of historically low unemployment. 

It’s worth noticing that this is not really about AI capabilities. It is about uncertainty. 

There are also speculations about whether AI could evolve into something far more powerful through means such as recursive self-improvement. For a rigorous exploration of the topic, see Superintelligence: Paths, Dangers, Strategies by Nick Bostrom. Bostrom maps potential trajectories in detail — although many of them based on strong assumptions. 

Meanwhile, we face a more immediate issue: decisions made amid uncertainty. 

In The Plot Against America, Philip Roth describes what he called the relentless unforeseen: what feels uncertain and terrifying in the present will later be studied as inevitable. But we do not live in hindsight — we live in the moment where outcomes are still shaped by choices. Our choices. 

Losing our jobs may appear inevitable. However, it only becomes reality if we decide to make it so. 

What AI Can and Cannot Do Today 

AI is often framed as something approaching autonomy. It is not. 

We may fear that the relentless unforeseen unfolding before us is human work being replaced by AI, but — with all due respect to our future AI overlords — AI as we know it is just a tool. 

AI does not hold goals. It does not understand consequences, and it does not take responsibility. It does not possess a grounded understanding of the world beyond patterns in data. 

It predicts what looks right, not what is right. 

Current AI systems generate statistically plausible outputs from large training corpora and immediate context. They can be extremely useful — but they still require human direction, judgment, and verification. If the output occasionally appears intelligent, that is anthropomorphism at work. 

This distinction matters. The moment we mistake pattern generation for understanding, we begin to misjudge what can and cannot be replaced by AI. 

What AI Can Do for Us 

Used well, AI is a powerful amplifier. 

It can liberate developers from mechanical, low-level tasks such as writing boilerplate code and wiring syntax, and elevate the developers to a higher level of thinking. The most effective division of labour is simple: 

AI handles the syntax. Humans own the semantics. 

When developers can delegate substructure maintenance to AI, they can direct more effort toward the superstructure. Instead of tracking every pointer and variable, they can focus on higher level topics such as class hierarchies, design patterns, cybersecurity, regression testing, quality assurance, and documentation. 

As with any tool, AI should reduce trivial work so that humans can focus on non-trivial problems — where they still excel. 

The policy risk begins when productivity is confused with replaceability. 

Why Companies Misjudge AI and Developer Productivity 

This is where the real danger begins.  

A common assumption is that if one worker becomes more efficient, the organization can “bank” that efficiency by reducing headcount. This line of thought is one reason why so many people fear losing their jobs. 

The problem lies in how we interpret efficiency. At the level of measurement, efficiency is one attribute among many. At the level of decision, efficiency often becomes one of the few attributes that survive — sometimes the only one. Once that happens, decision quality degrades quickly. 

Further complicating the issue is how efficiency is measured. Should it be: 

• In lines of code per hour, because more is assumed to be better? 
• In work items closed per sprint, because verification and validation are handled elsewhere? 
• In pull requests merged per sprint, because impact and quality do not matter? 
• In time to market, because requirements were perfectly known in advance? 

Each of these measures ignores critical context. 

Efficiency metrics are highly contextual. For example, a developer refactoring a legacy system may produce little visible output for weeks. Or, another developer may spend days trying to prevent a flawed architectural decision, producing no code at all. 

By narrow metrics, both appear inefficient, though they may be delivering the most value to the team and organization. 

To put it simply: efficiency is not a value. It is a proxy—and often a misleading one. 

When efficiency becomes the dominant metric, organizations risk optimizing for what is easy to measure — and losing what actually matters. 

Why Efficiency Metrics Fail in Software Development 

Software development is not just execution. It is judgment. 

Rather than efficiency alone, developers should be evaluated for their skills and their contribution to the whole. 

Developers contribute through problem-solving, communication, learning ability, adaptability, and critical thinking. They carry knowledge, experience, and context that cannot be easily quantified. Developers also perform what is called glue work: coordination, alignment, and communication that keep teams functioning. This work is essential — and frequently invisible. 

The real qualities are difficult to measure numerically, but humans can still evaluate them. Through collaboration, feedback, retrospectives, and shared experience, we develop a reliable understanding of each other’s contributions. We do not need to discard that understanding simply because we have a new tool. 

At Softability, we see this repeatedly in practice: the most impactful work is often the least visible in metrics. 

The Cost of AI 

It’s quite simple to understand where the trend for downsizing comes from. AI is extremely cheap. Developers are not. 

A typical business AI subscription in Finland is roughly 20 euros per month. The average labour cost for a software developer is around 5000 euros per month. In many Western countries, AI tooling represents roughly 0.4% of developer costs. 

This makes it tempting to assume one can replace the other. However, that conclusion does not follow. 

Why AI Is Needed in Software Development 

This article is not against using AI in software development. 

Software development is becoming more demanding, not less. 

The market is global , and competition is constant. Expectations for quality, security, and compliance are rising. To stay ahead, organizations need to invest in modern tools and practices. And AI is one of those tools. 

From an EU perspective, regulations such as the Cyber Resilience Act increase the requirements for secure design and continuous maintenance. This expands the scope of work and AI can help meet the demands. AI can support vulnerability detection, accelerate repetitive security tasks, and improve cybersecurity. For example, see Project Glasswing by Anthropic. 

But AI does not remove the need for expertise. If anything, it increases the need for skilled developers who can use the tools effectively and responsibly. 

The urgent question is not whether we need fewer developers. It is whether we can build more capable teams. 

Blind Spots in Decisions 

There is a recurring pattern in how AI is being evaluated at the decision-making level. The people who understand AI tools best are often not the ones making workforce decisions. 

Reliable metrics for how AI enhances human work are still emerging, and robust evidence for full replacement is even weaker. We need more data, more experience, and more time before making irreversible decisions. 

As we speak, developers are busily experimenting and collecting evidence in context. The problem is that results are complex and easily distorted as they move up reporting chains. This creates a risk that decision-makers, distant from the work, make conclusions based on weak metrics, with long-term consequences for both companies and workers. 

Several cognitive blind spots emerge in this trend: 

• The Dunning–Kruger Effect
  Those with limited exposure to AI tools may be the most confident in assessing them because they have not encountered the limitations of the tools. 
• Cargo Cult Thinking 
  Management sees output — code, summaries, prototypes — but not the judgment required to produce and validate it, hence, the conclusion becomes: the tool is doing the work. 
• Polanyi’s Paradox
  “We know more than we can tell.” Much of a developer’s expertise is tacit. It cannot be fully articulated, which makes it easy to underestimate — and easy to overlook. This can lead to underestimating experienced developers and overestimating AI tools. 

Humans can reflect, explain, and adapt their thinking when asked. That is not true for AI. 

The result is a distorted view of both the technology and the people using it. 

Decision Hygiene Matters 

The current situation is volatile and uncertain. In such conditions, decision hygiene matters more than speed. 

Decisions do not happen in isolation. They shape culture, expectations, and future decisions. Short-term, poorly grounded decisions — such as cutting experienced staff from the workforce — can create long-term damage that is difficult to reverse. 

If you are a decision-maker, you should: 

• Base your decisions on reliable data and real experience 
• Understand the limits of the tools 
• Involve the people closest to the work 
• Reliably measure before, during, and after any decision 
• Remain willing to reverse decisions when needed 

Talk to your developers before making structural decisions about their work. 

In light of the above, the real question becomes how leaders should decide in the face of uncertainty. The unforeseen will come either way. But we still get to choose how we respond. 

Final Thought 

AI will change how software is built. That is certain. 

Whether it weakens or strengthens organizations depends on how we respond. 

The technology is new. The responsibility is not. 

 

Executive Summary 

If you read nothing else, read at least this. 

When is workforce reduction defensible? 

• When you believe your workforce can be fully described by a single efficiency metric. 
• When your product is complete and will never need improvement. 
• When market requirements are static. 
• When your entire production line can be fully automated. 
• When you can ignore customer feedback, regulations, and quality requirements. 
• When you are willing to discard accumulated knowledge and experience. 
• When you want to hide deeper structural problems. 
• When long-term thinking is not part of your strategy. 

When is workforce reduction not defensible? 

• When you can continue to afford your current workforce. 
• When you want to invest in your workforce and retain your most valuable asset. 
• When you want to avoid high-risk decisions in uncertain conditions. 
• When you value expertise and want to avoid repeated onboarding costs. 
• When you want to build a culture that uses AI responsibly. 

What is the safest path forward? 

• Stay calm — conditions are volatile. 
• Equip teams with AI tools — the cost is low. 
• Provide training — adoption is fast. 
• Reserve time for learning — it will not happen otherwise. 
• Allow room for mistakes — experimentation is essential. 
• Talk with teams and adapt to context. 
• Use reliable metrics to measure outcomes. 
• Be ready to reverse decisions that do not deliver.