Drafting a Job Description With AI Without Inventing Requirements

Can you draft a job description with AI?

Yes. Drafting a posting is one of the better uses available. Short, self-contained professional writing is where the measured gains are clearest, and a job description is exactly that. What the model cannot do is know your job, so the drafting help is real everywhere except the one section that decides who gets screened out.

The evidence on this kind of writing is unusually direct. In a pre-registered online experiment, 444 college-educated professionals did occupation-specific writing tasks, and the half given ChatGPT finished 10 minutes faster, 37%, against a control group averaging 27 minutes, with graders scoring their output 0.45 standard deviations higher and the largest gains going to the weakest writers ¹. Those were one-sitting tasks with no revision cycle and no colleagues, which describes a first draft of a posting well and describes almost nothing else in hiring.

So split the document before you prompt anything. Three parts of a job description are drafting problems:

• The summary of the role. The model tightens what you feed it.
• The context paragraph. Team, stack, who the person works with, what the day looks like.
• The benefits, location and process boilerplate. Genuinely repetitive, genuinely fine to generate.

One part is not a drafting problem at all: qualifications and requirements. That section is a set of claims about who can do this job, and every line in it is a bar somebody may be rejected against. Generating it is the difference between using a model to write faster and using one to decide who gets considered.

Give it the task list, never the job title

A title is an instruction to average. Asked for requirements for a "senior marketing manager," the model returns the central tendency of every public posting under that title, which is a real document made of other companies' compromises and none of your work. A task list gives it something to compress instead of something to imitate.

What to put in the prompt, in this order:

1. Fifteen to twenty task statements for the role as it is performed now, marked for which ones an assistant already drafts. 2. The constraints: level, range, location rules, who this person reports to, what they own end to end. 3. Three things that go wrong when the role is done badly. This is the input that produces a specific description rather than a competent one. 4. An instruction to omit qualifications entirely, and to list assumptions it would otherwise have made.

That last instruction is the one worth keeping. The assumptions list is genuinely useful output: it shows you which requirements the averaging would have inserted, which is a decent map of what your competitors ask for and a terrible map of what your job needs.

The prompt cannot supply a task list you never made. Finding out what AI actually does in this role takes about half a day and it is the input every later step reads. Without it, a model-drafted description is a plausible average, and a plausible average is what a thousand applicants feed straight back into their own model, since the job description becomes the candidate's prompt the moment it is published.

Which requirements survive the trace-back?

The ones that point at a task in your list and at evidence in your loop. Take each requirement the draft produced, name the task it comes from, then name what in the process would show whether a candidate has it. Two answers and the line stays. One answer and it moves to preferences. No answers and it goes.

The reason to be strict is not tidiness. A hiring test has to measure the person for the job rather than the person in the abstract, and the touchstone the US Supreme Court set for a practice that screens people out is business necessity, with nothing forbidding testing as such, only giving a device controlling force unless it is demonstrably a reasonable measure of job performance ². That is 1971 language about aptitude tests at a power plant, quoted here for the principle rather than as advice, and the principle is the one a generated requirement fails: nobody can say where it came from.

The trace-back also catches the subtler failure, which is a requirement that is true, traceable, and still not checkable. "Strong analytical judgment" traces to real tasks. Nothing in a four-stage loop distinguishes a candidate who has it from one who describes it well, so it functions as a line that admits everybody and justifies rejecting anybody.

A draft that reads well earns no extra trust. A field experiment with 758 Boston Consulting Group consultants included one task deliberately chosen to sit outside AI capability, and on that task the consultants using GPT-4 were 19 percentage points less likely to reach the correct answer, 84.5% of the control group against 60% and 70% in the two AI conditions ³. They could not tell which side of the line their task sat on, so the failure arrived as a confident wrong answer on work that looked like work the model handles well. A qualifications section nobody traced has that shape. For the wording itself, an AI-skills requirement that is not legally vague is shorter than most drafts produce.

Say what applicants may use, since you used it

Put one line in the posting stating that applicants may use AI and that the process checks judgment rather than polish. A team drafting its posting with a model while penalizing candidates for sounding like one is holding a position it will be asked about, and the version that survives the question is the permissive one, because the alternative depends on telling generated writing from careful writing, which nobody can do reliably.

The practical shape of the line is short: AI is allowed at every stage, the work is checked for judgment, and anything a candidate submits they should be ready to talk through. That gives you a defensible round and it gives strong applicants a reason to believe the process is not a guessing game. It also heads off the thing that actually damages a pipeline, which is managers rejecting candidates for sounding like AI on no evidence at all.

Your sense of how much the model helped is not a measurement. In a randomized trial, 16 experienced open-source developers forecast that AI tools would cut their completion time by 24% and estimated afterwards that it had cut it by 20%, while the measurement showed the tools made them 19% slower ⁴. Sixteen developers on codebases they knew intimately is a narrow setting and the magnitude does not transfer. The gap between belief and measurement does.

So measure the description the way you would measure anything else: applications per week, the share that clear the first real check, and whether the hiring manager recognizes their own job in the document. A generated draft that shortens the writing by an hour and adds two unowned requirements has cost more than it saved, and the cost lands on people who never see the document that rejected them.

See a sample report >