I feel like software engineering will never be the same again, and engineers will be way less needed. I believe that’s actually a good thing.
How code looked was uninteresting to me
What drew me to software engineering in the first place was beautiful web and mobile applications. How the code looked was never what interested me. You work with engineers who have different perspectives, and you usually end up making compromises based on what suits the company and its business goals.
Most engineers will recognize these discussions: monolith versus microservices, packaged or non-packaged software, a separate dependency or not, reusable or not. You make these compromises with your colleagues for every piece of software anyway. Linters are the same: do we use tabs or spaces? And native or non-native applications.
Then there’s the human part. I’ve worked with colleagues who were adamant about their own domain and their preferred technology and tools. A web developer who knows JavaScript or TypeScript, for example, is more likely to pick React Native and/or Expo when building a mobile app.
The same happens within web development itself. Do we use React? Vue? Tailwind? Node.js? Rails? There are so many technologies to choose from, and engineers usually had a preference and were knowledgeable, or even experts, in it.
The playing field has leveled
Nowadays, basically any software engineer can choose what they want without necessarily needing the domain knowledge. They only need to learn the basic syntax if they still want to read and verify code manually. And because code looks familiar across many programming languages, an experienced engineer can usually identify the most important code and business logic in a pull request.
So the playing field for engineers has leveled out quite a bit. Expert domain knowledge still exists, for example in native iOS or Android APIs, but with AI and LLMs it’s quite reasonable to learn in a short amount of time. And I believe even that will become redundant as LLMs get better and cheaper.
How I got here
My first experience with LLMs was the first version of ChatGPT. If I didn’t understand a code snippet, I asked it to explain it. As LLMs got better, I asked them to refactor smaller snippets and checked whether they worked. At that time, it was still 50/50.
Then came the magnum opus: Opus and Claude Code launched, and the paradigm shifted dramatically. The AI still lacked domain knowledge or expertise in some areas, but you could already feel that once the code got better, everything would change. And it did.
Now, Opus 5.5 or even GPT Sol 6.1 writes very good code and tries to understand the context of the work you’re doing. Given your project architecture and agent setup, I’d argue it writes better code than 60% of all engineers. Actually, I’d even say 75%.
Will AI replace software engineers?
So, in my opinion, software engineering has been solved. The profession will never be the same again, and a lot of engineers will be replaced within the next three to four years. You could be out of a job in four years, and that includes me.
I see it happening in stages. First, we still do the work ourselves with Opus or GPT, prompting the LLM to solve our business needs. Then we’ll move to a more hands-free setup, probably inspired by Grok Bot, Hermes, or OpenClaw, where agents automatically find bugs and write PRs. Low-risk pull requests get merged automatically. Medium- to high-risk ones probably still need human verification.
After that, verification will get so good, either through your agentic setup or because LLMs got better, that a software product can improve itself within the guardrails you provide.
Teams won’t have many engineers anymore. Probably two or three, who can manage and develop a software product very well. Next to them will still be the human side: most likely a product manager and, in some cases, an extremely good designer. I think that’s the team you’ll need for every software product, whether it’s a backend service, a mobile app, a web app, or embedded software with hardware. No software product team will have more than three engineers.
So what’s next for software engineers?
I think the number of software engineers will drop significantly, while the number of marketers and product managers will grow.
The best move for a software engineer is to learn other skills, mostly in marketing, product management, social media, and agentic setup. If you still want to focus on technology, agentic setup is probably the best path. By that I mean designing your software’s architecture so agents can navigate it and develop in it as easily as possible.
You need to outperform the high-agency marketer or product manager who simply tells their Claude, ChatGPT, DeepSeek, or Kimi to do the work: fixing bugs, building new features behind a feature flag, and testing them themselves. As LLMs get better, agentic setup will also become less necessary. But less necessary doesn’t mean you’re out of a job, so it’s the best area to focus on. There’s lots of content out there, for example from DeepMind and other engineers, on how to set up your own agentic workflow.
The best way to describe this role is IT support. IT support makes sure colleagues have what they need to do their job: computers, mice and other peripherals, documentation, and data. In agentic terms, you’re the one providing the tools and documentation agents need to do their work well. Right now, the most important part of that is verification: how can an agent verify that its work is correct?
The fun part
But there’s also a tremendous amount of fun involved. Software engineers used to depend on many other factors: business decisions, time constraints, technology bottlenecks. Now that has basically all changed. Building prototypes and testing new ideas is fast now, so engineers have a bigger role and impact there too, not just discussing technical requirements and writing the code.
A prototype that took three days to a week to develop now costs one agent thread, and you can test it immediately.
That frees up a lot of your time for things I think you should have been doing in the first place: experimenting with and improving the product you work on, or getting into other areas of it. If you were mainly a backend engineer, you can dive into the frontend, build features end to end with an agent, and decide what an MVP or prototype should look like.
Honestly, I think software engineering was the best part of creating value for customers. For me, it was never about how clean the code looked. I don’t really care if code is duplicated in two places. More than that may be a problem, but in general I’m not that strict and never was. I’d rather compromise on what the team wants and be a flexible team player.
Now I don’t really have to worry about that. My colleagues are working quite well in this era. They set up their own rules, we set up ours, and we still make compromises. But in the end, most of our work right now is verification: checking that our applications work, that the LLM-coded feature meets the requirements, and so on.
Of course, there will always be bugs in software. I don’t think LLMs or AI will solve that. But engineers weren’t always quick to catch new bugs or faulty code in reviews either. Even with quite advanced QA teams, some medium- and occasionally high-priority bugs got through. That’s just the nature of serving a large customer base.
Adapt, like always
Software engineering will change drastically, and you have to adapt to the technology and the times: learn new skills, adapt. But honestly, it’s always been like that. My first programming language was C. Then I moved to Objective-C for a bit, and when Swift came out I moved to that and learned new tools and new Apple APIs. Then I did some web development and learned some things there, before becoming mostly an expert in Apple technologies. Now AI is here, and it’s here to stay for software development.