Run "Prove AI Can't Do It" Headcount Cases That Strengthen Good Asks

Workflow area: Org Design & Change · Tier: Core · Hands-on time: ~30 minutes

The question deserves better than either reflex it usually gets. The defensive reflex — "AI obviously can't do this job" — loses, because the CFO has read the same tiny-team articles you have, and assertion against assertion favors whoever holds the budget. The capitulation reflex — quietly shrinking the ask — loses differently, by understaffing the team against work that genuinely needs people. The winning move is to treat the question as a legitimate experiment: actually attempt the role's core work with AI, document precisely where it succeeds and fails, and let the failure modes write the job description. A req that survives an honest AI attempt is nearly unblockable — and a req that doesn't survive it is one you should be glad you didn't fill.

When to use — and when not to

• Use it for every senior or specialized req you expect to defendthe evidence takes a week of background effort and converts a negotiation into a review.
• Use it preemptively, before being askeda headcount case that arrives with the AI analysis already attached signals you govern this seriously (and pairs with pb-40's spend discipline).
• Use it when the answer might genuinely be "AI can, partly"the honest partial result lets you reshape a req (different level, different focus) instead of losing it whole.
• Skip the theater for roles where the question is absurdan SRE lead for a 24/7 payments platform doesn't need a demonstration that Claude won't carry a pager; a two-line judgment note suffices, and over-processing signals weakness.
• Don't rig the attempta sandbagged demo (vague prompts, no context, gotcha tasks) is detectable by anyone technical in the approval chain, and one detected rig taints every future case you bring.

The recipe

1. 1.

   Decompose the role into its real work, not its job description. List the 6–10 activities the hire will actually spend time on, with rough weekly-hour weights. "Senior backend engineer" decomposes into: extend the billing domain model, review the team's PRs, debug production incidents, negotiate API contracts with two partner teams, mentor two juniors, make build-vs-buy calls. The decomposition is half the argument — vague roles invite vague AI claims.

2. 2.

   Attempt each activity with AI, competently. Give it the real fight: your best prompting, proper context files, current tools, an experienced operator. For each activity, run a genuine trial on real (redacted) work samples and log what happened:

   Copy

   AI ATTEMPT LOG — [req title], [date], [tools/models used]
   Activity: [e.g., debug production incident from alert to fix]
   Setup: [context provided, who operated, time spent]
   Result: [what the AI produced, verbatim excerpts where telling]
   Verdict: HANDLES / ASSISTS / FAILS
   Observed failure mode (if any): [specific and quotable — e.g.,
   "proposed a fix for the symptom in the retry logic; root cause
   was a connection-pool config interaction it had no visibility
   into and did not ask about"]
   Human remaining even in HANDLES cases: [who verifies, who is
   accountable]
   

3. 3.

   Have Claude stress-test your own case before finance does.

   Copy

   Here is a headcount request and the AI-attempt log behind it.
   Act as a sharp CFO's analyst:
   1. Which "FAILS" verdicts look like operator error or missing
      context rather than genuine AI limits? Be specific.
   2. Which activities marked ASSISTS could plausibly shift the
      req down a level or to 0.5 FTE?
   3. What is the strongest version of the case AGAINST this
      hire? Steelman it.
   4. What evidence would make the case airtight?
   [PASTE REQ + LOG]
   

   Fix what it finds. A case that survives your own red team survives the meeting.

4. 4.

   Write the human-necessity argument from the failure modes. The strong form is never "AI is bad" — it is accountability, context and judgment are not features:

   Copy

   HEADCOUNT CASE — [role] (1 page)
   THE WORK: [decomposition with hours]
   WHAT AI NOW COVERS: [honest list — this is why the req is 1
   engineer, not the 2 we'd have asked for in 2023]
   WHAT IT DEMONSTRABLY CANNOT: [3-4 observed failure modes from
   the log, quoted — cross-team negotiation, novel-incident
   judgment, accountability for irreversible calls, mentoring]
   THE ASK: [level and shape, explicitly informed by the above —
   "senior, because the residual work is precisely the
   high-judgment share"]
   COST OF NOT FILLING: [what breaks or slows, with numbers]
   Attached: AI-attempt log.
   

   Note the concession in the middle — acknowledging what AI covers is what makes the rest credible, and it often raises the level of the ask: when AI absorbs the routine share, the human share concentrates in judgment, which argues for seniority.

5. 5.

   Keep the evidence log as standing infrastructure. Every attempt log joins a running file. Over quarters it becomes your org's empirical map of AI capability boundaries — feeding not just headcount cases but role design (pb-45), upskilling priorities (pb-46), and the exec narrative (pb-52). Refresh verdicts when models change materially; a 2025-era "FAILS" is not evidence in 2026, and citing stale failures is how credible cases rot.

Make it yours

• Startup or small team: the finance reviewer may be your co-founder and the log may be a page — but run the discipline anyway, because at seed stage every hire is 5% of burn and the honest ASSISTS findings frequently reshape the role you actually post.
• Mid-size org: standardize the one-page format across your leads so headcount review compares like with like, and pre-agree with finance what evidence counts — a jointly designed template turns the adversarial question into a shared protocol.
• Large org or GCC: expect the question institutionalized — some orgs now require an AI-impact statement on every req — so maintain the evidence log at org level with an owner, and in a GCC add the client dimension: staffing cases on client accounts can cite contractual accountability and data-boundary requirements as human-necessity arguments, but only alongside the capability evidence, never instead of it.

Quality check

• The attempt was competentan AI-savvy reviewer would agree the tools got a fair fight; check the log's setup lines for real context and real operators.
• Failure modes are observed and quoted, not asserted"AI can't do judgment" is opinion; "proposed the symptom fix, missed the pool-config root cause, transcript attached" is evidence.
• At least some reqs changed shapeif every case you run concludes "hire exactly as originally planned," the process is rationalization; honest logs sometimes say ASSISTS.
• The concession section is reala case listing nothing AI covers reads as advocacy and invites the CFO to write that section for you.
• Verdicts carry dates and model versionscapability boundaries move; undated evidence is expired evidence.