What to Delete From a Job Description When AI Does That Part

What comes out of the description first?

The production verbs. Every line built on drafts, writes, formats, compiles, transcribes, summarizes or assembles, where the assistant now produces a usable first pass, moves out of requirements and into context or out of the document entirely. That is the cut that never gets made, because it is the one that makes a description shorter and everything else in a refresh makes it longer.

What is being deleted is a claim about the hire, not a claim about the work. The report still gets written. The question is whether writing it is what you are hiring for, and whether a candidate who cannot produce that first draft unaided has failed anything that matters now.

Keep the deletion list narrower than the discourse suggests. Indeed's index of almost 2,900 work skills rated 19 of them, 0.7%, as very likely to be fully replaced, up from zero in the previous edition ¹. A skill is not a job, and no job in that analysis is made only of those 19, so the honest reading is that very little vanishes outright and a great deal changes hands.

The direction of travel is measurable even where the magnitude is not. The Burning Glass Institute found skills exposed to automation were 16% more likely than baseline skills to see demand decline in postings, while skills exposed to augmentation were 7% more likely to see demand increase ². Those are relative likelihoods rather than the size of any change, and the same occupations show both at once, which is exactly what a refresh has to encode: some verbs go down, others go up, inside one role.

If the exposed tasks in this occupation have never been listed, do that first. What AI actually does in this role is a half-day exercise and it makes the deletions arguable instead of instinctive.

Cut the production verbs, keep the accountability verbs

Two verb lists, and the whole refresh is moving lines between them. Production verbs name output: drafts, writes, builds, formats, compiles, summarizes, transcribes, assembles, maintains. Accountability verbs name a call somebody has to make: decides, approves, verifies, reconciles, refuses, escalates, prioritizes, signs off. The first list describes what the role emits. The second describes what it is answerable for.

Three deletions, in order of how much argument they cause:

• Production verbs in requirements. Move them to a short context paragraph, or delete them. "Drafts weekly client updates" tells a candidate what the day looks like. As a requirement it screens for a skill the assistant now supplies.
• Software-proficiency lines the assistant absorbed. Advanced formula work, deck formatting, transcription, basic query writing, boilerplate correspondence. These were proxies for productivity and they no longer separate anyone.
• Certification and tool lines nobody in the team holds. If the current team would not pass the requirement, it is not a requirement, and it is the line most likely to be doing quiet demographic work rather than job-related work.

Then sharpen what stays. An accountability verb with no object is as empty as a production verb: "verifies data quality" is a sentence anyone claims. "Reconciles the reported figure against the source system before it goes to the client" is a sentence that can be checked, argued with, and taught.

One caution about deleting a whole role's worth of production. If the work an assistant now drafts was the entire junior half of the job, the description is not the only thing that needs revisiting, and neither is the requirements section. Whether the level and range still fit is a separate decision, and it is the one most refreshes skip.

Why does the years-of-experience line need rewriting?

Because the thing those years stood in for was volume practice at the production tasks you just deleted. Five years of building models meant thousands of models built. If the first pass now arrives in seconds, the count of years no longer proxies the judgment you actually want, and it screens out people who acquired that judgment faster while admitting people who never had to exercise it.

Keep a line there. Name what the years were standing in for and ask for that instead:

• Instead of "5+ years in financial analysis," try "has owned a forecast through a cycle where the first version was wrong."
• Instead of "3+ years agency experience," try "has decided what a campaign claims and defended that claim to a client."
• Instead of "experience with high-volume support," try "has judged when a case leaves the script and escalated before the customer did."

Those read longer on the page and shorter in practice, because each one names a single thing an interviewer can ask about and a reference can confirm.

There is a legal reason to prefer them too, and it is the plain one. Under Title VII's disparate-impact provision, added by the Civil Rights Act of 1991, a US employer defending a practice that produces a disparate impact must show it is job related for the position in question and consistent with business necessity ³. A requirement written from a task the role performs is straightforward to describe that way. A years count inherited from a version of the job that no longer exists is harder, and this is public legal context rather than advice: run any wording change past counsel.

And treat the fashionable additions with the same suspicion. LinkedIn projects that 70% of the skills used in most jobs will change by 2030 ⁴, which is a forecast rather than a measurement, and it is quoted in most refresh guides as though it authorized adding a competency to every description in the library. It does not. It argues for descriptions that are easier to change, which means shorter ones.

Check that the posting got shorter

Put the old description and the new one side by side and count. If the refreshed version is longer, the AI clause was added on top of a task inventory nobody pruned, and the posting now asks for the old job plus a new competency. That is the common outcome of a refresh cycle and the reason a library of descriptions drifts toward unreadable over three or four passes.

Four checks before it goes back in the library:

1. Word count down. Not by a token amount. If the requirements section reads at the same length it did before, nothing was cut and the pass is not finished. 2. Every remaining requirement traces to a task somebody performs this quarter. Ask the manager to name the last time each one mattered. Lines that get a pause are the lines to cut. 3. The AI clause names an act. Writing an AI requirement that survives contact with a lawyer is a shorter sentence than most first drafts, and a tool name in that slot dates within a quarter. 4. The description would be recognized by the person doing the job. Send it to them. Two minutes of their time catches more than an hour of yours.

Run the library in waves rather than all at once. Start with the roles where the exposed tasks are obvious and the volume is high, and leave the rest until you have a pattern worth copying. Which roles actually need an AI requirement is the triage that keeps this from becoming a project, and roles that do not need one need no refresh at all.

The last check is the honest one. If cutting the production verbs leaves a requirements section with four lines in it, the description is finished, and the discomfort of a short document is not a reason to put anything back.

See a sample report >