For a long time, being a strong software engineer meant mastering the technical side of the craft, which included writing clean and maintainable code, understanding system architecture, making solid design decisions, and being able to debug complex issues under pressure. For many people this was the most satisfying part of the job because it was tangible, logical, and deeply rewarding.
Unfortunately, AI has changed that, and the barrier to building software has dropped significantly, creating a new reality. A big part of the “fun” engineering work is now being automated or heavily assisted.
Engineers are still expected to be technically strong, but now they also need to validate, challenge, and often redesign things that were already “built”, constantly reading code they did not write themselves. They spend more time in meetings, more time aligning with stakeholders, and less time just writing code. More and more is expected from them, almost like being a one man army, while at the same time human context is limited, and it becomes increasingly difficult to stay deeply technical when that knowledge is being used in a completely different way.
What is required from engineers today is shifting in a very clear direction:
1. Asking the Right Questions
You can generate code faster, prepare analysis quicker, and even create content almost instantly, but someone still needs to decide whether this is the right direction, whether the solution actually makes sense, and whether it solves a real problem.
This is where engineers can create real value today, because instead of jumping straight into implementation, they need to challenge assumptions, verify what problem is actually being solved, and identify gaps that are not visible in AI generated outputs.
Very often, this means questioning things that already look “done”, which is uncomfortable but necessary if the goal is to avoid building the wrong solution.
2. Decision Making Under Uncertainty
AI outputs are fast and convincing, but they rarely come with full context, tradeoffs, or long term thinking, which means engineers are constantly making decisions with incomplete information.
Choosing whether to extend an AI generated solution or rebuild it properly is not just a technical decision, but a tradeoff between speed, risk, and future cost. Engineers who can navigate this uncertainty and make conscious decisions, instead of blindly following the easiest path, have significantly more impact on the final outcome.
3. Communication With Stakeholders
Modern engineering is no longer isolated from the rest of the business, which means engineers need to communicate with people who do not think in technical terms. Saying that something has “bad architecture” is not enough.
Explaining that a certain decision will slow down development, increase maintenance costs, or introduce risk is what actually influences priorities. The ability to translate technical complexity into business impact is what moves engineers from execution to influence.
4. Connecting Context and Taking Ownership
AI can generate solutions, but it does not understand the full context in which those solutions operate, especially when it comes to combining business goals, user needs, and system constraints.
This is why engineers are expected to connect these perspectives and take responsibility for the final outcome, not just the code itself. It is no longer enough to deliver something that works, it needs to make sense in a broader context.
The Problem With Soft Skills
The biggest issue is not that soft skills are unimportant, but that they are often defined in a vague way. Companies talk about better communication, more ownership, or higher proactivity, but without clear examples it is difficult to understand what that actually means in practice.
It comes down to a simple question:
how can you realistically expect something from people if you are not able to measure it, observe it, or describe it in a concrete way?
From my experience, one way to solve this is to approach the competency matrix differently and build a process around it, where the matrix becomes the core. If expectations are translated into clearly written requirements, both technical and soft, it becomes much easier to assess where someone should grow and how to support them. That support can then be very concrete, whether it is allocating a higher development budget, investing time in books or conferences, or creating space to intentionally build specific skills.
Here is a general example of a System Design and Soft Skills Matrix.
Final Thoughts
From an engineer’s perspective, it is becoming obvious that the job is no longer just about writing code. There is more context to understand, more decisions to make, and while AI speeds things up, it also adds noise that someone has to filter, challenge, and validate to make sure it actually makes sense in the long run.
At the same time, humans still have their limits, and it is becoming harder to stay deeply technical when more and more time is spent on alignment, discussions, and decision making. We are still in the middle of this shift, and the market needs time to adapt, including changing its approach in areas like interviews.
Focusing on the reality today, soft skills are no longer optional, they are required, and one practical way to deal with that is to define them clearly in a skills matrix, in the same way technical documentation is written in a project... so expectations are explicit instead of assumed.
