Skip to content

The role of the software engineer in the age of AI

AI doesn't take your role away — it moves it up

By Nico BorromeiPublished August 4, 20265 min
Nico Borromei
Nico BorromeiSoftware Engineer · Qurable

The good news is that it moves upward. The engineer's value has moved away from how something is implemented and toward what's worth building and why. We live that change internally as an opportunity to evolve engineering.

How skills in software engineering evolved

For years, the core skill of an engineer was concentrated in implementation: mastering a language, writing clean and efficient code. That was the hard part and the most valued. Knowing how to do something was the differentiator.

AI shifted the weight of that balance. A large part of mechanical work (the syntax, the first version of a function) now gets resolved faster and with less friction. What can't be delegated is judgment: understanding the problem before writing a line and anticipating where something will break.

The engineer's skill shifted toward where it was always hardest to acquire. Less weight on syntax, more on judgment: knowing what code makes sense to write.

Ownership: the engineer also thinks about the product

Here, a feature isn't just a ticket to close. When you own a feature, you go beyond "how do I implement it" and get into "how should it be." This technical closeness brings a different perspective to the product. Where are the hidden costs? What decision today will complicate things in six months? That's why we encourage everyone, from any role, to propose improvements and ask these kinds of questions.

Real ownership appears when the engineer stops waiting for direction and starts contributing: raises key points and negotiates trade-offs with product until finding the balance between what's technically solid and what delivers user value. Product and engineering end up in the same conversation, with two perspectives that complement each other.

This is, for us at Qurable, entrepreneurship with commitment and enthusiasm. We don't wait to be told what to do — we seek to understand the "why" behind each request and take responsibility for the outcome.

— Nico Borromei

AI as a reach multiplier

AI-assisted development changed the scale of what's possible. And the key is that it's not about working more, but reaching further — thinking the solution "from above." A single engineer can be involved in multiple initiatives at once and accumulate knowledge from different clients in parallel, something that was previously unthinkable due to pure time limits.

That reach sharpens product judgment. Being across multiple projects at once allows you to see patterns: when different clients face similar needs, you start detecting them. That's how the rewards portal emerged — a response to a recurring need among clients who didn't have that solution. From that shared pattern, a prototype was born that's now part of the product. Not from a roadmap, but from being immersed in several problems at once and recognizing the same pain repeating.

And that's where AI makes the difference: it accelerates discovery, lets us iterate and solve on the fly, and validate faster what the client really needs. At its core, it's about changing with change: moving forward with more doubts than certainties, taking calculated risks with available information, and letting the solution evolve iteration by iteration instead of waiting to have it perfect before starting.

When you combine ownership and reach, the engineer stops resolving tickets and starts doing product intelligence. That's the point of getting involved with the client's problem. We don't engage with a specific requirement — we engage with the underlying problem. When you understand it as well as the client (or better), you stop delivering what they ask for and start anticipating what they need.

The conversation that doesn't end

If AI writes more and more code, the engineer's value lies in everything that surrounds the code: getting into the business, understanding why the client needs what they need, anticipating technical risks before they become problems. And deciding what to build today and what will age poorly.

None of this is built in isolation. The one who owns a feature needs to discuss it with product; the one who prototypes a solution needs others' feedback to validate it. The more code AI handles, the more time we have for the human part of the work — and that's where the best ideas emerge.

What if AI, instead of isolating us, ends up amplifying our more social side? Inside, we're already seeing it: good engineering is a conversation that never ends.

Frequently asked questions

Mechanical work gets done faster and the weight shifts to judgment: understanding the problem, anticipating risks and deciding what code makes sense to write.

Owning a feature beyond how to implement it: asking how it should be and negotiating trade-offs with product until what is technically sound balances with what brings value to the user.

As a reach multiplier: it accelerates discovery, enables faster iteration and lets the same engineer take part in several initiatives at once.

From a need that kept repeating among clients that didn’t have that solution. That shared pattern produced a prototype that is now part of the product.

Want to see how this applies to your business?

We explore your case in 30 minutes. No commitment, just clarity.