Software Engineering

I studied Computer Science, and my first job title was Consultant. In my next job, 5 years later, I was a Software Programmer, and then, more recently, I got a Software Engineer title. What all of these jobs had in common was that I was writing software to solve specific problems.

Solving problems using software was the main outcome I was being paid for. To deliver on that goal, engineers needed to understand programming languages, frameworks and systems. Then, as requirements and systems became more complex, engineers also needed to understand testing, automation (CI/CD), infrastructure and security, and some even specialised in specific languages or parts of the system (frontend, backend). This led to specialisations in the industry, and some roles became more distanced from product.

One of my teachers at university told this story, and it has stuck with me ever since:

There was this lift in a skyscraper in New York, and customers complained it was slow. Experts, mechanical engineers and others came in to look at the issue but couldn’t find any technical solution to speed it up. In the end, they decided to install mirrors in the lifts and the lobbies. The theory was that people were bored and, with the mirrors, they would have something to do - look at themselves. The complaints stopped.

It perfectly illustrates one of the core traits of a good Software Engineer. Get to the root cause of the problem before deciding what to do. Actually try to define the problem yourself rather than accepting it at face value. Always ask why. It may even be that the solution does not even require software.

These days, this is one of the aspects of what a Product Engineer does - understand the product, talk to the customers and figure out how to solve the problems using software.

AI age

I use Claude Code a lot, but I keep it simple. No more than four concurrent sessions, simple prompts, simple skills. To me, it is quite remarkable what these tools are able to do these days and how fast they have progressed. They have progressed from implementing functions to implementing whole features, running verification loops themselves and automating parts of the software development lifecycle.

Some examples of how I have used it at work:

• Got to the root cause of an incident before anyone else did
• One-shot simple features - or identical features that already existed
• Automated PR opening, taking screenshots/video captures of UI changes and attaching them to PRs
• Full integration with Linear and the deployment environment. It can implement a well-defined ticket; automatically roll out to the development environment; verify the new behaviour in the deployment; iterate; and open a PR.

I do worry about what it means in general for the Software Engineering profession. I have seen two schools of thought: 1. The number of roles will decrease as AI can do a lot more for less. 2. The number of SWE roles will explode as now, with AI, features can be delivered much more quickly and companies will require expert Agentic pilots to keep their edge against competitors.

Conclusion

I do not have a particular prediction, but I believe that the Software Engineering role will change. The change will be quicker in some places and slower in others, but I believe that in 10 years the work a Software Engineer does will be vastly different. The role was never about writing code and AI further demonstrates that.

I think product engineering skills will be the most important in the future: knowing what to build, and especially what not to build, will be the prime skill to have. On top of that, fundamentals will still be very important: knowing systems, how data flows in your platform, which pieces fit where, etc. I think software engineer roles will move closer to what some Staff+ Engineers do now. More of the value will come from understanding customers, the product, the whole system architecture and company strategy.

AI will change how we build software but the core skill still remains: knowing what to build.