As we enter 2026, the question everyone in the tech industry is facing is: will AI replace software engineers? There’s a lot of anxiety around this topic and heated debates. Some people avoid this topic as a plague and some look for the answers. My view is simple …
_Quick Answer - it won't. It will bring even more opportunities._
But it if you want to understand where these opportunities are and why its not just granted / free (you actually need to adapt, put some work) enjoy the read.
AI is an opportunity
I believe AI will transform our industry and make us even more productive, more impactful, and ultimately more rewarded by companies and businesses. However, to benefit from this shift, you’ll need to transform yourself. You’ll need to become a different type of engineer.
AI is and will be an opportunity for the whole industry, but there will be people who benefit from it and the ones that won’t. And I don’t want to say that the jobs will be gone, I don’t think this is the case - as its more a case of value of the roles and types of skillset you bring in will shift and change.
_On Positive note - Being in IT is a blessing._
We are one of the first industries that will adopt AI on a massive scale. This puts us in the early adopters bracket of a technology shift. A lot of industries will face this challenge in 5-10+ years. Early adopters are usually ahead and then can use their experiences in other types of industries - facing the change.
This Transformation Is Not new
I’ve been in this industry for about 16-20 years, and I’ve witnessed several major transformations. Each time, people worried about their jobs - and each time, the industry adapted, changed and it moved the value generated by folks from one place to another. It was important to look at the waves going across the industry and learn new skills, change perspectives.
Virtual Machines & Managed Memory
One of the first big transformations I witnessed was when engineers stopped writing code that dealt directly with memory allocation. We got virtual machines that abstracted all of this away from us.
On University I had to learn ASM and C and understand in details all the abstracted parts - and how things work behind the scenes.
Back then, when this started happening, people were complaining: “How can you be a real engineer if you rely on a virtual machine? It’s inappropriate! It’s ineffective! It’s not optimal!” But look where we are now - there are multiple different systems, frameworks, and languages, and we just rely on them. We no longer worry about memory allocation at the degree of specialization we did before. It has been abstracted away, and the industry moved on.
_Specialization is still needed._
I don't want to paint a picture here that specialization or this type of knowledge is not needed anymore. There are still people having a very detailed knowledge about memory allocation responsible for optimizing systems and building the virtual machines and their interations.
Hey we even have Rust language and the whole community that takes the memory allocation very seriously. But the market for that kind of skills is getting smaller and smaller, its crowded and requires from you to have a ton of experience. It is difficult to get into.
So it is not like value from this skillset will dissapear it will just be more difficult to get the same amount of value out of it.
The Testing Revolution
Another transformation I witnessed required a bigger change in engineer behavior. Developers were told: “Now you are supposed to also write tests - unit tests, integration tests, all kinds of tests. You need tests.”
At the same time, testers were told: “You’re not just a manual tester anymore. You’re supposed to write code, write scripts, and automate the way you do things.” The whole industry shifted. Instead of being focused on a specific narrow task, engineers became responsible for building stable features that are correctly tested and correctly developed. The boundaries between “developer” and “tester” blurred, and quality became everyone’s responsibility.
It was not like that from the beggining the work was more siloed - meaning - more specialized when I entered the market.
_It did not mean you are not supposed to have specialization._
Again, this whole move was not about making you super `generalist` or to forget about having a specialization.
It was more about - Hey engineers keep your expertise and specialization but in order to scale the way we build products and increase the quality of them you also need to start having general knowledge around teseting and feel ownership of being responsible for end user quality.
DevOps & Infrastructure
Another transformation happened when engineers were told: “Now you’re going to deal with DevOps and infrastructure-related stuff. This is something you should worry about because it makes products better if you think about infrastructure.”
It was no longer a plyaground for SysOps oriented folks. DevOps just like Testing Revolution - told both sides to get general knowledge in other fields in order to be able to build better products with more robust foundation (infrastructure).
_Of course, not everyone can be fully specialized in infrastructure_
But at least you should understand the basics so you can design better products. We still have specialized people who do the heavy lifting for infrastructure-related stuff. We still have platform engineering teams that provide a platform to build on top of. But product engineers still need to understand the fundamentals in order to be better at their jobs. Infrastructure knowledge became table stakes for building quality software.
From Devops to Cloud
When I jumped into the DevOps world, I started with the cloud. I already assumed cloud was the baseline - just the basic stuff you work with. But cloud itself was a revolution for a lot of IT specialists in the industry. Many felt threatened, thinking cloud was going to take their jobs because it commoditized so many things around building scalable infrastructures.
I got used to the cloud. I got very comfortable with it. I felt it was my superpower. Then Docker and Kubernetes entered the space, and they started challenging the knowledge I had. They commoditized a lot of things around building system architecture and system design, making things a lot simpler from that point of view.
_We still need Cloud/Devops/k8s experts_
And again - we still need specialists and people that understand k8s in details. But k8s made it a lot easier to buid/maintain scalable systems. A lot of the complex properties of a system you get out of box and you can build more reliable and available products. This type of system characteristics have become slightly commodetized - meaning the value of being able to create more reliable and avaialable systems has gone down.
It doesn't mean its equal `0` but its just lower.
And Now: AI Commoditizing the ability to produce Code
You can see that transformation is part of our industry. It’s part of the business. AI is simply the next step - and this time it’s targeting the coding part itself.
The coding part of our work is becoming commoditized. It will be a lot cheaper to write code. Code will no longer be the bottleneck - the limiting factor in our ability to build products. When the coding part was a bottleneck it meant there was a great deal of value you could generate for having this kind of skill.
But, here’s the economic reality: when something stops being a bottleneck the price the market pays for it goes down and down. If you want to retain your current value - you need to adapt to where the market needs are.
I believe the next bottleneck will be coordinating the coding work of all the different people (and AIs) into bigger structures and higher abstractions. Knowledge around architecture, system design, domain knowledge will become much more profitable in the coming future.
The pattern is clear: each wave of transformation abstracts away complexity and shifts where value is created. AI targeting the coding layer is simply the next step in this ongoing evolution.
_AI/LLMs might commodetize this too_
It's also possible that AI will commoditize this layer too eventually - I'm not certain, but it could happen. We'll see. But for now, this is where I see the value shifting.
My Bet: Invest into domain / soft and business knowledge
In my opinion, we will need to become more focused on business impact and outcomes. We can no longer be engineers who just do magic tricks with code and technology without fully understanding where the impact lies.
This is my main proposition: to benefit from this AI transformation, you need to be more than just a technologist who writes code, creates solutions, and designs architecture. You need to be a partner to your business, your company, and your colleagues. You need to be a driving factor behind revenue and value creation.
You can no longer be the “magic box” that simply translates someone else’s ideas into technical solutions. You need to understand and drive the business outcomes yourself.
This isn’t a new idea—Eric Evans preached this in his Domain-Driven Design book years ago. We just need to get back to this foundation.
FAQ:
_What if you are wrong?_
Well I will change my mind and adapt to the market needs and requirements. I do have my passion and hobby but I am also a professional that is interested in being able to respond to market shifts.
_What if don't want to adapt?_
It is your decision, you will be stacking your odds against the market and statiscitally `the value` of your skills will get smaller and smaller.