The AI-Enabled Software Engineer. the evolution of the role, not its replacement.

There is a strange thing happening in software engineering right now.

Organisations are buying AI coding tools at an extraordinary rate. Developers are being given GitHub Copilot, Cursor, Claude Code, Codex and an increasingly bewildering collection of AI-enabled development environments. These tools can write code, explain code, refactor applications, generate tests and increasingly take on entire development tasks. Then we declare that we are becoming "AI-enabled".

I'm not convinced.

In many organisations, we haven't created AI-enabled software engineers, we've simply given yesterday's software engineers better tools. Those are two very different things.

For decades, the value of a software engineer was closely associated with their ability to turn requirements into working software. The best engineers were often the people who could solve the hardest problems, write the cleanest code, understand a technology stack deeply or simply get things built faster. That’s no longer the case because AI has fundamentally changed that equation.

The ability to produce code is becoming less scarce. An AI can produce a functioning implementation in minutes. It can generate a test suite, explain an unfamiliar codebase and suggest multiple architectural approaches before a human developer has finished their first cup of coffee. So, if the production of code is becoming dramatically cheaper, what becomes more valuable?

The simple answer is, Judgement.

Knowing what should be built, knowing what shouldn't. Understanding the problem behind the requirement. Knowing what context an AI needs, recognising when its answer is wrong, understanding the architectural consequences of a seemingly simple decision and knowing whether something is secure, maintainable and fit for production.

In other words, the things that make someone an engineer rather than simply a producer of code become more important.

This is where I think many organizations are going to get caught out. We have spent years talking about AI productivity and how much faster can developers work. How many lines of code can they generate? How much time can be saved?

Those are useful measures, but they miss something fundamental. AI doesn’t just make good software faster, it makes software easier to produce. Sadly, that includes bad software!

It includes insecure software, poorly architected software, not to mention unnecessary complexity. It includes solutions that technically satisfy the prompt while completely missing the underlying business problem.

And the worrying thing is that AI can produce all of this at a speed that humans cannot easily match with traditional review processes. If a developer spends three days writing a feature, there is a natural opportunity to think about what they are doing. If an AI agent produces the same feature in ten minutes, the bottleneck moves somewhere else.

Where AI ends, responsibility begins.

This is why we need to start talking about the AI-Enabled Software Engineer. It’s not as a new job title or another certification. It’s certainly not someone who happens to know how to use an AI coding assistant, but represents a seismic change in what we expect from the profession.

The AI-enabled software engineer understands how to use AI throughout the software engineering lifecycle, but remains responsible for the outcome. They understand how to turn an ambiguous business problem into precise intent and how to provide an AI system with the right context. They delegate implementation to an agent and then critically evaluate what comes back.

The engineer of the future will spend less time manually producing every line of implementation and more time defining intent, shaping solutions, evaluating outcomes and orchestrating increasingly capable AI systems. That makes something else increasingly important: the specification.

If AI is going to implement more of our software, then our ability to clearly describe what we want becomes critical. A vague requirement that might once have resulted in a conversation between a developer and a product owner can now become a vague prompt that an AI agent interprets and turns into thousands of lines of code.

The question becomes: how do we know that the ten-minute solution is actually the right solution? That is a very different engineering problem.

The ambiguity hasn't disappeared; we've simply automated its consequences.

The AI-enabled engineer therefore needs to become exceptionally good at expressing intent. Behaviour, constraints, context, acceptance criteria, security requirements, architectural boundaries and non-functional requirements all become increasingly important. This isn't simply "prompt engineering".

It is engineering, and I think this distinction gets to the heart of the transformation. There is a difference between being AI-assisted and being AI-enabled. An AI-assisted engineer uses AI to do their existing job faster.

An AI-enabled engineer changes how they approach engineering because AI exists.

This is where it becomes a bit more difficult for businesses. The answer isn't to buy more AI tools. It is to start treating AI-enabled engineering as a capability transformation programme.

Understand where your organisation is then deciding what AI-Enabled looks like to you, that’s the real starting point. Ask yourselves, are our software engineers ready for a world where writing code is no longer the most valuable thing they do?

Because that world isn't coming.

It's already here.

How QA can help with AI adoption