AI engineering titles have become fairly useless. After enough searches, the more revealing question is normally why a role appeared — what became difficult enough that somebody finally needed to own it.
This is about what companies are actually handing to AI, the problems that appear as they hand over more, and what those problems are doing to the people they try to hire. It gets into FDEs, Australia’s supposed talent shortage, whether every role really needs to be senior, and the possibility that sometimes the right hire is nobody.
I've spent a slightly unreasonable amount of this year looking for engineers who build with AI. Some for frontier labs, some for startups where AI is basically the whole point of the company, and some for businesses that were around long before ChatGPT and are now trying to work out which bits of what they're being told are actually useful.
The jobs have been all over the place.
I've worked on roles where someone needs to sit with a customer, understand a fairly horrible business problem, build an agent around it and get the thing working in production. Others where the hard part isn't the agent at all, it's building the platform underneath so twenty other engineers can build theirs without each inventing their own version of observability, evalsEvals — the tests and scoring harnesses used to measure whether a model or agent is actually behaving well, since you can't just assert-equals your way through probabilistic output. and permissions. Then there are companies where none of that matters yet because they're still trying to make the model do something reliably enough that a customer would actually pay for it.
They're all hiring AI Engineers.
Well, some are hiring Applied AI Engineers. Others are hiring AI Product Engineers. Forward Deployed Engineer has become particularly popular, to the point that I think we're now legally required to call anyone who writes code within fifty metres of a customer an FDEFDE — Forward Deployed Engineer. An engineer embedded close to the customer: discovery, build and rollout in the customer's real environment rather than behind a product spec..
I've contributed to this, so I can't really complain.
But after enough of these searches, the titles started to feel like the least interesting bit. The useful question was normally the one underneath: why does this person need to exist now when they didn't six months ago?
Usually, something had broken.
Not necessarily broken in the catastrophic sense. Sometimes it was a good problem. Customers wanted the product but getting each one live required half the engineering team. Five product teams were all solving the same infrastructure problem differently. The agents were doing impressive things but nobody could reconstruct what had happened when one of them did something completely deranged. Security had finally asked what the agent was allowed to access and the answer was, technically speaking, quite a lot.
Whatever it was, something that had previously been manageable as part of somebody else's job had become painful enough to need an owner.
Which got me wondering whether we're looking at AI hiring backwards.
We spend a lot of time trying to decide what the new roles are. What exactly is an AI Engineer? Is FDE actually new? Do we need an LLMOps Engineer? What's the difference between an AI Product Engineer and a Product Engineer who happens to be very good at AI?
I'm increasingly less interested in any of those questions.
Because if you ignore the title and look at the reason the role appeared, the org chart starts to look like a record of the problems the company encountered as it gave AI more responsibility.
The AI org chart tells you what broke.
And if that's true, the more interesting question isn't what AI roles should we hire?
It's what are we actually trying to let AI do, and what's stopping us?
There are enough AI maturity models on the internet already, and I have no desire to add another coloured staircase to the pile.
The distinction I've found more useful is much simpler: what are you actually trusting the machine to do?
At one end, it's answering. Summarise this. Explain that. Tell me what happened. It gives you an answer. Somebody still has to decide whether it's any good — and whether to do anything with it. If it's wrong, that's annoying, but in most cases the human is still standing between the answer and the consequence.
Then it starts doing things. Process these documents, update this record, generate this feature, run these tests. It's inside a workflow now, but somebody else has mostly decided the route. This is normally where the impressive demo runs into the considerably less impressive reality that the model needs access to six systems, three of them have terrible APIs, the useful data lives somewhere nobody mentioned and apparently Salesforce has its own interpretation of what a field should be called.
Move again and the AI starts acting. You're not giving it the route anymore, you're giving it the outcome. Resolve this support request. Investigate this transaction. Fix this bug. It can decide which tools to use, what order to use them in, whether to retry and when to change approach.
This is where things get much more interesting, because you've stopped merely automating execution and started delegating decisions about execution. Suddenly the questions aren't just "is the model good?" They're "what did it actually do?", "why did it do that?", "what was it allowed to do?", "how much did that cost?" and the increasingly important "how do we stop it doing that again?"
And then there's operating, which I think is meaningfully different again. Acting is episodic autonomy: here's an outcome, go and achieve it. Operating is standing responsibility: own first-line support, monitor these transactions, keep this process running and bring a human in when you hit the boundary.
At that point we've given the system something that starts to look surprisingly like a job. So, unsurprisingly, we start asking surprisingly job-like questions about it. Who owns it? What identity does it have? What can it access? What needs approval? How do we audit it? What happens when it gets something wrong at 2am and there isn't a human watching?
I don't think those four things are a maturity model, although drawing them in a line makes them look suspiciously like one.
It gives you an answer. Somebody still has to decide whether it’s any good — and whether to do anything with it.
Context, accuracy, whether the answer’s actually usable.
It’s doing something rather than suggesting something, although most of the route has already been decided.
Integration, tools, data, the six systems it needs to touch and the three that have terrible APIs.
You give it the destination rather than the directions. It chooses tools, retries and changes approach along the way.
What did it actually do, why did it do that, what was it allowed to do, what did that cost, how do we stop it doing that again.
This is standing responsibility rather than a one-off task. It starts to look surprisingly like a job.
Who owns it, what can it access, what needs approval, how do we audit it, what happens at 2am when nobody’s watching.
The point isn't to get everything as far as possible. That would be an extremely efficient way to create some exciting new problems.
The point is that every time you hand over a little more responsibility, the difficult bit moves.
And that's where the hiring gets interesting.
When somebody tells me they need an AI Engineer, my first response probably shouldn't be "great", although old habits die hard.
The useful question is why?
Sometimes the answer is genuinely about model capability. They're building something difficult enough that the quality, latency or behaviour of the model is the limiting factor, and they need serious ML depth.
Quite often it isn't.
Maybe the technology works beautifully, but every new customer requires weeks of engineering work before they can use it. Maybe the product engineers are all building their own versions of the same agent infrastructure because nobody owns the shared layer. Maybe the system works 90% of the time and that last 10% contains almost all of the things customers actually care about. Maybe everyone can see the agent doing something odd in production but nobody can trace the sequence of decisions that got it there.
Or maybe the agent now has access to enough important things that the security team has stopped saying "interesting" and started saying "absolutely not".
These are all AI problems in the sense that AI caused them to become important. But they're not the same engineering problem, and hiring somebody simply because they've had "AI Engineer" written under their name for the past eighteen months doesn't tell you much about whether they can solve yours.
What I keep seeing instead is specialisation appearing around the constraint.
None of this is a hard taxonomy. It's just a pattern that shows up often enough to be worth noticing.
Once agents can take consequential actions, security and identity stop being an afterthought either. The system needs access, but not that much access; autonomy, but not that much autonomy; enough freedom to be useful without giving it the digital equivalent of a master key and hoping it has a good day.
I'm not proposing that a company with three unreliable agents should immediately hire a VP of Agent Reliability and print some stickers.
The specialist tends to appear where the shared pain has become expensive enough.
There's a slightly more interesting implication hiding inside that.
We tend to think adding specialists makes an organisation more specialised. Sometimes it does. But sometimes the specialist is the thing that allows everyone else to remain broad.
If every Product Engineer needs to become excellent at model routing, sandboxes, deployment infrastructure, permissions, observability, eval design and cloud economics before they can ship a useful feature, you've certainly built a high-bar engineering team.
You've also narrowed your hiring pool to roughly twelve people, seven of whom work for Anthropic.
At some point it makes more sense to solve the genuinely shared problems once, properly, and let the people close to the product stay close to the product.
Not everything belongs in a central team. Central teams have their own special talent for becoming the thing everyone is waiting for. But where inconsistency is expensive, shared capability starts to earn its keep.
That feels more useful to me than asking what an AI company of a certain size is "supposed" to hire.
This isn't a particularly helpful thing for a recruiter to write, but there we are.
Some companies absolutely have a technical talent problem. They know what they want to do, they've got the organisational permission to do it, and they simply don't have the engineering capability required to make it work.
Hire.
But I've also seen variations of another situation.
The business wants to "do something agentic". Product hasn't really decided which workflow matters. Nobody quite owns the process they want to automate. Security hasn't said what an agent is allowed to touch. The data lives across four systems owned by different teams. Leadership agrees that AI is strategically important but less so on what that should mean before the next board meeting.
Then somebody writes a job description.
There is probably an excellent engineer somewhere who can help untangle some of that. Excellent engineers do heroic amounts of organisational archaeology.
But if you gave the company the perfect AI Engineer tomorrow, what exactly would you expect them to do?
If the answer quickly becomes "well, first we'd need Product to decide..." or "Security still needs to approve..." or "we're not actually sure who owns that workflow", I'm not convinced the talent market is your immediate problem.
Microsoft's 2026 Work Trend Index research is useful here. Looking across 20,000 AI users in ten markets, it found organisational factors such as leadership alignment, manager support, culture and talent practices were far more influential in reported AI impact than individual factors alone.
In other words, you can hire people who know how to use the tools and still create almost no useful leverage if the organisation around them can't absorb what they can do.
I think we sometimes describe both situations as an "AI skills gap" because that's easier than admitting one of them is a decision-making gap.
The first is a capability problem. The second is an absorption problem.
The distinction matters because hiring into an absorption problem can actually make it worse. You've now added another expensive person to a room full of people waiting for somebody to decide what the room is for.
A lot of apparent AI problems are fairly old organisational problems with a very expensive model sitting on top.
Forward Deployed Engineering probably deserves a small diversion because it has become the clearest example of how strange the titles are getting.
The actual idea is interesting.
Take someone technical and put them much closer to the problem. Rather than Product discovering a requirement, writing it down, handing it to Engineering, building something, handing it to Implementation and eventually discovering that the customer meant something completely different, collapse some of that distance.
The engineer sits with the customer, understands the workflow, works out what's actually possible, builds against the real environment and sees what happens when the thing leaves the safety of the demo.
If that loop works properly, what they learn doesn't stay trapped inside the customer project either. The repeatable pieces make their way back into the product, so the next customer doesn't need quite so much custom engineering.
That's the bit I find interesting. It is product discovery through engineering.
OpenAI's current FDE descriptions are quite explicit about that kind of ownership: discovery, scope, architecture, build, rollout, adoption and measurement, with what gets learned in deployment feeding back into product and model development.
The slight problem is that we've since started calling an enormous number of things FDE.
I've seen versions that are basically customer-facing Software Engineers. Others are closer to Solutions Architects. Some are excellent systems engineers who happen to spend a lot of time in customer environments. Some are technical consultants with a new badge.
Again, none of those are bad jobs.
But if an engineer doesn't really build anything, that's useful information. If they build a proof of concept and disappear before it hits production, that's useful too. If every customer still requires the same volume of custom work three years later, that might tell you something slightly uncomfortable about the product.
So I don't think the useful question is whether your company "needs FDEs".
It's whether bringing engineering closer to the problem removes a bottleneck that your existing way of working can't.
The title can come afterwards.
Although it probably will be FDE. Everyone else is doing it.
There is another thing making these searches harder than they need to be.
We have started treating AI experience as though it needs to have happened inside an AI job.
Sometimes it does. There are parts of the market where you really do need deep specialist experience and pretending a strong backend engineer can become a research scientist because they had a productive weekend with Claude is not particularly helpful.
But closer to the product, I'm much less convinced.
One of the more interesting bits of Anthropic's recent Claude Code research looked at roughly 400,000 sessions between October 2025 and April 2026. In a typical session, humans were still making most of the planning decisions — what should happen — while Claude made more of the execution decisions — how to do it. People with greater domain expertise were also able to get more work from the agent per instruction and were somewhat more likely to succeed.
Which is interesting because the obvious story has been that better AI lowers the value of expertise.
It clearly lowers the value of some kinds of expertise. I don't need to remember syntax with the same devotion I once did. There are technical tasks that used to require a specialist which somebody competent can now get surprisingly far through with the right tools.
But that doesn't necessarily mean the experienced engineer becomes less useful. In some situations it means they can operate over a much bigger surface area.
That feels closer to what we're seeing in the talent market.
I've spoken to engineers whose CVs look like conventional software engineering CVs until you ask what they've actually been doing for the last year.
Then you discover they've built an internal review agent over a code graph. Or automated a recurring production workflow with an agent. Or changed the way their whole team develops because a large part of implementation now happens through coding agents. None of that necessarily changed their title.
Their professional identity is still Backend Engineer, Staff Engineer, Platform Engineer, whatever it was before.
The work moved faster than the label.
And this is where I think we may be over-indexing on the shiny new skills while underestimating some fairly old ones.
A production AI system still needs someone to understand state. It still falls over. It still has latency, bad data, permissions, cost, dependencies, edge cases and users who will do things nobody expected. It just now has the additional benefit of one component occasionally making a decision you would never have written into the code.
That makes model fluency valuable.
It also makes things like debugging, systems thinking, judgement, failure handling and knowing when something smells wrong fairly useful.
The more probabilistic part of the system becomes, the less I want the rest of it designed by somebody who only learned engineering after LLM APIs arrived.
Perhaps that's slightly unfair. But I think the broader point holds.
AI is creating new expertise, but it may also be increasing the leverage of some very old engineering qualities.
There are definitely areas where Australia is short of talent.
I've worked searches where you can map the credible local pool and reach the end rather more quickly than anyone involved would like.
So this isn't going to turn into one of those "the talent is out there, you're just not looking hard enough" recruiter speeches. Sometimes it isn't.
But I also hear "there aren't enough AI engineers in Australia" used to describe several completely different problems.
The actual market is growing quickly. PwC's 2026 AI Jobs Barometer found Australian job ads seeking AI skills increased from around 20,000 in 2024 to 41,000 in 2025. AI-skilled workers carried an average wage premium of 62%, which is perhaps the market's slightly more direct way of telling us demand is ahead of supply.
The National AI Centre paints a similarly complicated picture. Its latest report found 1,532 Australian organisations sought workers with AI-related skills in 2024, up from 483 in 2015, while the top 100 hiring organisations accounted for 58% of AI job postings. Inner Sydney, Melbourne, Brisbane and Perth made up 64% of advertised locations. Its company analysis also identified a sample of 1,533 businesses contributing to the Australian AI ecosystem — not the whole ecosystem, but enough to make "nothing is happening here" fairly difficult to defend.
What I think gets lost is that "talent shortage" can mean at least three things.
The first is the obvious one: the capability is genuinely scarce. You want someone who has already built a particular type of agentic system at real scale, understands the domain, can architect the platform, talk to enterprise customers and operate at Staff level. There may be a very small number of them. Fair enough.
The second is visibility. The people exist, but the normal search doesn't show them particularly well. Their title doesn't contain AI. Their LinkedIn is four years out of date. The interesting thing they've built was internal. They're not applying to jobs. Or the strongest signal isn't something searchable at all — it's another engineer saying, "you should really speak to this person."
This happens often enough that I no longer treat the people visible in a recruiter search as the market.
The third shortage is more awkward because we've created it ourselves. It's the brief.
Staff-level software engineering · production agents · distributed systems · evals · customer-facing capability · product judgement · security · a particular industry background · commercial sense
Headcount required: five.
Budget: one. Good luck.
At some point the problem isn't simply that Australia hasn't produced enough people. You've defined one person as an entire team.
The three shortages require completely different responses, yet they all arrive at the same sentence: "There's no talent."
This one’s real more often than recruiters like to admit. If the brief requires someone who has already built this kind of system at real scale, in this domain and at Staff level, the credible pool may genuinely be very small. This is usually the kind of search that needs an honest conversation about time, geography and which capabilities really have to arrive in the same person.
My first suspicion would be that at least some of the people exist, but the obvious search isn’t showing them. Their title may not say AI. Their LinkedIn may be years out of date. The interesting thing they built may have been internal and never became a case study. Searching for the job title finds people legible as that job title. It doesn’t find everyone capable of doing the work.
My first question would be whether the role is really several jobs bundled together: Staff-level engineering, production agents, distributed systems, evals, customer-facing work, product judgement, security, domain experience and commercial instinct. Some roles genuinely need unusual combinations. But when almost nobody qualifies, I’d want to test the brief before concluding that the market has failed to produce the talent.
Sometimes there genuinely isn't enough of the capability. Sometimes the talent exists but isn't visible. And sometimes the search is working perfectly; the person you've asked it to find barely exists.
That's why I'm increasingly careful with the idea that Australia's AI talent market is tiny.
The visible part can be. I'm much less sure the available part is.
This probably explains some of the visibility problem.
An engineer can change quite dramatically without changing jobs.
A year ago, perhaps they were using Copilot occasionally. Six months later they're delegating large chunks of implementation through coding agents, building agentic workflows internally, thinking in evals and tool calls and changing the architecture of systems around what models can now do.
Same company. Same title. Same LinkedIn headline.
There isn't a neat labour-market event marking the transition.
The people around them notice, though. They see who works differently. Who has actually figured out how to use the tools. Who built the thing everyone else copied. Who gets asked when the agent starts behaving strangely.
Which is part of why referrals become interesting in a fast-moving technical market.
A CV is periodically updated. Reputation is continuous.
This isn't unique to AI. Strong engineers have always known who the strong engineers around them are.
But when capability is changing faster than job titles, that informal network updates before the formal market does.
The search therefore has to change as well.
Looking for "AI Engineer" finds people who are legible as AI Engineers. It does not necessarily find all the people capable of doing the work.
Those are not the same thing.
This one is less settled in my head, but I think it's worth putting down because I keep seeing versions of it.
AI has made the exceptional senior engineer incredibly attractive.
Take someone with deep technical judgement, give them increasingly capable agents and let them operate across a much larger problem space than they could before. It's fairly easy to imagine why a company would want a small team full of those people.
The problem is everybody wants the same people.
And if AI makes the most experienced engineers more leveraged, the obvious response is to keep hiring more of them. Senior, Staff, Principal. People who can take ambiguity and just make it disappear.
I've had conversations recently with companies that would happily hire good mid-level engineers in theory but aren't really sure what to give them anymore. The senior can do the ambiguous work and use AI for much of the execution, so where does the mid fit?
I don't think the answer is pretending the mid is suddenly a Staff engineer because they have Claude.
But I also don't think "we only hire seniors now" is a particularly sustainable endpoint.
The question may be less about what level of task a mid can perform and more about what level of outcome they can own.
A senior engineer can decide where the boundary should be, what architecture makes sense and what risks are acceptable. A mid-level engineer doesn't necessarily need to make all of those decisions independently to own a meaningful piece of production work inside them.
"Implement this endpoint" is increasingly a terrible unit of ownership. "Get this ingestion workflow reliable enough that customers stop complaining about it" is much more interesting.
There might be twenty implementation tasks inside that. The agent can help with a lot of them. The engineer still has to understand the system, make decisions, test things, inspect failures, work out what good looks like and remain accountable when the improvement doesn't work.
That's real engineering experience.
And it has a second benefit. If a Staff engineer is spending half their week doing work a capable mid could own with good tooling and clear boundaries, then you're not really getting Staff-level leverage from the Staff engineer.
Now, the uncomfortable bit: perhaps you simply need fewer people.
If four engineers using agents can deliver what eight people did before, there are obviously companies that will choose to employ four people. Pretending that won't happen seems silly.
But it's not the only thing you can do with the productivity gain.
You can solve the same number of problems with fewer engineers, or you can solve more problems with the same number. Gartner's July 2026 research predicts smaller engineering teams becoming much more common — 60% of organisations adopting them at scale by 2029 versus 15% in 2026 — while explicitly arguing that these teams should not be treated simply as a cost-cutting exercise. It expects demand for engineers to keep growing as demand for software grows with it. Gartner also warns that cutting junior hiring creates a rather obvious problem later when everyone wants experienced engineers and nobody has spent the previous five years creating any.
I don't know exactly where that lands yet.
But I think "AI means we only need very senior engineers" may turn out to be one of those ideas that works brilliantly for the first companies to do it and rather less well once everybody does.
There has to be a way for people to become senior.
The interesting thing about experience isn't really the number of years. It's what happened inside them.
You can do the same narrow job for ten years and have ten years of employment. Or you can spend five years moving through increasingly difficult systems, making decisions, getting some of them wrong, seeing the consequences and changing how you think.
The second person may have considerably more useful experience.
AI could make that distinction even bigger.
An engineer can now research approaches faster, prototype faster, implement faster, generate tests faster, explore unfamiliar codebases faster and potentially attempt things that would previously have taken too long to be worth trying.
In theory, that should increase the number of meaningful technical experiences they can have. But only if they actually experience them.
There is a version where the agent writes more code, solves more problems and the human learns less because they never had to form a view of what was happening.
Producing an answer and understanding an answer have never been quite the same thing. AI just makes the gap easier to ignore.
So I'm interested in what I've started thinking of as experience density: how many meaningful decision-and-feedback loops somebody has actually been through.
Understand the problem. Form a view. Make a trade-off. Build or delegate. Ship it. Watch what happens. Discover something you were wrong about. Change your mental model.
AI can make the distance between those moments shorter. It can't guarantee the learning happens when they arrive.
That has implications for how we develop people too.
I don't think the answer is banning AI for juniors so they can enjoy the authentic experience of spending an afternoon writing a helper function somebody else solved in 2014.
Let them use the tools. But don't let them outsource ownership.
Ask why they chose the approach. How they verified it. What the failure modes are. Which bit they don't understand. What the agent suggested that they rejected and why.
If seniority increasingly involves directing work, making trade-offs and knowing when something isn't good enough, then those are the muscles people need to practise earlier.
AI might compress the time between engineering experiences. It doesn't automatically compress the time required to learn from them.
One prediction I do find convincing is that the team wrapped around an individual problem gets smaller.
Gartner currently describes these emerging "tiny teams" as typically four to five people, sometimes two or three, supported by strong platform capability.
That makes intuitive sense. If one engineer can move across a broader surface area because agents absorb more of the execution, you need fewer people passing work between each other just to get something built.
The interesting bit is what happens with the spare capacity.
The dull answer is "efficiency", which usually means a slide containing a downward arrow somewhere near the word headcount. Sometimes that will be the answer.
But software has the useful characteristic of creating new things worth building every time building software becomes cheaper.
So I wonder whether the more important organisational change is not fewer engineers but more small units of ownership. Instead of eight people around one problem, perhaps four people own it and another four tackle something that never previously made the roadmap.
That also makes the infrastructure around those teams more important. A tiny team is only tiny if it doesn't need to employ its own miniature security department, platform team, data platform and observability function.
So as individual teams get broader, some shared capabilities may need to get stronger. Which sounds contradictory until you think about it.
The edge gets more generalist because the centre takes care of the things nobody should be inventing twelve different ways.
There is a limit, though. Not every handoff is waste. Some exist because one person should not be both marking and sitting the exam.
Security challenging engineering is useful. A domain expert independently deciding whether an agent's behaviour is acceptable is useful. The person who built a consequential system not being the only person deciding whether it's safe is useful.
AI makes execution handoffs easier to compress. I'd be much more careful with the separation of judgement.
The thing I thought I was researching was AI hiring. The thing I think I've actually been looking at is delegation.
As companies give AI more meaningful work, the easy bit moves.
First the model needs to produce something useful. Then it needs to interact with the real system. Then it needs enough autonomy to get to an outcome. Then somebody decides it can own part of a process without a human standing over it.
Every move creates leverage. Every move also creates a new way for things to go wrong.
The interesting roles tend to appear around those new failure points.
Sometimes that's an ML Engineer because capability itself is still the problem. Sometimes it's an FDE because deployment has become the problem. Sometimes it's platform, evals, reliability, security or identity. Sometimes it's an experienced software engineer who never bothered changing their LinkedIn title.
And sometimes it isn't an engineer at all because the technology is ready and the organisation isn't.
Which leaves me with two questions I think are more useful than asking what an AI engineering team is "supposed" to look like.
I’d want to establish whether the model itself genuinely isn’t reliable enough for the thing the company wants it to do. If that is the problem, the search is likely to depend on real depth in the specific capability that’s missing.
I’d want to understand what happens between a capability working in principle and working in a customer’s actual environment. The useful hiring question is whether the difficult part is customer-side discovery, production engineering, domain translation — or some combination of the three.
I’d check whether several teams are independently solving the same underlying infrastructure problem. When that starts appearing in multiple briefs, it is often a sign that the shared problem is becoming expensive enough to need an owner.
I’d want to know how the company decides whether the system is good enough to trust with more. If something works often enough to be useful and fails often enough to make people nervous, the hiring need may sit around measurement, explanation and failure analysis.
I’d ask what the system can access, where approval is required and what happens when it crosses a boundary. Those answers usually tell you more about the hiring problem than saying the company needs “more AI security.”
I’d probably pause the hiring conversation if nobody can yet say what this person would own or what should become possible after they arrive. That doesn’t mean there is no problem. It means another hire may be an expensive way of waiting for the same decisions.
The first tells you what you're actually trying to delegate. The second tells you where the bottleneck is.
Somewhere inside that answer is probably the person you need.
If you need anyone at all.
I've mixed three things together here.
There is published research — from Anthropic, Gartner, PwC, Microsoft and Australia's National AI Centre among others.
There are things I've observed through engineering searches in Australia during 2026: the briefs companies are writing, the people we're finding, the combinations of capability that are proving difficult to hire and the gap between what candidates call themselves and what they actually do.
And then there is my interpretation of the two.
The answering → doing → acting → operating model is mine. So is the idea of capability, visibility and brief shortages. They're ways I've found useful to make sense of what I'm seeing, not categories handed down on a stone tablet by Gartner.
I'd rather say that than put a source number next to every opinion and hope nobody notices.