Pipeline
Write a Job Description for a Role AI Already Changed
When AI now does half of what a role used to do, write the job description from a task list, not from the old posting. Sort each task one of three ways: an assistant drafts the first pass, a person has to own the call, or nothing changed. Only the tasks a person owns belong in requirements, because those are what the hire is paid for and the only lines your hiring loop can actually check. The description then reads as accountability instead of tool familiarity.
The takeThe AI sentence is the least important line in the posting. Most refreshes are spent arguing about which tools to name, and they ship a requirements section that still lists the pre-AI task inventory underneath. A posting naming four tools and asking for nothing a person owns will fill with applicants who list the same four tools, and the round after it will have nothing to check. Teams spend the meeting on the sentence that will be edited again in six months and skip the section that decides who applies.
Where Olive fits
Open a role and see what the work shows
Olive is priced per attempt rather than per seat, and one attempt returns six evidenced findings about how a candidate worked with an assistant on a role-grounded assignment. Ten attempts a month are free, so a new requirement can be checked beside the round you already run.
Rank your shortlistWhere does the job description actually change?
In the requirements section. Adding an AI competency to a description whose duties still list the pre-AI job leaves the hire measured against work an assistant now drafts. Delete before you add: production tasks move down into context, and what the role is answerable for moves up into requirements.
Most published advice answers the adjacent question, which is how to use a model to write the posting faster. That advice is fine, and it does not touch this. A posting drafted in four minutes with the same requirements section is the same document, produced sooner.
Start from the difference between a duty and a task. A duty is "own the weekly performance report." A task is "pull the campaign figures, write the summary, flag what moved." Only tasks are small enough to mark, and marking is the whole exercise. If the inventory has not been run yet, find out what AI actually does in this role before the description gets touched.
Indeed's GenAI Skill Transformation Index puts a rough size on the change. It rated almost 2,900 work skills found in US postings on Indeed over a twelve-month window and put 40% in minimal transformation, 19% in assisted, 40% in hybrid and 1% in full, with 46% of the skills in a typical posting falling into the hybrid or full categories 1. Hybrid in that index explicitly means human oversight is still necessary, and the ratings come from models scoring skills rather than from anyone watching the work, so read it as a ceiling on what could change, not a record of what has.
The vocabulary has moved faster than the practice. Counting job titles that carry "AI" or a related term in the employer's own wording, Indeed found US AI-touched titles rising from 264 in the first quarter of 2022 to 822 in the first quarter of 2026, with 63% of them now outside tech occupations 2. That is why the person rewriting this description is often not a technical manager, and why the tools line is the part they feel confident editing.
Sort every task three ways before you write a word
Three marks, applied to a task list. An assistant drafts the first pass. A person has to own the call. Nothing changed. Three columns is deliberate: a five-point scale invites a hedge on every line, and the hedge is where this exercise quietly stops working.
What goes where:
- An assistant drafts it. The first version comes back usable. Summaries, first-pass code, meeting notes, standard correspondence, the routine deck, the initial data pull. Somebody still checks it, and the checking is a separate task that belongs in the second column.
- A person owns the call. The task ends in a decision, a commitment, or a judgment about a number or a person that costs money when it is wrong. Choosing between two options, signing off, deciding a claim is supported, escalating, telling a client no.
- Nothing changed. The task needs an act the model cannot reach: a system with no interface, a conversation, a physical step, an approval that requires a name.
Do the sort with the task list open and the old description closed. Reading them together turns the exercise into a defence of the description.
The second column is what you are hiring for, and it is the column that has to hold up when a requirement is questioned. The Uniform Guidelines on Employee Selection Procedures, the 1978 US federal regulation at 29 CFR Part 1607, define a selection procedure as any measure or procedure used as a basis for an employment decision, and say the definition reaches the full range of assessment techniques, work experience requirements and unscored application forms included 3. A requirements section that applicants are screened against sits inside that definition. That is definitional scope rather than an audit obligation, and what it means for a specific posting is a question for your own counsel. It is still the reason a requirement nobody can trace back to a task is worth deleting before anyone applies against it.
The written sort is the artifact. Keep it beside the description, dated. When the next manager asks why the posting no longer wants five years of report production, the sort answers in one line and the argument ends. From there, writing the AI requirement itself is a shorter sentence than most first drafts contain.
What belongs in requirements after the sort?
Only the second column, written as acts rather than nouns. Every task where a person owns the call becomes one line: checks the model's numbers against the source before the deck goes out, refuses an answer that cannot be traced, decides which of three options the team takes. The first column becomes context so an applicant can picture the day. The third column is what most descriptions under-describe.
Worked, in three occupations that all now carry an AI clause:
- Financial analysis. Out of requirements: builds the model, formats the pack, drafts the commentary. Into requirements: reconciles output against the source system, states which assumption the number is most sensitive to, says when an answer is not supportable yet.
- Marketing. Out: writes the first draft, resizes the creative, assembles the report. Into: decides what the campaign claims, checks that claim against what the product actually does, owns the sign-off on anything going out under the company name.
- Support operations. Out: drafts the reply, summarizes the thread, tags the ticket. Into: decides when a case leaves the script, notices when a confident answer is wrong for this account, escalates before the customer does.
Two tests keep the list honest. Would a competent person with a good assistant still get this wrong? If not, it is context. Does a wrong call here cost more than an hour to reverse? If not, it is context.
What comes out is short. Four to six lines is a normal requirements section after this exercise, and it is shorter than what it replaced. That is the point, and it is also the uncomfortable part, because a short list is harder to hide behind in a debrief.
Write the posting so the requirement is checkable
Write each requirement so you can name, in one sentence, what in the loop would show whether a candidate has it. A requirement with no answer to that question is decoration, and decoration is what produces an applicant pool nobody can sort. Cut it, or move it to preferences and say so, before the posting goes up.
Run each surviving line through three questions:
1. What would prove it? A work sample, a scenario question with a right answer, a reference who watched it happen. If the honest answer is "the interview would probably surface it," that is a hope rather than evidence. 2. Does the loop contain that? If nothing in the round tests the line, either add the round or delete the line. Publishing a requirement the process never checks is how a description turns into a filter that screens on wording. 3. Would a candidate read it the way you do? "Comfortable with AI tools" is read by every applicant as yes. "Checks a generated figure against the system it came from before it ships" is read correctly only by the people who do it.
Then handle the tools separately. Name the stack once, near the bottom, as context. A requirement built on a product name asks which product somebody happened to use, and the stack changes between requisitions.
Last, read the old description beside the new one. If the new one is longer, the sort was additive and the deletions never happened, which is the failure with its own page: what to delete when AI does that part. A refreshed description should end up shorter, more specific, and easier to check than the one it replaced.
Common questions
Should the posting name specific AI tools?
Name them as context, never as the requirement. Listing the stack helps a candidate picture the work and helps them decide whether to apply. Used as a filter, a tool name screens out people who did the identical work in a competing product, and it dates fast: a posting open for six weeks can outlive the version number in it. What transfers between products is the act, so the requirement should say what the person checks or decides and the tools paragraph should say what they will be handed on day one.
What if the team disagrees about which tasks the assistant already does?
The disagreement is the finding, and it usually means two people are describing different weeks. Resolve it by asking each person for the last specific instance: what went in, what came back, what they did with the output. Instances converge where opinions do not. If they still disagree after that, mark the task as a person owning the call, because a task nobody can characterize confidently is not one you want an assistant finishing unsupervised, and the requirement written from it will hold either way.
Should an AI requirement be required or preferred?
Preferred, unless the loop tests it. A required line narrows the pool in a direction you cannot see and invites applicants to claim it, since nothing in the process contradicts the claim. A preference costs nothing, still tells applicants what the work is, and leaves the hiring bar where the evidence is. Move it to required only when there is a round that would actually distinguish a candidate who has it, and when the task it came from is one where a wrong call is expensive.
Does this change the level or the salary range on the requisition?
Often, and in the direction most plans do not expect. If the assistant absorbed the production work, what is left is weighted toward review and judgment, which is more senior work rather than less, even though the hours fell. The safe sequence is to finish the sort first, then set the level from the tasks in the second column, then set the range. Setting the range first and fitting the scope to it produces a posting that asks for senior review at a junior number.
How long does the sort take for one role?
About two hours if the task inventory already exists, and half a day if it does not. Pulling the occupation's task statements and marking them is the fast part. The slow part is the argument about which column three or four contested tasks belong in, and that argument is where the exercise earns its time. Write the result down and date it. Reused at the next requisition, the same file takes twenty minutes to refresh instead of two hours to rebuild.
References
- 1. AI at Work Report 2025: How GenAI is Rewiring the DNA of Jobs ✓ hiringlab.indeed.com Supports the claim that most skills in a role change rather than disappear: 40% minimal, 19% assisted, 40% hybrid, 1% full transformation across almost 2,900 skills, with 46% of a typical posting's skills in the hybrid or full categories.
- 2. AI Is No Longer Just a Tech Occupation Story: It's Spreading Across Job Titles in the US and Europe ✓ hiringlab.indeed.com Supports the claim that AI language has spread beyond technical roles: US AI-touched job titles rose from 264 in Q1 2022 to 822 in Q1 2026, with 63% now outside tech occupations.
- 3. 29 CFR Part 1607 - Uniform Guidelines on Employee Selection Procedures (1978), sections 1607.16(Q) and 1607.3(A) ✓ govinfo.gov Supports the claim that a requirements section is a selection procedure: the Guidelines define one as any measure or procedure used as a basis for an employment decision, covering work experience requirements and unscored application forms.
3 sources, numbered by first appearance. Every one was opened and checked against the claim it carries. How Olive sources claims
General guidance for hiring teams. What works at one company and one volume may not transfer to yours.
Olive assesses how a person works with AI. It does not detect AI-written documents, and it never produces a score, a ranking, or a match percentage for a person. Candidates read the same report the employer reads.