AI Isn't Coming for Your Job. It's Coming for Your Advantage

Let me start without anesthesia: I think we're facing one of the deepest shifts in the history of software. But not for the reason everyone keeps repeating.

The question is not whether AI will replace developers. That question is comfortable, almost reassuring, because it casts you as a victim just waiting for the verdict. The real question, the uncomfortable one, is this: what happens when building software stops being a competitive advantage?

That's where the conversation actually worth having begins.

When writing code stops being the value

For decades, software had a crystal-clear barrier to entry: building it was hard.

A company had an idea. To turn it into code it hired developers, formed teams, invested months, and took on technical risk. We were the only ones who could turn an intention into a working product. That difficulty was our wall. And we lived comfortably behind it.

AI is tearing that wall down.

Today, a person with enough context builds in hours what used to take days or weeks. Not with the same quality, security, or maintainability—watch out for that—but the initial barrier is falling. And when a skill becomes more accessible, its economic value changes. Always.

Think about what happened with digital photography, video editing, or graphic design. The professions didn't disappear. What changed was which activities were scarce and which ones people were willing to pay for.

Code is becoming a means of production, not the final product of our knowledge. That doesn't mean programming stops mattering. It means something subtler and more dangerous: that knowing how to program, on its own, might stop setting you apart.

So where do we sit in the chain now?

My hypothesis is that we're moving from being software builders to being people responsible for getting results through software. Look at how the position evolves, from the bottom up:

1. The executor — "Tell me what to build and I'll code it." Writing code, implementing components, solving well-defined tasks. Increasingly automatable.
2. The systems engineer — "I decide how it should work and what can fail." Architecture, integration, security, observability, performance, reliability. Generated code needs technical judgment too.
3. The solution designer — "I identify the right problem and design the solution." Understanding the business, questioning requirements, weighing alternatives, coordinating whoever (or whatever) does the execution.
4. The owner of the outcome — "I'm accountable for this producing value." Connecting technology with revenue, costs, user experience, risk, and product decisions.

I don't think we all have to become managers or founders. Nor that these levels replace each other in a straight line. An engineer can keep programming most of the day and still be extremely valuable.

The difference is where that value rests: less and less on how much code you produce, more and more on the decisions you make, the problems you avoid, and the results you deliver.

And here's the unsettling part: we may need fewer engineers

Let's be honest, because this is what almost nobody says to your face.

There's no guarantee that the extra productivity creates more jobs for developers. And this isn't a distant forecast: it's already happening. Companies that used to need ten people to build and maintain a product now get similar results with four. Teams shrinking, costs being cut, and more and more decisions handed off to AI.

Does that mean the apocalypse? Not necessarily. That same company can also build products that weren't economically viable before, opening up new opportunities. Both things can happen at once. The uncomfortable consequence is this: we could end up with more software in the world and, at the same time, fewer jobs dedicated to producing it.

That changes the rules of professional competition. Before, a company justified a large team because it needed execution capacity. If that capacity multiplies, keeping the same headcount stops being an obvious decision.

The question you'll hear more and more won't be "how many developers do we need?". It will be:

"What results do we need, and what's the smallest team that can deliver them?"

We don't know how far this process goes or at what pace. But building your career assuming today's structures will stay intact strikes me, right now, as a mistake.

So what should we become?

I'd bet on five capabilities. And pay attention to which one I'm saving for last, because I think it's the one almost nobody is watching.

1. Deep technical judgment. You don't need to memorize more syntax than a model—you already lost that race, and that's fine. You need to spot when a solution is wrong, fragile, insecure, or too expensive. Reviewing, verifying, and debugging complex systems can be worth far more than producing code fast.

2. Product thinking. Understanding why something is being built. What problem it solves, who needs it, how success is measured. AI helps you implement a solution; it doesn't guarantee you're solving the right problem.

3. Orchestrating systems and agents. Moving from doing every task with your own hands to designing workflows where agents research, code, test, and review. Your job becomes setting boundaries, validating results, and knowing when to step in.

4. Communication and decision-making. Turning ambiguous problems into concrete decisions. Defending an architecture, negotiating priorities, explaining risk, getting a team to move. When execution speeds up, this turns to gold.

5. Ownership and distribution. Knowing how to build is one thing. Having access to customers, an audience, distribution, or a stake in a product is a very different one. If building gets cheaper, finding who your work actually serves may be an even bigger advantage.

The last one strikes me as the most important. Because there's a huge difference between being the person who builds another company's product and being the one who owns the relationship with the users, decides what to build, and captures part of the value. Not everyone has to start a company. But depending exclusively on a company needing your programming hours is an increasingly risky bet.

The trap: chasing the next trend

And here's where you need to be careful, because there's a false exit that feels like the solution.

It looks like it's enough to learn to use agents, master prompting, know the latest model, or switch editors every three months. That helps. But there's a paradox you have to see: if we all learn to use the same tools, that skill stops setting you apart and becomes a baseline requirement.

Today, knowing how to use AI distinguishes you. Tomorrow it'll be as expected as knowing how to use Git. That's why I split capabilities into two groups:

• The ones that depreciate: specific syntax, repetitive manual workflows, knowledge of tools that change every quarter.
• The ones that compound: judgment, experience with real systems, domain understanding, trust, reputation, relationships, knowledge of your users.

It's not an absolute split—technical fundamentals will stay useful for a long time. But invest more in what compounds over the years than in chasing what's trending this quarter. That last one is a treadmill: you run like crazy to stay in the same place.

And now a more uncomfortable, almost philosophical question

For a long time we built part of our identity around a hard-to-acquire skill. We solved problems others couldn't. We built things others didn't even understand how to make. That skill gave us autonomy, recognition, and often a good economic position.

What happens when a big part of that capability stops being exclusive?

I think that's where two different crises appear, and it's worth not confusing them:

• The economic one: how do I make money in a market that needs fewer human work hours?
• The personal one: who am I when a skill that defined me stops being exceptional?

And I suspect the second is the harder one to resolve. Because if your value depends on being better than a machine at writing code, you're competing on ground that shifts under your feet every single day.

But if your identity rests on understanding problems, building useful things, learning, collaborating, and taking responsibility, then programming is still an extraordinary tool. Maybe more powerful than before.

We don't have to defend the value of writing code. We have to figure out what we want to do with the ability to build almost anything.

My bet, if you have engineering experience

I wouldn't abandon engineering to become some supposed "AI expert." I'd do exactly the opposite: I'd use AI to extend the reach of my experience.

I'd try to become someone capable of:

• Designing a complete system and explaining why it should exist.
• Directing agents to speed up its construction without losing control.
• Evaluating quality, security, cost, and reliability.
• Understanding the business well enough to prioritize properly.
• Shipping products and checking whether anyone actually needs them.
• Building assets of my own: products, intellectual property, reputation, distribution.

The combination is powerful because it joins technical capability, judgment, and autonomy. And no, not everyone needs to reach VP of Engineering, enterprise architect, or founder. There can still be an excellent technical career for people who enjoy solving complex problems. What we do need to question is whether the traditional paths will keep rewarding the same skills in the same way.

My goal wouldn't be to be the developer who produces the most code. It would be to be someone who can turn an ambiguous opportunity into a real result, with fewer resources and less dependence on others. Not because I want teams to disappear, but because I want to have options when the way we work changes.

And I want to close by passing the ball back to you, because this conversation isn't solved by reading, it's solved by thinking. Out of this whole future, what actually worries you the most?

• That there'll be fewer jobs and lower salaries?
• That your experience and knowledge lose their value?
• That wealth concentrates in a few companies and people?
• Or that programming stops giving you the meaning and satisfaction it used to?

Answering one versus another isn't the same, because each leads to a different strategy. I already told you where I stand. Now it's your turn. Tell me in the comments: let's keep the conversation going there.