# AI Job Description Generator: A Hiring-Manager Workflow > Use AI to turn verified hiring-manager input into a clear job advert without invented requirements, biased proxies, fake metrics, or hidden working conditions. > Author: Roman Belov · Published: 2026-03-27 · Source: https://futurecraft.pro/blog/ai-job-descriptions/ A job advert is not good because an LLM made it sound polished. It is good when a qualified person can answer five questions quickly: 1. What problem will I work on? 2. What will I be expected to deliver? 3. What authority and constraints will I have? 4. What are the conditions and hiring steps? 5. Which requirements are truly essential? AI can turn those answers into readable copy. It cannot supply answers the hiring team never agreed on. If the input says only “senior backend engineer,” a fluent output is still a guess. ## Keep three documents separate Teams often call everything a job description, but three artifacts serve different purposes: | Artifact | Purpose | | --- | --- | | Internal role definition | outcomes, scope, level, decision rights, interfaces, success evidence | | Person specification | job-related capabilities and acceptable evidence | | Public job advert | enough accurate information for a candidate to decide whether to apply | The public advert does not need every internal detail. It must not contradict the internal role. Generate all channel variants from one approved baseline, or the LinkedIn, careers-page, and recruiter versions will drift. ## Build the source-of-truth intake Ask the hiring manager for facts before asking a model for prose. ### Why the role exists - Is this growth, replacement, temporary capacity, or a new capability? - Which business or customer problem makes the hire necessary now? - What happens if the role stays open? - Is headcount and budget approved? Do not publish sensitive performance information about the person being replaced. ### Outcomes and work Capture three to five outcomes for the first six or twelve months, then the work likely to produce them. Outcomes should be within the role's control. Weak: ```text Own backend development and improve scalability. ``` Better: ```text Within the first quarter, establish a measured latency baseline for the billing path, remove the two largest verified bottlenecks, and document the next capacity constraint. ``` The second version does not promise an invented latency target or dictate a premature architecture. It tells the candidate what evidence of progress will look like. ### Scope and environment - team size and reporting line; - important collaborators; - decisions the role owns, influences, or escalates; - current production stack and what is genuinely optional; - legacy, on-call, travel, location, and time-zone constraints; - work arrangement and expected overlap; - accessibility and accommodation contact; - interview stages and work-sample expectations. Only publish scale figures that the company has approved. Never let the model make the role sound more interesting by inventing traffic, revenue, team growth, or migration plans. ### Conditions Collect verified compensation range and basis, currency, employment type, location, benefits, equity treatment, schedule, leave, probation, and start constraints where applicable. Local disclosure rules change. Route each variant through HR or counsel rather than asking AI to decide which legal fields are required. ## Turn requirements into evidence A requirement should answer: what must this person be able to do, and how could an applicant show it? | Vague proxy | Better job-related evidence | | --- | --- | | “5+ years of Python” | operated and debugged a Python service in production | | “computer science degree” | can reason about the data structures and failure modes used in this role | | “excellent communicator” | can explain an architecture trade-off to engineering and product peers | | “culture fit” | works effectively with the team's stated review and decision practices | | “rockstar who thrives under pressure” | handles the described on-call or incident responsibilities | A proxy may still be justified in a particular regulated or licensed role. The hiring owner must document why. The model should not add a degree, certification, years, language, location, or physical requirement because it often appears in similar adverts. Split criteria by decision value: - **essential on day one:** necessary to perform the core work safely or lawfully; - **learnable after joining:** expected capability with a realistic ramp plan; - **useful context:** experience that shortens the ramp but is not a filter. Do not impose an arbitrary maximum count. A short list is usually clearer, but the real test is whether every essential criterion is defensible and assessed later in the same hiring process. ## Generate from facts only A generation prompt should prohibit completion by stereotype: ```text You are editing a public job advert from an approved role intake. Use only supplied facts. Do not infer or invent company claims, duties, stack, scale, compensation, benefits, location, credentials, years of experience, legal notices, or candidate traits. If a required field is absent, insert [MISSING: field] and add it to open_questions. Preserve uncertainty such as "planned" versus "in production." Structure: 1. role and one-sentence problem; 2. outcomes and representative work; 3. scope, team, and decision rights; 4. essential evidence; 5. learnable or useful experience; 6. verified conditions; 7. hiring process and accommodation route; 8. concise, factual call to apply. Style: - describe the job, not an idealized person; - use direct language and short paragraphs; - remove unsupported superlatives and corporate clichés; - do not discourage applicants who meet essentials but not every preference. Return: - advert_markdown; - open_questions; - claims_requiring_verification; - source_map linking each factual section to intake field IDs. APPROVED INTAKE: {role_intake} ``` The source map is not bureaucracy. It makes hallucinated facts visible during review. The same principle—structured inputs, explicit omissions, controlled output—appears in the [context engineering guide](/blog/context-engineering-guide/). ## Review in five passes ### 1. Factual pass The hiring manager checks each claim against the role intake. Confirm that the listed stack is used by this team, planned work is labelled as planned, and outcomes are not fictional commitments. ### 2. Job-relatedness pass For every filter ask: - Which task requires it? - How will the interview assess it? - Would an alternative background demonstrate the same capability? - Does the criterion exclude people without improving the decision? Delete requirements with no answer. ### 3. inclusion and accessibility pass Check job title, pronouns, idioms, age-coded language, unnecessary physical or location requirements, rigid schedule assumptions, and the way accommodation is offered. Avoid words that describe a demographic proxy instead of the work. In the United States, the EEOC states that job advertisements may not express preferences or discourage applicants based on protected characteristics and that neutral practices can also create unlawful disparate effects when not job-related and necessary. See the [EEOC recruitment guidance](https://www.eeoc.gov/prohibited-employment-policiespractices). In the UK, Acas advises employers to use inclusive language that defines the job rather than the applicant and to consider where the advert is distributed. See [Acas guidance on advertising a job](https://www.acas.org.uk/recruitment/how-to-advertise-a-job). Other jurisdictions need their own review. ### 4. transparency pass Ask which omitted fact would make a candidate withdraw later: pay, location, schedule, travel, on-call, employment type, interview workload, reporting line, or language used at work. Verify the fact before adding it; “competitive compensation” is not a substitute for an approved range. ### 5. legal and policy pass HR or counsel checks local advertising, pay-transparency, equality, privacy, classification, right-to-work, works-council, union, record-retention, and required-notice rules. This is a release gate, not a prompt instruction. If AI later scores resumes, ranks applicants, conducts assessments, or targets delivery, that is a separate and higher-risk system. Writing assistance does not validate selection automation. The EEOC and US Department of Justice have warned that AI hiring tools can screen out people with disabilities and that employers still need accommodation and anti-discrimination safeguards; see the [EEOC/DOJ technical-assistance announcement](https://www.eeoc.gov/newsroom/us-eeoc-and-us-department-justice-warn-against-disability-discrimination). ## Run an adversarial editing prompt After the human factual review, a second model pass can find defects. It should not silently rewrite the advert: ```text Audit the approved draft. Do not change it. Return findings with exact excerpts and proposed edits under: - unsupported or unverifiable claim; - requirement not tied to a stated task; - essential versus learnable mismatch; - ambiguous responsibility or success evidence; - discriminatory or exclusionary language risk; - missing condition likely to cause expectation mismatch; - cliché, repetition, or inflated tone; - conflict between the advert and source intake. Do not give a legal conclusion. Mark items requiring HR or legal review. DRAFT: {job_advert} SOURCE INTAKE: {role_intake} ``` A reviewer accepts or rejects each edit. Do not publish the second model's full rewrite without returning through the factual pass. ## A compact before-and-after example This is a fictional example; the facts are placeholders, not hiring benchmarks. Before: ```text Senior Backend Engineer We are a fast-growing company seeking a proactive team player. You will build scalable services, collaborate cross-functionally, and drive innovation. Requirements: 7+ years, Python, Django, FastAPI, Kubernetes, Kafka, AWS, Redis, PostgreSQL, Terraform, and a computer science degree. Competitive salary and flexible work. ``` After intake and review: ```text Backend Engineer — Billing Reliability The billing team needs an engineer to reduce recurring payment failures and make incident diagnosis faster. This is an existing Python and PostgreSQL system with on-call responsibility; a service split is being evaluated, not pre-decided. Initial outcomes - establish a shared failure taxonomy and baseline from production data; - remove the two largest verified causes of failed renewals; - add runbooks and traces that let the on-call engineer identify the failing step. Essential evidence - operated a backend service in production; - diagnosed failures across application and database boundaries; - wrote and reviewed tests for changes to money-sensitive workflows. Useful context, not a filter - Python or a comparable typed/dynamic backend language; - PostgreSQL performance work; - event-driven systems. Team and conditions [VERIFIED TEAM, REPORTING LINE, LOCATION, SCHEDULE, ON-CALL, PAY RANGE, EMPLOYMENT TYPE, BENEFITS, INTERVIEW STAGES, ACCOMMODATION CONTACT] ``` The revised advert is not better because it is longer. It separates observed work from a possible architecture, replaces a technology inventory with evidence, and exposes the facts still missing before publication. ## Create channel variants without changing the job Derive a short social post, full careers-page advert, recruiter brief, and internal referral note from the same approved baseline. Lock factual fields; allow only length, heading, and format changes. Each variant should retain a baseline version ID. Localization is not translation alone. A local reviewer checks terminology, compensation basis, employment classification, required notices, and whether the application channel is accessible and appropriate for the intended market. ## Measure the whole funnel Track quality without turning the advert into a volume game: - views to completed applications, by source; - applicants meeting the documented essential criteria; - progression and withdrawal at each stage; - time spent in each stage; - expectation mismatches raised in interviews; - offer acceptance and decline reasons; - later evidence that the role definition or assessment was wrong. Analyze demographic impact only with lawful collection, access controls, adequate sample sizes, and qualified HR/legal guidance. Do not put protected-characteristic data into a public model. Comparing an old advert on one platform with a new advert on another is not a useful A/B test: audience and distribution changed too. When testing is appropriate, compare within the same channel and market, randomize or rotate carefully, keep conditions identical, and review both variants for compliance. The [experimentation playbook](/blog/experimentation-playbook/) covers predeclared metrics and stopping rules. ## The operating rule AI should make the approved role easier to understand, not make the company sound more impressive. When the model marks missing compensation, unclear decision rights, or an unsupported requirement, that is a successful output. It found a hiring problem before a candidate had to discover it.