AI isn't the first technology to disrupt software engineering. The real surprise is how many people forgot that constant change was part of the job.
I recently came across an excellent LinkedIn post by Gergely Orosz, the author of The Pragmatic Engineer.
He makes an interesting argument about why software engineers have traditionally enjoyed rather extraordinary working conditions compared with many other engineering professions.
High salaries. Stock options. Remote work. Relatively easy international mobility. Generous benefits.
Not everywhere, obviously, but enough to make software engineering one of the more privileged professional fields of recent decades.
And Gergely suggests that a substantial part of this premium comes from something people have rather conveniently forgotten.
The profession requires you to keep learning. Constantly.
Not just to get into the industry.
To stay in it.
The rather expensive privilege of never being finished
Consider a civil engineer.
Bridges don't suddenly become obsolete because somebody released Bridge Framework 4.2 with an entirely new architecture and deprecated concrete.
An electrical engineer doesn't ordinarily wake up to discover that electricity has switched to a subscription model.
Of course, these professions evolve. Materials change, regulations change, technologies improve, and engineers must update their knowledge.
But the underlying principles tend to have a reasonably long shelf life.
Software engineering has always been different.
Languages come and go. Frameworks rise, dominate the conversation, and become embarrassing historical artefacts. Entire development paradigms change.
Yesterday's revolutionary architecture becomes tomorrow's technical debt.
And there's always somebody on the internet explaining that everything you've been doing for the past five years is fundamentally wrong.
Usually with considerable enthusiasm.
The point Gergely makes is that the ability and willingness to absorb these changes quickly is itself part of the profession.
You're not simply being paid to know something.
You're being paid to keep becoming useful as the definition of useful changes.
Then the industry became comfortable
There's another observation in his post that I find particularly interesting.
For roughly ten to twenty years, large parts of the software industry experienced a period of relative stability.
Not technological stagnation, certainly.
But a kind of professional predictability.
Learn a popular stack. Build experience. Move between companies. Negotiate a better salary. Perhaps work remotely from somewhere pleasant.
The tools changed, but for many developers the basic professional bargain remained remarkably consistent.
And when something continues long enough, people start treating it as a permanent feature of reality.
High salaries become normal.
Remote work becomes an entitlement.
Demand for engineers becomes something that will presumably last forever.
The obligation to reinvent yourself periodically fades into the background.
Until something arrives that doesn't merely introduce another framework.
It changes how software is produced.
Hello, AI.
Machine learning people might have a different perspective
One part of this discussion particularly resonates with me.
Look at machine learning specialists.
For many of them, those supposedly stable years weren't particularly stable at all.
The field kept changing.
New research. New architectures. New training methods. New libraries. New hardware. New approaches that made previous approaches significantly less interesting.
Keeping up wasn't an occasional professional development exercise.
It was practically a lifestyle.
And not everybody enjoyed it.
I know people who left technical professions precisely because of this relentless requirement to keep learning.
Not because they weren't intelligent enough.
Not because they couldn't understand the new technologies.
They were simply tired of running.
There's a substantial difference between enjoying learning and accepting that your existing expertise may have a surprisingly short commercial half-life.
The latter can become exhausting.
And perhaps that's one reason why many people already working in machine learning were relatively well positioned for the latest AI wave.
They weren't necessarily better engineers than everybody else.
But they were accustomed to the ground moving beneath their feet.
For them, another technological earthquake was not exactly a novel experience.
But rapid change alone doesn't explain the money
Here's where I'd add a qualification to Gergely's argument.
If professional compensation were primarily determined by the speed at which an industry changes, journalists would be spectacularly wealthy.
And graphic designers would probably own most of Europe by now.
Both professions have experienced enormous technological disruption.
Neither has consistently enjoyed software engineering's compensation premium.
So what makes software different?
Part of the answer is economics.
Software can be reproduced and distributed at extremely low marginal cost. A relatively small engineering team can create a product used by millions of people.
And the commercial value generated by that team can be enormous.
Technology companies have also benefited from venture capital, equity compensation, global distribution and unusually strong competition for specialised talent.
Remote work is easier partly because the product and the work itself are digital.
The ability to learn rapidly doesn't create all these advantages on its own.
But it helps explain who can continue participating in them when the technological foundation changes.
The economics creates the premium. The ability to adapt helps you keep it.
And that distinction matters.
AI isn't another framework
There's a temptation to interpret the current AI wave as just another technological transition.
Learn a new tool.
Add a new library.
Update your résumé.
Carry on.
I think this underestimates what's happening.
AI-assisted development changes the allocation of work between humans and machines.
Writing routine code is becoming easier. Generating prototypes is becoming dramatically faster. Tasks that previously required substantial implementation time can sometimes be completed through a combination of specification, generation and verification.
But easier code generation doesn't automatically mean easier engineering.
Someone still has to understand what should be built.
Why it should exist.
Whether the generated result works.
Whether it's reliable, maintainable and secure.
And whether it solves a problem worth solving in the first place.
In my own work with AI-assisted development, this shift has become increasingly obvious.
The most important question is often no longer how quickly I can produce an implementation.
It's how accurately I can define the problem, organise the work, evaluate the results and decide what deserves to survive.
The tools have made producing things easier.
They haven't eliminated the need for judgement.
If anything, they've made bad judgement considerably more productive.
Which is a fascinating problem.
Learning is part of the job, not an extracurricular activity
There's a familiar professional attitude that goes something like this:
I've spent years becoming good at what I do. Why should I have to learn everything all over again?
It's an understandable question.
But in software engineering, it's also a rather dangerous one.
The value of accumulated experience doesn't disappear when technology changes.
Understanding systems, failure modes, users, businesses and trade-offs remains valuable.
But experience has to remain connected to the tools and realities of the present.
Otherwise, expertise gradually turns into nostalgia.
And nostalgia, wonderful as it is, doesn't always pay the electricity bill.
That doesn't mean engineers should chase every new model, library or fashionable methodology.
Constant motion is not the same as adaptation.
The skill is knowing which changes matter, learning what is necessary and integrating it into useful work.
Sometimes that means adopting a new tool immediately.
Sometimes it means ignoring an entire wave of hype.
But both decisions require paying attention.
The premium has a price
I think this is the part of the software engineering discussion that often gets overlooked.
Continuous learning sounds wonderful when you're young, curious and excited about everything.
It sounds rather different after twenty years, a family, a mortgage, several exhausting projects and yet another revolutionary technology that everybody insists will change the world by Thursday.
There's a genuine psychological cost to professional instability.
Some people love it.
Some tolerate it.
Others eventually decide they've had enough.
And that's perfectly reasonable.
Not everybody wants to spend their entire working life reinventing themselves.
But perhaps the industry should be more honest about what its privileges require.
Software engineering has never been simply a profession you learn once and then practise unchanged for forty years.
For many roles, the learning never stops.
And neither does the uncertainty.
The job was never just writing code
I think Gergely's central argument is largely right.
AI isn't necessarily the end of software engineering.
But it may be the end of a particularly comfortable interpretation of what being a software engineer means.
The profession has always rewarded people who can turn changing technology into useful products.
That's still the task.
Only the tools, the pace and the expectations have changed.
Some engineers will adapt and discover entirely new opportunities.
Some will resist.
Some will leave the profession, just as people have left other rapidly changing fields before.
And some will discover that their accumulated experience makes them considerably more valuable when combined with new capabilities.
There's no guarantee of a happy ending for everybody.
But there never was.
The premium was never simply for knowing how to code. It was for remaining useful when the way we build software changes.
And perhaps the most surprising thing about the AI revolution is how many people had forgotten that part of the contract.