How Many People Do You Need If AI Takes Part of the Workload?

How many people do you actually need next year?

Fewer in one or two occupational families, the same in most, and more in at least one. The company-wide answer is unusable because none of its inputs are company-wide. Run the arithmetic per family: hours spent on tasks an assistant can already draft, times a gain you have measured on your own work, minus the review time those drafts create. What comes out is a band, not a number.

The plan itself is old arithmetic. Headcount equals forecast work volume divided by throughput per person. AI moves one term, unevenly, and only where it lands:

• Exposed hours, not exposed tasks. A task an assistant drafts well in four minutes matters to the plan in proportion to the hours it currently eats. Most task lists carry two or three lines worth half the week and a dozen worth an afternoon between them.
• Realized gain on those hours. The figure from your own work, not from a vendor deck and not from the pilot team's enthusiasm. Until it has been measured, the honest entry is zero.
• Added review time. Every draft that ships needs someone to check the claim it rests on. That work is real, it lands on your most senior people, and it is missing from nearly every plan showing a saving.

Two further terms decide whether a throughput gain becomes a headcount change at all. Demand is the first: if the work is rationed by a backlog rather than by customer volume, a faster team clears the backlog and hires on the same curve. Skill mix is the second: the gain often appears at exactly the level you were about to hire into, which changes who you hire rather than how many.

Start from what AI actually does inside each role, then from the roles where exposure is real. A plan built on titles is a plan built on a job architecture that was written to set pay bands.

Why does one company-wide productivity number fail?

Because it is wrong in both directions at once. Exposure varies several-fold across occupations, so a blanket cut over-prunes the families where a model already drafts most of the work and leaves untouched the families where it drafts almost none. The same assumption then under-invests where the gain is real. One number, two opposite errors, and no way to see either from the top line.

An exposure study covering the whole U.S. workforce put around 80% of workers at 10% or more of their tasks affected by large language models, and about 19% of workers at half or more of their tasks ¹. Both figures describe the same labor market. The distance between them is the spread your plan is pretending does not exist.

Depth follows the same shape. Usage data across occupations found roughly 36% showing AI use for at least a quarter of their tasks and only about 4% for at least three-quarters ². Broad and shallow: most families have some exposed work, very few are mostly exposed work, and a company-wide mandate prices every family as though it were the second kind.

There is an accounting reason the average lies, too. A company-wide figure is dominated by the largest family, so the number you compute describes your biggest team and is then applied to a controller group, a field operations group and a research group whose task mixes have almost nothing in common with it. Two companies with identical org charts land on different answers because one has a review step after the exposed work and the other removed it in a reorganization three years ago.

Measure the realized gain before you spend it

The gain in your plan has to come from your own work, because the published measurements disagree by sign. Controlled studies have found large gains for new workers, close to nothing for experienced ones, and a measured slowdown for experts working in code they already knew. None of those is a company-wide multiplier. A number you did not measure is a preference with a decimal point on it.

The two most useful measurements point in opposite directions, and both are real:

• Large gains, concentrated at the bottom of the experience curve. Across 5,179 customer support agents given an AI assistant, issues resolved per hour rose 14% on average, but about 34% for novice and low-skilled workers, with minimal effect on experienced and highly skilled ones ³. If your exposed family is mostly senior, the average in that headline is not your number.
• A measured slowdown among experts on familiar ground. In a randomized trial, 16 experienced open-source developers took 19% longer to complete 246 issues when allowed to use early-2025 AI tools, in repositories they already maintained. They had forecast a 24% speedup, and after finishing still believed they had been sped up by 20% ⁴.

That 39-point gap between what the developers experienced and what they believed is the single most important line for a planner. Self-report is the weakest instrument in the building, and it is what most headcount assumptions are built from. A follow-up run on late-2025 tools, with 57 developers across 800-plus tasks, still measured no speedup (roughly -18% for returning participants and -4% for new ones, both intervals wide enough to cross zero), and the researchers say selection effects make even that weak evidence ⁵.

So measure. Take one exposed family, split real work between an AI-allowed arm and an AI-disallowed arm for a month, and count completed units and rework rather than asking anyone how it went. Two arms, one month, real tickets. That gives you a low and a high for one row of the table, which is more than any published figure can give you.

Run the range per occupational family

Five columns, one row per family, filled in a morning from documents you already own. Current headcount, share of hours on tasks an assistant can draft, the low and high gain you measured, and the review time added. Compute the need at both ends, then write the one thing that would move the row. The output is a band per family and a date to look again.

1. Map families to occupations, roughly. Your "Senior Insights Manager" is a market research analyst or a data scientist. Pick one, take the published task list, and move on. The point of an external list is that nobody in the budget meeting wrote it. 2. Weight the exposed tasks by hours, not by count. Ask the manager which three tasks eat the week. Exposure on a task nobody spends time on is worth nothing to the plan. 3. Enter the gain as a range. Low end and high end from your own two-arm measurement. If you have not measured, the low end is zero and the high end is whatever the pilot claimed, which is a wide band on purpose. 4. Subtract the review time. Percentage points of senior capacity spent checking drafts that would not otherwise exist. Nobody enjoys this column; every plan that omitted it has been wrong. 5. Divide forecast volume by the result, at both ends.

A worked example, four families of a hundred people each, flat volume:

Four hundred people today; the honest total for next year is 385 to 411. No single percentage would have produced either end, and the two families that move most move in opposite directions. That total is not a hedge. It is the finding. It tells you which family to measure first, because narrowing software engineering is worth eleven people and narrowing field operations is worth one.

What do you do with a range instead of a number?

Budget the low end, pre-approve the difference as requisitions that open on evidence, and attach a named trigger to every row. A range is a commitment device: it says what you would have to see before moving, in advance, while nobody is arguing. The trigger is a measurement (completed units per person, rework rate), never a seat-licence count or a training completion rate.

Four things the range changes that a single number cannot:

• The entry level gets planned deliberately. Payroll data covering millions of U.S. workers shows employment of 22-to-25-year-olds in the most AI-exposed occupations sitting 19% below where it would be had it tracked their less-exposed peers, with no comparable gap for experienced workers in the same occupations ⁶. Your senior bench is a stock that juniors refill; cutting the intake is a decision about 2030 taken in a 2027 budget meeting. Whether a junior with an assistant substitutes for a senior is the question to answer before the requisition closes, not after.
• Train-or-hire is decided per family. A family with three exposed tasks and a patient manager is a training problem. A family where the exposed work is most of the job is a hiring decision with its own arithmetic.
• The review column gets an owner. Training people to check their own output is worth doing and is not the same as having a second reader, and treating training as a substitute for verification is how a plan books a saving that shows up later as rework.
• The hiring bar gets written before the requisition. If the plan assumes people who work well with an assistant, the loop has to be able to tell. That means a work sample with the assistant present, a rubric written beforehand, and knowing what an assessment result does and does not predict before it carries any weight.

Revisit rows when a trigger fires, not on a calendar. A tool that lands in the finance stack, a review step removed, a team absorbing a function: each moves one row. An annual refresh of a document nobody consults is the thing this exercise exists to avoid.

See the benchmarks >