How Do You Write an AI Requirement Without Flooding the Pipeline?

Why does a tool-name requirement flood the pipeline?

Because a tool name is a claim with no floor under it. "Experience with ChatGPT" is true for anyone who has opened the tab once, so the line sorts nobody out and every applicant clears it honestly. Federal assessment guidance is blunt about the mechanism: self-reported training and experience invites applicant inflation, and ratings built from those self-reports relate poorly to performance on the job ¹.

The application text will not rescue the requirement either. In a field experiment across nearly half a million jobseekers, candidates given algorithmic writing help on their resumes were hired 8% more often, with no sign employers were less satisfied with them ². A well-written claim about AI fluency is now cheap for every applicant to produce, which means the claim carries almost no information by the time it reaches you.

So the posting does two things at once, and the second is invisible until the applications land:

• It sets a threshold. "Familiarity with generative AI" sets the threshold at having a consumer account. Everyone with a browser meets it, including the people applying to forty postings a week.
• It tells applicants what the job is. A tool list tells them nothing about the work, so nobody self-selects out. A task tells them exactly what they would be doing on a Tuesday, and the people who have never done it move on.

That second effect is the whole lever. Volume at the top is not really an inbox problem; it is the arithmetic of a threshold anyone clears, which is the same arithmetic behind keyword screening no longer separating anyone and behind applications per opening climbing while the shortlist stays the same size.

Write the requirement as a task, not a tool

Take one sentence from the occupation's real task list, add the assistant to it, and name the moment where a plausible wrong answer would get through. Three parts: the act, the object it acts on, and what would make the output wrong. A requirement with all three is readable by a candidate, assessable by an interviewer, and boring to fake, because faking it means describing work.

The source for the act is already published. O*NET carries a task list for every SOC code: 26 statements for financial and investment analysts, including employing financial models and comparing the relative quality of securities in an industry ³. Software developers carry their own, among them modifying existing software to correct errors and analyzing user needs against time and cost constraints ⁴. Start there rather than in a brainstorm, because the list was written by someone with no stake in your requisition.

The rewrite, in order:

1. Pick the exposed task. The one where an assistant would produce a confident first draft and someone downstream would have to catch it. 2. Write it in the second person, as work. "You'll take a denials queue and an assistant that will draft a persuasive appeal for the claim you should be conceding." 3. Name the failure. What does a wrong answer look like, and who pays for it. This is the sentence that makes the requirement job-related instead of aspirational. 4. Cut the adjectives. "AI-fluent," "AI-native" and "prompt engineering experience" are claims, not requirements. Delete them once the task line exists; keeping both puts the low threshold back.

The word count barely moves. A tool list of six products and a task sentence run about the same length, and only one of them tells a candidate whether to apply. If the job requisition process needs the change written up formally, putting AI skills into job requirements is the same edit made at the job-architecture level.

Compare the before and after across six fields

The right task differs by occupation, which is why one house style for the AI line never survives contact with six requisitions. What a marketer does with an assistant is not what an underwriter does, and a requirement copied between them sets a threshold in one field and a mood in the other. The table below rewrites the same generic line six ways, each one anchored to work the occupation actually performs.

Read the right-hand column down and the pattern is one behavior in six costumes: something the assistant produced was checked against the world before it shipped. That is the part that transfers between fields. The task it gets checked on does not transfer at all, and pretending otherwise is how a shared requirement template quietly becomes a mood board. See how Olive measures this is one worked version of the same split: a different assignment per occupation, one frame across them.

One caution on the middle column: these are requirement lines, not interview questions. Keep them in the responsibilities section where a candidate reads them before applying. A task sentence buried under "nice to have" does none of the filtering, because the threshold a candidate reads is the one at the top.

What happens to applicant volume when you change the line?

Raw volume may not fall much, and it is the wrong number to watch. What changes is composition and screenability: the same posting now attracts fewer people who cleared a bar made of tool names, and every applicant who does apply has been told what the work is, so the first screen has something specific to ask about. Judge the rewrite on how many applications survive your first pass, not on how many arrive.

The change also moves the requirement into legal territory worth knowing about. Under the Uniform Guidelines, a selection procedure is any measure used as a basis for an employment decision, and the definition names work experience requirements and unscored application forms outright ⁵. The moment a recruiter drops applicants for missing your AI line, that line is doing selection work, and "used ChatGPT" is much harder to defend as job-related than "has reconciled a model-drafted forecast against source documents," which is a description of the job.

Two failure modes eat the gain:

• Converting the tool name into a years-of-experience minimum. "Five years of LLM experience" narrows the pool by calendar rather than by capability, and in most fields it excludes people who have been doing the work since the tools existed. The task line replaces the tool name; it does not need a number attached.
• Stacking the task line on top of the old bullets. If "experience with AI tools" survives three bullets below the rewrite, the low threshold survives with it. Delete on the same pass.

One more measurement note: give it two full requisition cycles before reading the result. A single posting's volume moves with the season, the salary band and the day of the week, and a rewrite judged on one week of applications will be reverted for reasons that had nothing to do with the words.

Which requirements should you delete instead of rewriting?

The ones on roles where nobody would perform an AI-exposed task in a normal week. Executive pressure to add the line is real. In a survey of 31,000 knowledge workers across 31 markets, 66% of leaders said they would not hire someone without AI skills, and 71% said they would take a less experienced candidate with them over a more experienced candidate without ⁶. That pressure produces AI lines on requisitions where the work does not exercise the skill.

A requirement earns its place when three things are true at once: an assistant could draft a large share of the role's exposed task, that task runs weekly rather than annually, and a plausible wrong answer reaches a customer, a regulator or a board before anyone catches it. Roles that meet one of those get tool access and a short policy. Roles that meet all three get the task-shaped line.

Deleting the requirement is also a volume decision, in the direction people forget. An AI line on a role that does not need it narrows the applicant pool for a capability the job never exercises, while adding nothing you can screen on, which is the worst of both trades. Working out which roles actually need AI skills before the requisition opens is a cheaper exercise than rewriting twelve postings, and naming what AI actually does inside the role is the input to both.

Say how the claim gets checked, in the posting

One sentence, in the posting, naming the check. Federal guidance gives two counters to self-report inflation: creating an applicant expectation that responses will be verified, and actually verifying them ¹. The first is free and belongs in the job description. "Shortlisted candidates complete a 45-minute task in this role's own material, with an AI assistant available" changes what a candidate writes on the way in.

The sentence has to be true, which is the constraint people trip over. If no work sample exists, the posting says nothing about one, and the requirement goes back to being a claim. Build the check first, then write the sentence:

• Keep it short and role-shaped. A task on the occupation's own material, timed, with the assistant open. Long take-homes lose candidates who have options.
• Write the answer key before the invitation goes out. What counts as a source demanded and opened, a suggestion refused, a number recomputed. Without it, the check produces opinions.
• Put it early enough to save work. Assessing before the resume screen instead of after is the version that pays back on a flooded posting, because the screen you are trying to protect is the expensive one.
• Do not add a round. Testing AI skills without lengthening the loop usually means the work sample replaces a screening call rather than joining the sequence.

One restraint worth keeping: the sentence in the posting describes the check, not a verdict. "Scored by AI" and "automated assessment" read as a verdict handed down before anyone has looked, which is not what the check is. Say what the candidate will do, how long it takes, and who reads the result.

See a sample report >