AI isn’t coming for jobs.
It’s coming for tasks.
And that matters.
Because if your position descriptions are just lists of tasks — and most of them are — then you’ve got a serious blind spot in your workforce documentation.
The work is changing.
But the documents that define that work haven’t caught up.
Most PDs I see still pretend it’s 2015.
They describe the role like it exists in isolation. Like it’s static. Like the person is the sole agent in delivering every outcome.
But that’s not how work works anymore.
We’ve got teams using AI for copywriting, summarising meetings, writing code, cleaning data, generating insights, drafting legal contracts.
And yet their PDs? Still say “drafts documents” or “prepares reports” like it’s all human hands on keyboard.
That’s the mismatch.
And if we’re serious about helping organisations adapt, stay compliant, and stay competitive — then PDs need to reflect the reality of how work is done today, not just who is doing it.
You Don’t Need to Predict the Future — You Just Need to Acknowledge the Present
I don’t write PDs like crystal ball forecasts.
That’s a dead end. The tech moves too fast.
But I do write them with an assumption baked in: some tasks are better done by machines, and some tasks are better supported by machines.
That’s the starting point.
And I make it explicit.
If a role is expected to use AI tools — even lightly — I call that out in the capability section.
If a process is partially automated, I clarify which part the human owns, and what judgement or oversight they’re responsible for.
It sounds obvious, but most PDs don’t do it.
They either:
- Pretend AI doesn’t exist, or
- Avoid naming it because it feels speculative or risky
But here’s the thing — when you leave it out, you create ambiguity.
You leave people unsure about what they’re still responsible for, what the system is doing, and where the risks or decisions actually sit.
And that ambiguity?
That’s what gets exploited in audits, legal challenges, and compliance reviews.
You don’t need to over-engineer it.
You just need to say what’s true now — and leave space for change.
I Use the SCORE Lens to Map What Can Shift
I built a method I use in every WorkLuma project: the SCORE framework.
It helps assess which tasks in a PD are ripe for automation or augmentation — and which ones still need distinctly human judgement, creativity, or oversight.
SCORE stands for:
- Structure – Is the task built on predictable, structured inputs/outputs?
- Criticality – What happens if it fails? Is it low-risk or mission-critical?
- Opportunity – How much value or time could be gained if automated/augmented?
- Repeatability – Is it performed often enough to justify automation effort?
- Ease – How technically easy is it to automate today?
I don’t include this scoring in the PD itself — that’s back-of-house analysis.
But I do use it to rewrite responsibility statements.
Take this example:
Old PD says:
“Prepares monthly performance reports”
That’s vague. Could mean anything. Could take hours. Could take two clicks in a dashboard.
After SCORE analysis, I rewrite it like this:
“Reviews auto-generated performance reports each month, validates data accuracy, and escalates anomalies to the leadership team.”
Now we’ve acknowledged the automation.
We’ve defined the human’s role in quality assurance.
We’ve clarified where judgement comes in.
That’s the kind of clarity organisations need — especially as AI becomes embedded in more workflows.
Because here’s the truth:
If you don’t write it down, people will make it up.
And they’ll make it up differently.
Which means no consistency, no defensibility, and no way to scale.
I don’t write AI into PDs because it’s trendy.
I do it because it’s already here.
And because PDs are meant to reflect the truth of the role — not the fantasy of how we used to do things.
This isn’t about replacing people.
It’s about designing roles that make the most of people and technology.
It’s about being honest about what’s changing — and giving people the clarity to adapt.
So the next time you write a PD, ask yourself:
Are you describing the role as it used to be?
Or are you writing it for how it works now?
If it’s the former, you’re doing your team a disservice.
If it’s the latter — you’re building something future-fit.