If I Were a Software Engineer Today, Here's What I'd Focus On

What does this mean for software engineers?

For me, this is probably the most important part of the whole discussion.

If I were planning my career for the next three years, I wouldn’t bet everything on OpenAI, Anthropic, Microsoft, JetBrains, or any other AI company. The market is moving too fast, and nobody knows exactly how things will look in a few years.

Instead, I’d focus on something more stable: skills that will still be valuable regardless of which company wins the AI race.

1. Understand systems, not just code

Writing code is one thing. Understanding how an entire system works is something else.

In real projects, the difficult part isn’t always implementing a new feature. It’s understanding an unfamiliar codebase, figuring out why something is failing, tracing dependencies, and making changes without breaking something else.

AI can generate a function in seconds. But understanding how that function interacts with a complex production system is a different challenge.

That’s why I believe understanding software architecture, debugging, and system design will remain important, even as AI gets better at writing code.

2. Learn how to build reliable AI-powered workflows

Knowing how to use an AI coding assistant is useful, but I think we need to go further than that.

We should learn how to connect AI models to real tools, APIs, databases, code repositories, test suites, and deployment pipelines.

More importantly, we need to understand when AI should make a decision, when a simple automated script is enough, and when a human needs to stay in control.

Building a chatbot that answers questions is relatively straightforward. Building a system that can complete a real business task reliably, handle failures, and know when to ask for help is a different level of engineering.

That’s where things get interesting.

3. Get really good at verification

This is one skill I wouldn’t underestimate.

AI can generate code quickly, but generating code doesn’t automatically mean the code is correct, secure, or maintainable.

Someone still needs to verify that it actually works, handles edge cases, respects the requirements, and doesn’t introduce problems elsewhere in the system.

That means understanding testing, static analysis, type systems, security, observability, CI/CD, and production debugging.

It also means learning how to evaluate AI-generated changes systematically rather than simply reading the output and hoping for the best.

The faster we can generate code, the more important it becomes to have reliable ways to check that code.

4. Understand the business and the economics

There’s another side of software engineering that developers sometimes overlook: the cost of running what we build.

Imagine building an AI-powered feature that works perfectly in a demo but becomes too expensive when thousands of customers start using it.

Technically, it works. As a business, it might be a failure.

We need to understand things like inference costs, latency, failure rates, infrastructure expenses, and the cost of evaluating and maintaining AI systems.

Sometimes, a smaller model or a simple rule-based solution is better than using an expensive AI model for everything.

The goal isn’t to use AI everywhere. It’s to solve the problem in the most effective way possible.

This matters even more when building products for enterprise customers, where reliability, cost, security, and business value all matter.

5. Develop expertise beyond writing code

I think this is one of the most interesting opportunities for software engineers.

An engineer who understands both software and a specific business domain can bring much more value than someone who only knows how to implement technical requirements.

Take insurance, for example. An engineer who understands how claims are processed, where delays happen, and why certain decisions require human approval can identify opportunities that someone without that experience might miss.

The same applies to banking, healthcare, logistics, and industrial operations.

AI can help you build the solution. But understanding the business helps you figure out which problem is actually worth solving in the first place.

And that distinction matters.

The bigger picture

I don’t think software engineers need to panic about AI, nor do I think learning how to use the latest AI coding tool is enough to prepare for the future.

Tools will change. Companies will rise and fall. What seems impressive today might become a standard feature tomorrow.

What I’d focus on is becoming an engineer who can understand a problem, design a solution, build it, verify that it works, and explain why it’s worth building.

AI can help with many parts of that process. In fact, it can make us significantly more productive.

But being able to produce code quickly and being able to take responsibility for a working system are two very different things.

If I had to choose where to invest my time over the next three years, I’d focus less on mastering one particular tool and more on becoming the kind of engineer who can use any tool to solve real problems.