What to Put in Your Job Description Instead of 'AI Skills'

"Must have AI skills" filters out nobody, so delete it and write the line it was trying to be: "Must catch and override AI output that is confidently wrong." One of those sentences sorts your applicant pool. The other one just decorates it. If your job description leans on the first, every candidate clears the bar, and you are back to reading résumés that all say the same three tools.

The reason is simple and a little uncomfortable. "AI skills" names Fluency, whether the person can make the tool produce something. In 2026 that is not a distinguishing trait. It is a baseline everyone in the applicant pool already meets, the way "comfortable with email" stopped being a line worth writing around 2004. A requirement that everyone satisfies is not a requirement. It is a formality wearing the costume of one.

The short version:

• "AI skills" screens nobody out, because Fluency with the tools is now universal. The line looks current and rigorous and tells you almost nothing about the candidate.
• What the role actually needs is Direction: the judgment to notice when the model is confidently wrong, override it, and own the decision the tool got backwards. That is the thing "AI skills" was always pointing at and never able to name.
• Every fakeable line has a direct rewrite that describes a behaviour instead of a tool. Swap "proficient with AI" for "can tell when the AI is wrong and say so." Swap "AI-augmented workflow" for the specific decisions the person still owns when the tool is confidently incorrect.
• The table below is copy-paste. Take the lines that fit the role, drop them into the JD, and you will screen for the capability that survives the tool instead of the one that everyone already has.

---

Why "AI skills" sorts nobody

Picture the last shortlist you screened. Everyone listed AI. Same models, same automation tools, the same "AI-augmented workflow" line near the top of the CV. You learned nothing from any of it, because the phrase you asked for is the phrase they all knew to supply. When a requirement produces a clean pass from the entire pool, the requirement is dead weight. It occupies a line in the JD and does no work.

This is not a hunch. "AI skills" now appears on a rising share of postings: roughly 2.5% of all US job listings in PwC's AI Jobs Barometer, and about 4.2% of entry-level roles, nearly double a year earlier per CNBC. The phrase is spreading fastest at exactly the level where it means least, because entry-level is where "can operate the tool" has the smallest signal and the biggest crowd. Every hiring manager has written the line. Almost none can say what it screens for. I made the fuller case for why the phrase means nothing on its own. This piece is about what to write in its place.

The gap the phrase hides is the one that matters. Two candidates both fluent with the same stack are not the same hire. One ships whatever the model produces. The other notices when the output is polished and wrong, and stops. Your JD, as written, cannot ask for the second one, because "AI skills" describes both of them identically. To sort them, you have to describe the behaviour, not the tool.

The thing you were actually trying to ask for

There are two axes, and "AI skills" only ever touches one. Fluency is what a person can make AI do. Direction is whether they can tell where it should go, catch it when it drifts, and override it when it is confidently wrong. Fluency is a stage everyone has passed through. Direction is the thing almost no job description asks about, because it is harder to name and far harder to fake.

Direction is not a soft skill or a vibe. It is a measured gap in how people behave around a confident machine. In a Wharton study titled Thinking, Fast, Slow, and Artificial, researchers Steven Shaw and Gideon Nave ran three experiments with 1,372 people. Accuracy rose from 46% with no AI to 71% when the AI was right, then collapsed to 31.5% when the AI was wrong, below the 46% people managed with no help at all. And they followed the wrong answer around 80% of the time, growing more confident as accuracy fell. Shaw and Nave call it cognitive surrender. The person hands the thinking to the machine and borrows its certainty without checking its work.

Now read that as a hiring spec. The trait you most need to screen for is the refusal to surrender, the itch that makes someone check the load-bearing claim when the output looks finished. That trait does not show up under "AI skills." It shows up only when you write the JD line to describe it directly. Which is the whole exercise.

The swaps: what to write instead of "AI skills"

Here is the table. Left column is the line you have. Middle is the line to write instead. Right is why the swap sorts people the first one couldn't. Take what fits the role and leave the rest.

Instead of writing "X"	Write "Y"	Because
"Must have AI skills"	"Must be able to catch and override AI output that is confidently wrong"	Names Direction, not Fluency. Everyone passes the first; only a real Operator passes the second.
"Proficient with AI tools"	"Can tell when an AI answer is wrong, say so, and explain what they checked"	Proficiency is universal. Knowing when the tool is wrong is the rare part.
"AI-augmented workflow"	"Owns the final decision when the tool is confidently incorrect, and can name which decisions those are"	Describes accountability the tool can't hold. A workflow doesn't own an outcome; a person does.
"Experience using ChatGPT / Claude / Copilot"	"Has shipped work where they overrode the model's first answer and can explain why"	Usage is table stakes. The override is the judgment you're paying for.
"Comfortable prompting large language models"	"Comfortable disagreeing with a large language model and defending the disagreement"	Prompting is input. Disagreeing under pressure is the signal that survives the tool.
"Leverages AI to boost productivity"	"Uses AI for speed and still checks the load-bearing claim before it ships"	Speed without checking is how confident mistakes reach your customers fastest.
"Strong AI literacy"	"Can spot a plausible-but-wrong AI output in their own domain and trace what it would break"	Literacy reads the output. Direction predicts its consequence three moves out.
"Familiar with AI-driven automation"	"Can decide which steps must stay human because the cost of the model being wrong is too high"	The valuable judgment is knowing where not to automate, not where you can.

Two rules make these land. First, every rewrite names a behaviour under a wrong answer, not a tool in a good moment, because the wrong-answer moment is the only one the candidate can't pre-cook. Second, every rewrite is checkable in the room. If you write "can tell when the AI is wrong and say so," your interview now has an obvious job: put a confidently wrong AI output in front of them and see whether they say so. The line and the test are the same shape. That is not an accident. It is the point. A JD line you can't test is decoration. I wrote separately about what you're actually screening for when you screen for "AI skills," and the short version is: you were reaching for Direction the whole time and describing Fluency by mistake.

The one swap most JDs get wrong

"AI-augmented workflow" is the line I'd delete first, because it hides the exact thing you're hiring for. A workflow is a process. It doesn't decide anything, doesn't catch anything, doesn't get held to account when the model is wrong. When you write that a role is "AI-augmented," you've described the machinery and skipped the human, which is precisely the part that matters when the machinery is confident and incorrect.

Rewrite it as a decision the person owns. Not "works within an AI-augmented content pipeline" but "owns the call on whether a piece ships when the AI's draft reads clean and gets a fact wrong." Not "operates an AI-augmented underwriting process" but "decides which flags the model raised are real and which to override, and signs their name to it." The augmentation isn't the job. The judgment left over after the augmentation is the job. Write the leftover.

This also fixes a quiet failure mode. A JD full of "AI-augmented" language attracts people who are good at running the pipeline and says nothing that would attract the person who argues with it. You end up staffing for compliance with the machine and filtering out the ones who'd catch it, which is the case I made in full for why you should stop hiring AI users and start hiring AI Operators. The JD is where that filter gets set, before a single interview. Get the language wrong and you've pre-selected the surrendered candidate.

Write the JD so the interview writes itself

The best test of a rewritten line is whether it tells your interviewer what to do. "Must have AI skills" gives them nothing, so they ask "so, do you use AI?" and everyone says yes, and the screen is over having sorted no one. A line like "can catch and override a confidently wrong AI output" gives them a script: build a moment where the AI is wrong, hand it over, say nothing about the error, and watch.

That is the difference between asking and checking, and most processes never cross it. Asking a candidate whether they can direct AI gets you a fluent yes. Checking means constructing the wrong-answer moment and reading what they do. Do they get the itch, check the load-bearing claim, find the crack, and rebuild? Or do they accept the polished gift and build on top of it? Your JD language decides which of those two things your interview is even capable of doing. Write for Fluency and you'll ask. Write for Direction and you'll check.

So the practical order is this. Rewrite the requirement to name a behaviour under a wrong answer. Then design the one interview moment that provokes exactly that behaviour. The JD and the assessment stop being separate documents. They become the same claim, written once as a requirement and once as a test.

What this costs you if you leave the line as-is

Leaving "AI skills" in the JD is not neutral. It is an active filter that selects for the wrong trait. You attract, screen, and hire for Fluency, the thing everyone has, and you stay blind to Direction, the thing almost no one is tested on. Do that at scale for a year and here is the org you build. Velocity looks healthy. Everyone's fast. And underneath, the share of decisions that are AI-shaped and unchecked keeps climbing, because your JD language never once asked for the person who checks.

The correction is cheap, which is the good news. It is a language change in a document you already control. You do not need a new assessment platform or a new interview panel to start. You need to delete one phrase and write, in its place, the behaviour you were always trying to describe. The candidate you want, fluent with the machine and still willing to tell it no, reads job descriptions too. Right now yours is written to attract the one who never argues. Change the line and you change who applies.

---

Frequently asked questions

What should I write in a job description instead of "AI skills"? Write a behaviour under a wrong answer, not a tool in a good moment. Replace "must have AI skills" with "must be able to catch and override AI output that is confidently wrong." Replace "proficient with AI tools" with "can tell when an AI answer is wrong, say so, and explain what they checked." The rewrite names Direction, the judgment the role needs when the model is confidently incorrect, instead of Fluency, which every candidate already has.

Why doesn't "must have AI skills" work as a requirement? Because it screens nobody out. Fluency with AI tools is now universal, so a requirement that asks for it produces a clean pass from your whole applicant pool. "AI skills" appears on roughly 2.5% of US postings and about 4.2% of entry-level roles per PwC and CNBC, spreading fastest exactly where it means least. A line everyone satisfies is not a filter; it is a formality.

What is the difference between Fluency and Direction in a JD? Fluency is what a person can make AI produce: running the tool, prompting, generating a draft. Direction is whether they can tell where the output should go, catch it when it drifts, and override it when it is confidently wrong. "AI skills" only names Fluency. The requirement you actually want describes Direction, because that is the capability that survives once everyone can operate the tool.

How do I rewrite "AI-augmented workflow" on a job posting? Delete the workflow and name the decision the person owns. Instead of "works within an AI-augmented content pipeline," write "owns the call on whether a piece ships when the AI's draft reads clean and gets a fact wrong." A workflow can't be held to account when the model is wrong; a person can. Describe the judgment that's left over after the augmentation — that leftover is the job.

Do these JD line swaps actually change who applies? Yes. Language written for Fluency attracts people who are good at running the machine and stays silent to the ones who argue with it. Language written for Direction — catching wrong output, overriding it, owning the call — signals that the role wants judgment, not just usage. The JD is the first filter in your process, set before a single interview, so the line you write pre-selects the candidate you get.

How do I test the rewritten requirements in an interview? Build the wrong-answer moment. Because each rewrite names a checkable behaviour, the interview task is obvious: hand the candidate a real problem with a polished-but-incorrect AI output attached, say nothing about the error, and watch. Operators check the load-bearing claim and rebuild; users build on top of it. The JD line and the test become the same shape — write the requirement as a behaviour and the assessment designs itself.

Ivanooo built the AI Operator Profile to measure the axis a job description can't carry on its own: not what a candidate can make AI do, but whether they can direct it when it is wrong. If "must have AI skills" is on your posting, this is the thing you were trying to write.