Do I need an AI Builder or an AI Enabler?

What 1,000+ live roles, four salary sources, and our own market data reveal about the AI hiring problem nobody's naming.

The biggest frustration I get from CTOs and HOEs when they're hiring an AI engineer isn’t the lack of AI engineers applying: it’s there’s too many of the wrong ones.

The problem

“AI Engineer” isn't one job. It's two very different people wearing the same title.

Builders. Data science, ML research, or PhD-level background. They understand what's actually happening inside the model, not just how to call it. They can architect a system from first principles, and they're the ones genuinely shipping production AI products, not just integrating someone else's.

Enablers. Software engineering background. They're fluent in using AI: prompting, fine-tuning, wiring models up via API, getting real value out of tools that already exist. But they've never built or shipped a genuine AI product end to end. They're building with AI, not building AI systems.

Both call themselves AI Engineers. Both will apply to your job ad. And they will not do the same job for you.

This isn't a semantic argument. It's a market failure. And the data backs it up.

What a Builder actually looks like

A few months ago I was talking with a CTO who heads up the Agentic AI R&D function for one of the most successful tech businesses Australia has produced. The conversation turned to hiring, specifically, what he looks for in AI engineers building LLMs to support R&D for professional services.

RAG came up straight away.

For anyone who doesn't know it: RAG, Retrieval-Augmented Generation, is how an LLM gets access to external knowledge instead of relying only on what it learned during training. It solves the two biggest problems with LLMs, hallucination and stale knowledge. Retrieve. Augment. Generate.

What he actually cared about wasn't whether candidates could use AI tools. It was whether they understood how those tools are built, and what it takes to build native AI products properly. Knowing when to use RAG is one level. Knowing when not to use it is the next.

That distinction is the clearest, most testable definition of a Builder I've come across. It's not a personality type or a vibe from a resume, it's a ladder you can actually interview against.

What separates senior from junior and mid isn't the tools. It's understanding what the thing you're building actually means for the business, risk versus reward, cost versus payoff, ROI. Having the projects and the experience is one thing. Being able to explain that clearly to an employer in an interview is another. That gap is what separates candidates in today's market, and it's exactly what the CTO was screening for.

This is what a Builder looks like in practice. Not a job title or a computer science degree as a proxy, but a specific, examinable progression from can-follow-a-tutorial to knows-when-not-to-use-the-tool-at-all. The candidates who consistently clear the senior bar tend to have real depth in model architecture and optimisation behind them, whether that's a data science background, an ML research background, or a PhD. That's not a coincidence, and it's a pattern we see across our own pipeline too.

Most industry commentary gets this backwards

Most of what's published about AI Engineers versus Data Scientists assumes the AI Engineer is the practical one and the data scientist is the theoretical one, stuck in a notebook while the engineer ships. It's a tidy story. It's also not what we're seeing.

Right now we're representing a candidate with two PhDs, one in mathematics, one in computer science, with published research on model quantisation and on reducing hallucinations by keeping model behaviour “on-manifold.” A decade building production ML at a global platform business, matching live inventory to demand across more than a thousand partners. More recently, building an optimisation model for a telco that measurably cut operating costs through automation.

That's not a theorist. That's the most production-ready Builder in our current pipeline, and the research depth is exactly what makes the difference: understanding why a model fails, not just noticing that it did.

Most of the online commentary hasn't caught up to this. It's still describing a market where the software engineer is inherently the practical one and the PhD is inherently the impractical one. In AI hiring right now, in our experience, it's often the reverse: the software engineers are the ones fluent in using the tools, and the deep researchers are the ones who actually understand how to build them.

Worth being straight about what this is and isn't. It's not a universal law, it's a pattern we're seeing in the current market and in our own candidate pool, and it's worth testing against your own pipeline rather than taking on faith. But it changes who you should be looking at when the job is genuinely architecture, not integration.

The observation

Start with the volume. Right now there are over 1,000 roles live on SEEK carrying some version of “AI Engineer” in the title, and more than 1,200 if you widen the net to “Artificial Intelligence Engineer.” Sydney alone accounts for close to 900 of them. LinkedIn's own Jobs on the Rise data has AI Engineer as the fastest-growing job title in Australia for 2026, and Small Business Connections puts that growth in the order of 150% since 2023.

Then look at what those roles actually pay. Levels.fyi puts the median AI Engineer in Sydney at around $113,000, but switch the title to Machine Learning Engineer for what is often the same day-to-day work, and that median jumps to around $163,000 nationally. Glassdoor has Sydney AI Engineers landing between $106,250 and $161,250, the middle half of reported salaries, with an average of $128,500. Indeed's national average for AI Developer roles sits at $125,000–$127,000. Our own market work puts senior AI engineers in NSW at $180,000 to $210,000+, and lead-level at $210,000 to $240,000+.

Same title. A spread of well over $100,000. That's not a salary band. That's two different jobs, priced by two different hiring managers, who both think they're buying the same thing.

We built a full TAM/SAM/SOM model earlier this year to size this properly. Start broad, with the ABS category for software and applications programmers across NSW, VIC and QLD: roughly 150,000 people, on a median of around $130,000. Narrow that to people genuinely working in AI, ML or data engineering roles: about 10,000, averaging $165,000. Narrow again to senior and lead engineers who've actually shipped production LLM or multi-agent systems: around 1,500 people nationally, averaging $195,000.

Fifteen hundred people. That's the pool every bank, every scaleup and every enterprise transformation team in the country is drawing from at the same time.

Regional pay bands

Break that senior and lead pricing down by state, and Sydney carries a consistent premium over Melbourne and Brisbane at every level.

The implication

Here's what it costs you when you get the distinction wrong.

You hire a Builder when you needed an Enabler, and you've got someone spending three weeks architecting a custom solution to a problem a well-configured prompt would have solved by Friday. You hire an Enabler when you needed a Builder, and you've got someone who can wire up an impressive demo, but hits a wall the moment the model starts failing in a way they don't have the depth to actually diagnose.

And the cost isn't evenly spread. It lands hardest on the companies that can least afford to get it wrong.

If you're a founder pitching this hire to a board, you don't get a second attempt. You get one hire, one budget line, and one round of “why isn't this working” if you picked wrong.

If you're inside an ASX-listed business, it's worse again. The headcount business case has already been through finance, through the executive committee, and possibly through the board itself, before the job ad even goes live. Nobody wants to go back to that room and explain why the person they fought for isn't delivering.

And if you're a smaller, well-funded scaleup, the instinct is often to hire the most impressive resume in the pile. That's frequently the Enabler, the one with the flashy AI-native product portfolio and genuinely fluent prompting skills. Impressive on paper. But if what you actually need is someone who understands the model well enough to fix it when it breaks, you've just spent your one hire on the wrong archetype.

So before you write the ad, answer this instead: are you trying to build something new, or get more out of what you already have?

• Standing up a net-new AI product or system from scratch: you need a Builder. Someone who thinks in architecture and can own the thing end to end.

• Trying to extract more value from tools and models you've already licensed, better RAG, better prompting, faster iteration: you need an Enabler.

Most businesses don’t need both.

What we are noticing as the technology world adopts enablers to better enhance and improve productivity is the sheer speed at which they complete complex software engineering tasks. It’s incredible to hear stories about how a 2-week sprint cycle feels like a marathon. Six months ago this simply was not possible!

Before you write the ad

Remember the most important question you can ask yourself is: are we trying to build something new, or get more out of what we already have?

People complain a lot about the responses that they are getting from advertising for an “AI Engineer.” Don’t let it be you. Learn from their frustrations.

Please feel free to use what’s in this article to help you write a better job ad. If you don’t want to do that, I highly suggest partnering with someone who can help you identify and attract the people you need.

PS: if you want a second opinion on which archetype your next hire actually needs, I'm always happy to talk it through.

About the author

Sam Elderfield is Co-Founder of ScaleUp Recruitment, an Australian recruitment firm specialising in AI and software engineering hiring, with a strong focus on the Sydney market. His work is built on live market data, direct candidate and client conversations, and ScaleUp's own AI Engineering Market Intelligence Report.

ScaleUp Recruitment places both Builders and Enablers into AI-native startups and enterprise businesses adopting AI, helping hiring managers work out which archetype a role actually needs before they go to market, not after a bad hire.

Website: www.scaleuprecruitment.com.au

Email: sam@scaleuprecruitment.com.au

Sources: job volume & market growth

SEEK.com.au, “AI Engineer” and “Artificial Intelligence Engineer” job search results, Australia and Sydney NSW, October 2026.

LinkedIn “Jobs on the Rise” 2026 (Australia), as reported by Information Age (ACS) and HR Leader, January–June 2026. Growth figure as reported by Small Business Connections, 2026.

Sources: salary benchmarks

Levels.fyi, AI Engineer and Machine Learning Engineer, Sydney and Australia, accessed 2026.

Glassdoor Australia, AI Engineer salary data, Sydney, March 2026.

Indeed AI Developer national average, as cited via ACS reporting and Nucamp's 2026 Australian tech salary roundup.

Proprietary data

ScaleUp Recruitment, 2026 AI Engineering in Australia Market Intelligence Report.

Sources: taxonomy & industry commentary (contrasted, not confirmed)

These sources represent the conventional framing this article argues against, included for transparency, not as supporting evidence:

Chip Huyen, AI Engineering (O'Reilly), interviewed on The Pragmatic Engineer podcast, Gergely Orosz.

TechTarget, “AI engineer vs. data scientist: What's the difference?”

KDnuggets, “Data Scientist vs AI Engineer: Which Career Should You Choose in 2026?”

If you would like to chat more about the topics covered in this blog, or require any help, please reach out to us via our Contact Us page or email info@scaleuprecruitment.com.au.