AI job descriptions: rewrite roles before you hire again

Why old job descriptions stop working

Many AI job descriptions still read like pre-AI checklists. They focus on work people used to do by hand: first drafts, routine replies, basic research, status updates, simple analysis, and standard documentation.

That used to make sense because those tasks filled most of the week. It stops making sense once AI can produce them in minutes.

The work does not disappear. The center of the job moves. Instead of spending most of the day creating the first version, people spend more time checking it, correcting it, deciding when it should not be used, and stepping in when the situation does not match the pattern.

Old job descriptions hide those harder calls. They describe the easy, repeatable parts because those were easier to list and easier to measure. After AI enters the workflow, the repeatable parts shrink and the messy parts take over.

That mismatch attracts the wrong applicants. You get people who fit yesterday's work: fast writers, fast researchers, fast ticket closers, fast producers of standard output. You miss people with domain knowledge, judgment, and the patience to deal with exceptions.

The cost shows up early. In the first month, the new hire thinks success means volume while the manager needs careful decisions. The hire expects to create from scratch. The team expects them to review AI output, catch bad assumptions, and handle unusual cases. Nobody feels aligned, and the role starts to look fuzzy even when the real problem is the job description.

This is common in small companies that shift to AI-heavy workflows. A startup posts for a support hire and asks for quick replies, help center updates, and ticket summaries. On day one, AI already drafts most of that. What the person actually needs to do is calm upset customers, spot policy gaps, and know when a bug, refund, or security issue needs escalation.

If the post still describes the old task list, the search starts with the wrong frame. You are not hiring for the work that fills the day now. You are hiring for the work the team used to need.

What the role owns now

After AI takes over routine work, the job usually gets narrower and more serious. The person you hire owns the messy parts: unclear cases, risky calls, and moments when a fast answer can still be the wrong answer.

Start by separating repeatable work from decisions that need judgment. If a model can draft replies, sort tickets, summarize notes, or prepare a first-pass analysis, that work should not define the role anymore. The role should define what happens when the pattern breaks.

That usually means ownership of cases with missing, conflicting, or unusual information. It also means handling exceptions that affect money, contracts, trust, or compliance. In some teams, it means deciding when an AI output sounds convincing but should not go out. In others, it means making the final call when the cost of a mistake is high.

Write those decisions in plain language. A vague duty like "manage support operations" tells candidates very little. "Approve refunds above a threshold, override AI replies in account disputes, and escalate suspected security issues" tells them what the job actually is.

Rewrite the role before you post it

If you want a useful job description, ignore the org chart for a week and watch the work itself. Read tickets, sit in on handoffs, review drafts from AI tools, and note where people stop, double-check, or ask a senior person to step in. Most weak AI job descriptions describe yesterday's workload, not today's exceptions.

Start with one week of evidence

Map the role by actual tasks, not by status or title. For each task, use a simple label: AI handles it well, AI handles it with review, or a person takes over because the case gets messy.

This exercise clears up more confusion than most planning meetings. Routine work often moves faster, but the hard parts do not go away. They get concentrated. A support team might let AI draft common replies all day, yet refunds, policy edge cases, and angry enterprise customers still pull team leads into the loop. A product team might use AI for routine code, while outages, security decisions, and strange legacy bugs still land with senior engineers.

Count those pull-ins. If the same problems keep reaching the same senior people, that is not random cleanup. That is the new center of the role.

Turn exceptions into scope

Now rewrite the job around those cases. If someone needs judgment, define where that judgment starts. Write down which exceptions they own, what they can decide without approval, and what they should improve so the team sees fewer repeats next month.

A strong role description makes four things clear: which situations need escalation, which decisions belong to the role, what work needs human review before it goes out, and which repeat failure patterns this person is expected to reduce.

Then define success for the first 90 days in plain language. Skip lines like "manage workflows" or "support AI adoption." Say what results matter. Examples are much better: reduce senior review time on support escalations by 25 percent, document the 15 cases AI still gets wrong, or cut repeat billing exceptions by tightening prompts and review rules.

That gives candidates something solid to react to. It also helps you reject the wrong profile early. Someone who only knows how to handle standard cases will struggle in a role built around judgment.

What to include in the job description

Lead with the decisions this person owns. Most job posts start with duties, but duties blur together. Decisions show candidates where they will use judgment. If the role can approve refunds up to a limit, override an AI suggestion, escalate product issues, or reject a risky customer request, say that in the opening paragraph.

Then show a few messy situations. That is where strong candidates pay attention. Generic task lists hide the real job. A customer says the AI-generated answer is wrong, but the account data is incomplete. A large client wants a special process that will slow support for everyone else. A bug report looks urgent, but the logs suggest the customer changed settings on their side. These examples make the role feel real.

Be direct about how the person will use AI every day. Say whether they draft responses with AI, review AI output before it reaches customers, check transcripts after AI triage, or write feedback that improves prompts and workflows. If AI handles the first pass and the person handles exceptions, write that clearly.

Spell out what good judgment looks like on your team. Maybe you want someone who slows down before sending a risky answer. Maybe you need someone who spots patterns across cases or sees when a quick fix today will create a bigger problem next week. Put that in the post. Generic lines like "good communicator" do not tell candidates much.

Cut the filler. Skip words like "ninja" and "rockstar." Skip giant task lists that read like three jobs taped together. The best AI job descriptions are short, specific, and honest about the hard parts. A candidate should finish reading and know what they would decide, where AI helps, and where a human still needs to think.

A simple example from customer support

A support job used to read like this: answer every ticket fast, follow the script, keep response times low. That made sense when humans wrote every reply. After AI adoption, that description points at the wrong work.

If a bot can draft most routine answers, speed stops being the main skill. The human job shifts to judgment. The support hire checks what the bot wrote, spots where the tone is wrong, and steps in when a reply could cost money or damage trust.

Picture a customer writing in after a failed refund during an outage. The bot sees the word "refund" and sends a standard billing note. A good support specialist notices the real issue right away: the outage may have caused duplicate charges, the customer is angry, and the account may need a manual fix. That person rewrites the message, checks the account history, and makes sure the customer gets a clear answer.

To do that well, the person needs real knowledge of billing rules, outage handling, and the point where finance or engineering must step in. That is domain depth, not ticket speed.

In a rewritten support role, the person might review or replace AI drafts in risky cases, handle refunds and billing disputes, catch moments when the bot confuses customers, and log repeat failure patterns instead of treating each ticket as a separate event. They should also send recurring issues back to product and operations with enough detail to fix them.

That is a different hire. You are not looking for the fastest person in the queue or someone who depends on canned replies. You want someone who can read a messy situation, make a fair call, and explain it in plain language.

Many teams miss this shift. They keep the old target, like ticket volume or first reply time, and add "use AI" as a side note. The better version says the person owns exceptions, protects customer relationships, and turns support patterns into product changes.

When you write the role that way, stronger candidates recognize themselves in it. Weaker ones usually do not. They talk about speed and scripts. The people you want talk about judgment, odd cases, policy calls, and how to stop the same problem from showing up tomorrow.

Mistakes that waste time in the search

Most searches go wrong before the first interview. The team posts a role built for an old workflow, then spends weeks sorting through people who look fine on paper and wrong in practice.

One common mistake is hiring for prompt writing instead of judgment. Good prompts matter, but most smart candidates can learn them quickly. The harder part is knowing when an answer is good enough, when a model is drifting, and when a messy case needs a human decision.

Another mistake is loading too much into one role. The post ends up covering tool setup, process redesign, team training, reporting, quality control, edge cases, and business results. That is not one job. It is three jobs forced into one budget line.

Copying last year's description and swapping in a few AI words is another trap. The title changes, but the work does not. If AI now handles the first draft, the person you hire should own review, exceptions, quality, and policy decisions. If the draft still rewards pure output, you will attract the wrong candidates.

Teams also skip the hardest question: who reviews wrong answers and odd cases? AI creates more gray-area work, not less. Someone has to catch bad summaries, risky replies, strange customer requests, or numbers that look plausible and still fail a basic sanity check. If nobody owns that layer, problems spread quietly.

Volume-only metrics make the search worse. More tickets closed or more content produced can look impressive while quality drops. A better scorecard tracks speed, error rate, escalation choices, and whether the person prevents repeat mistakes.

A simple gut check helps. Remove every tool name from the draft role. If the job still makes sense, you are close. If it falls apart, you are still hiring for software familiarity rather than business depth.

That mistake gets expensive fast. You do not only hire the wrong person. You teach the whole team to chase output and ignore judgment.

How to interview for judgment

A trivia quiz tells you who memorized facts. It does not tell you who can make a sound call when the facts are incomplete, the customer is upset, and the AI gave a half-right answer.

If the role depends on judgment, the interview should test judgment under a little pressure. Use one messy scenario that feels close to the real job. For a support or operations role, that might be a customer complaint with missing account details, an AI-written reply that sounds confident but makes a promise the company cannot keep, and a note from sales asking for a fast fix.

Start with one simple question: "What do you do in the first 10 minutes, and why?" Strong candidates pick an order. They do not talk in circles. They tell you what they check, who they contact, what they pause, and what they refuse to send.

A few follow-up questions are enough. Ask what they would verify before acting on the AI output. Ask where they would trust the AI and where they would stop and check. Ask which risk matters most if they guess wrong. Ask when they would escalate and what extra context would change their decision.

Listen for tradeoffs, not polished language. A solid answer often sounds plain: "I would confirm the account history first because the draft reply offers a refund and that creates a cost and a precedent." That shows domain sense. So does saying, "I would not let AI answer this alone because it touches billing, access, and contract terms."

One of the best tests is a flawed AI output. Give the candidate a draft that is mostly fine but wrong in one or two important ways. Maybe it misses a compliance issue, suggests the wrong priority, or uses a tone that will make the customer angrier. Ask them to fix it and explain each change.

Watch for two weak patterns. Some people trust the AI too quickly. Others reject it on principle and waste time doing everything by hand. You want the middle ground: someone who uses the tool for speed, spots the failure point, and knows when a human should take over.

Checks before you open the search

A weak job post creates a weak search. If AI now handles drafts, routine updates, and first-pass analysis, the person you hire should own the moments when the normal flow breaks.

Before you publish anything, hand the role summary to someone outside the team. If they still cannot tell which calls this person makes without follow-up questions, the role is still fuzzy. "Manage operations" tells nobody much. "Decide when to override the model, escalate a customer issue, or approve a risky release" is much clearer.

Name the exceptions. Most teams forget this part. They describe the normal daily work and skip the rare cases that matter most. Those cases often justify the hire: an angry enterprise customer, suspicious model output, a bug that touches billing, a compliance request, or a production change that cannot wait.

Before you open the role, do five quick checks:

• Write down three to five decisions the role owns alone, and two it only recommends.
• Remove tasks automation already does well, such as first drafts, routine status updates, basic triage, or template replies.
• Define what good work looks like at 30, 60, and 90 days with results the team can notice.
• Check pay against the level of judgment you expect.
• Decide whether the job needs deep domain knowledge or whether a strong generalist can learn fast enough.

This is where many AI job descriptions break down. They ask for senior judgment, domain depth, and calm exception handling, then price the role like task execution. That mismatch slows the search and fills the pipeline with people who look fine on paper but cannot carry the real load.

If the role still reads like a list of activities, stop and rewrite it again. A good version makes ownership obvious, cuts work that automation already covers, and gives both sides a fair picture of the job.

What to do next

Pick one open role and rewrite it before you approve another job post. Do not start with the hardest position on the org chart. Start with the role where AI has already changed the daily work, even if nobody has said it out loud yet.

Most job descriptions improve after one honest rewrite and one hard review from the people who deal with exceptions every day. If a draft still reads like "do the task faster," it is still an old role with new wording.

A simple process works. Rewrite the role around decisions, exceptions, and domain knowledge. Ask the people who fix bad outputs, escalations, and unusual customer cases to review it. Use the first interviews to test the role scope, not just the candidates. Then edit the post before you widen the search.

That review step matters more than most teams expect. The people handling exceptions today know where automation fails, where judgment matters, and where the role still needs a human. Ask them direct questions: what lands on your desk when the system gets confused, what mistakes cost money, and what requires context rather than speed?

Use early interviews to find blind spots. If several candidates misunderstand ownership, your draft is vague. If strong candidates keep asking the same question about approval rights, priorities, or escalation paths, fix the role before you keep interviewing. Five early conversations can save weeks of wasted search time.

A small startup can do this in a day. Take one role, mark what AI now handles, mark what still needs judgment, and rewrite the scope in plain language. That is usually enough to expose missing responsibilities or work that belongs in another seat.

If your company is redrawing roles after AI adoption and the org chart no longer matches the real work, Oleg Sotnikov at oleg.is can help review the hiring plan, workflow, and technical ownership as a Fractional CTO or advisor. That kind of outside review is useful when the team can feel the mismatch but has not yet defined the new role clearly.