Like it or not, AI is revolutionizing the way we approach writing software. And yet, I’m convinced that Software Engineers still have many good years ahead of them, just not quite in the role we’ve known. The question isn’t whether our profession will survive this wave, but how it redefines itself around it.
Our job was never to write code
Before talking about AI, we need to recall something obvious that’s often forgotten: our job was never about writing code. It has always been about co-building solutions aligned with product and business needs. Creating alignment, understanding the real needs, talking with users to put effective and relevant solutions into their hands. Applying engineering, innovation, and creativity to develop those solutions under the constraints we’re given, within the organizations we’re placed in.
When you think about it, the way we get there has always been, from a business standpoint, an implementation detail. A detail that certainly carries plenty of weight and its share of stakes, because it determines how a piece of software meets needs, evolves, and is maintained over time. A detail that, to be fully mastered, undeniably requires expertise and experience, the very ones that will always need to be put to good use.
It’s this distinction that sheds light on everything that follows. If the core of the value never lay in typing the code but in the judgment that precedes it, then automating part of the writing doesn’t make the engineer disappear. It shifts the center of gravity of their work.
Expertise as leverage, not as casualty
Today, the people who have solid fundamentals in Engineering, Architecture, Software, and System Design will be able to capitalize heavily on this revolution. That’s precisely why I encourage everyone to keep going down this path: at the end of the day, we’re still the ones laying the rails that we run the AI Agents on.
An agent doesn’t decide on its own where the boundary between two business contexts lies, nor the contract of an API, nor the migration strategy for a legacy system. It executes, suggests, accelerates, but within a frame that someone has to think through. The cheaper code generation becomes, the more the quality of that frame becomes decisive. Expertise, then, isn’t the casualty of this transition: it’s its leverage.
That way we’ll be able to keep doing what we’re here for: co-building solutions aligned with business needs and aiming for full customer satisfaction. But the means of getting there will, in my view, be vastly different, and will keep evolving drastically.
Write less, ship faster
The most concrete change is right here: we’ll probably spend less time writing code ourselves, and more time finding ways to reach our goals faster. Testing, changing direction, reducing time-to-market, evolving architectures and technologies. Code stops being the bottleneck; it goes back to being what it always should have been, a means to an end.
What used to be a prohibitive cost is now within reach. A few examples of what’s now at hand:
- Building solutions in a few hours, including for non-technical profiles, and I’m not talking about no-code, but real software.
- Evolving or migrating software in a few prompts. Migrations that were until now major roadblocks, because they involved a considerable cost, are becoming affordable.
- Reproducing existing products that took several years to develop, in just a few weeks.
- Building and validating the relevance of a SaaS in a few prompts, where the upfront effort used to be a deterrent barrier for many.
And many other things that once stood as so many obstacles. Where some see a threat, I mostly see a multitude of opportunities to harness the capabilities of this new world. The barrier to entry for experimentation is collapsing, and with it a large part of the risk that held innovation back disappears.
A veteran’s perspective: Salvatore Sanfilippo
Salvatore Sanfilippo, creator of Redis and with nearly thirty years of experience, perfectly summed up how writing software has recently changed for him. His words are worth more than any paraphrase:
Anyway, back to programming. I have a single suggestion for you, my friend. Whatever you believe about what the Right Thing should be, you can’t control it by refusing what is happening right now. Skipping AI is not going to help you or your career. Think about it. Test these new tools, with care, with weeks of work, not in a five minutes test where you can just reinforce your own beliefs. Find a way to multiply yourself, and if it does not work for you, try again every few months.
Yes, maybe you think that you worked so hard to learn coding, and now machines are doing it for you. But what was the fire inside you, when you coded till night to see your project working? It was building. And now you can build more and better, if you find your way to use AI effectively. The fun is still there, untouched.
The message is crystal clear: refusing what’s happening gives us no power over the direction things take. The only useful stance is to try seriously, not a five-minute test meant to confirm our biases, but a genuine effort, spread over several weeks, to figure out how to multiply ourselves. And if the fire that drove us when we coded into the small hours of the night was the fire of building, then it remains intact: we can now build more, and better.
Conclusion
AI doesn’t eliminate the engineer’s role; it redraws its outline. What it automates is the most mechanical part of our work, typing the code, not the part that truly creates value: understanding the needs, designing the architecture, laying the rails. The more trivial code generation becomes, the more judgment, experience, and systems thinking become precious.
The right reflex, then, is neither denial nor resignation, but clear-eyed experimentation. Those who invest in learning to multiply themselves with these tools won’t lose their profession: they’ll be practicing its most essential part, faster and at a greater scale than they ever thought possible.