The impact of AI on software engineering has been both swift and significant.

In some ways, engineering has become the coalminer’s canary for the impact AI might have on white-collar professions. We are already seeing the potential for enormous productivity gains, alongside growing questions about quality, security, skills, and ultimately, the future shape of the profession itself.

It is fair to say that the speed at which AI has disrupted software engineering has caught many organisations off guard, particularly when it comes to security. But the rapid announcements of supposedly AI-driven cuts to developer workforces, and the almost equally rapid walking back of some of those claims, have raised another set of questions.

If you are a junior software engineer entering the profession today, what skills should you actually be learning?

And what kind of job will be waiting for you when you have learned them?

These were among the issues raised in the Think Tank session that concluded Clutch Events’ recent Sydney Engineering & DevOps Summit, where Asif Gill (Head of Discipline – Software Systems and Director of the DigiSAS Lab at the University of Technology Sydney), Jeremy Burton (Chief Technology Officer at hipages Group), and Jovana Dunisijevic (Senior Technical Evangelist at Atlassian), discussed what the future might hold for engineering and software development in Australia.

The short answer is that nobody really knows. The pace of change is simply too fast for predictions based on today’s capabilities to remain reliable for very long.

What we can see more clearly are the changes already taking place in software delivery.

• Developers can produce code at a far greater rate than before.
• The increased use of generated code and pre-developed packages has created new security vulnerabilities.
• The bottleneck in software delivery has moved away from code creation towards testing, validation, and review.

But beneath these obvious changes sits a potentially more profound one.

AI is rapidly harvesting the low-hanging fruit of software development, and many of the lower-level, process-oriented tasks that once formed part of the training pathway for junior developers no longer need to be performed by human hands.

That creates an uncomfortable question: if we automate the work through which junior engineers traditionally learned their craft, how do they acquire the experience needed to become senior engineers?

What does “entry level” mean anymore?

Of course, software engineering has always evolved this way. Every era leaves skills behind. Few developers today need to write machine code or worry about many of the technical constraints that consumed earlier generations of programmers.

Perhaps AI simply pushes the definition of “entry level” further up the skills ladder.

But if entry-level work becomes more sophisticated, what sits at the top? What are the highest-value skills an engineer can aspire to develop in a world where increasingly capable AI systems can generate, test, explain, and potentially optimise large amounts of code?

Does the software engineering ladder extend upwards, or does the distance between its top and its bottom begin to compress? That question is much harder to answer because we don’t yet know where those limits lie.

One theme that did emerge clearly from the Think Tank discussion was that an engineer’s value increases significantly when they understand their work through a business lens. That might explain why the term “business engineer” is appearing more often.

The valuable engineer of the future may not simply be the person who can produce the code the fastest. It may be the person who best understands why the code should exist in the first place, how it interacts with the broader organisation, what risks it introduces, and what outcome it is intended to create.

I have a personal attachment to this question.

Many, many years ago, long before I entered technology journalism, I started a degree in digital systems and communications engineering at RMIT. I learned about things such as logic controllers, EPROMs, and differential calculus.

At the time, I couldn’t see what much of this had to do with the work I imagined myself eventually doing. I was told it was foundational knowledge, and that its relevance would become clearer as I progressed.

I never got the chance to find out. I dropped out by the end of my first year.

But what I remember is that each new piece of knowledge provided another fragment of the world I was entering. Even when something had little obvious practical value, it helped explain how the technologies around me had come to exist and how their different components fitted together.

That context matters.

Understanding why things are the way they are can be enormously valuable when trying to understand how different parts of a system interact. It contributes to what we now commonly describe as systems thinking, a capability that almost every employer seems keen to find.

And yet systems thinking is becoming harder to attain. Over the decades, science, technology, and engineering have become increasingly specialised. The depth of knowledge available within individual disciplines has grown enormously, but the ability for any one person to understand how those disciplines fit together has become much harder to develop.

Paradoxically, those who develop that ability may also be becoming more valuable.

This is where the impact of AI on engineering becomes more interesting than a simple discussion about productivity. If we only use AI only to produce more code, faster, we may be missing its greater value.

There is a risk that automation strips away some of the work through which engineers traditionally built knowledge, intuition, and experience. If that happens without us creating alternative pathways for developing those capabilities, we may eventually discover that we have automated away parts of the apprenticeship on which the profession has traditionally depended.

But the opposite outcome is also possible.

AI could remove enough of the repetitive, low-level work to give engineers more time to look beyond their immediate domain. It could allow specialists to explore adjacent disciplines, understand the businesses and systems within which their work operates, and develop the broader perspective that increasingly distinguishes high-value engineers from everyone else.

Perhaps, then, the goal for AI in software engineering should not simply be to help engineers produce more.

It should be to help them see more.