Will AI take my job? Think in tasks, not roles

Jobs are bundles, not units

Most talk about AI and employment treats a job as a single thing that survives or does not. That framing is useless for a practitioner, because no technology has ever acted on a job title. Technologies act on tasks. A job is a bundle of dozens of tasks held together by an organisation chart, a salary band and a habit of who does what.

Take a bookkeeper. Inside the role sit tasks as different as keying invoices, reconciling accounts, chasing a client for a missing receipt, spotting that a supplier has quietly changed their payment terms, explaining to a nervous owner why cash is tight this quarter, and deciding whether an unusual transaction is a mistake or a problem. Some are pattern-heavy and repetitive; others require trust, context and accountability. Lumping them together and asking whether "the bookkeeper" is automatable tells you nothing.

The bundle also shifts. Spreadsheets did not eliminate accountants; they eliminated the arithmetic task within the accountant's bundle and expanded the analysis and advisory tasks. The role survived because the bundle re-formed around what remained scarce. Expect this pattern, and decompose first.

Exposure is not replacement

Once a job is decomposed, each task can be rated for exposure: how much of it could, in principle, be done or assisted by a current model. A task is highly exposed if its inputs and outputs are mostly text, images or structured data, if the quality of an output can be judged without deep access to the world, and if the task recurs often enough that patterns exist to learn from. Drafting a first-pass summary is highly exposed. Calming a furious customer in person is not.

Most confusion begins here. High exposure does not mean the task disappears. Between exposure and replacement stand at least four gates. First, reliability: a model that does a task well nine times in ten is a superb assistant and a hopeless replacement if the tenth failure is costly. Second, accountability: someone must sign off, carry the liability and answer for the outcome, and that person needs enough competence to check the work. Third, integration: the task has to connect to systems, permissions, data and procedures that often do not exist yet. Fourth, economics: automating a task is only worth doing if the saving exceeds the cost of building, monitoring and fixing the automation.

So the honest statement about a highly exposed task is usually not "this will be replaced" but "the cost of doing this will fall, the volume may rise, and the human's contribution will shift towards judging, correcting and deciding when to use the output". The two forecasts differ materially, and so do their implications for what you should learn.

Complementarity: when your neighbour gets cheaper, you get dearer

The most under-appreciated idea in this whole area is complementarity. When one task in a bundle becomes dramatically cheaper, the tasks that sit next to it in the workflow often become more valuable, not less, because they are now the bottleneck.

Consider a marketing team where producing a draft campaign brief used to take a day. If drafting becomes nearly free, the team can consider ten briefs instead of one. Now the scarce skill is choosing between them: knowing the customer well enough to spot the brief that will actually land, seeing that two of the ten quietly contradict the brand position, noticing that one relies on a claim the legal team will never approve. Those tasks were always in the bundle, rationed by how slowly drafting happened; remove the ration and their value is exposed.

The same logic applies to verification. A model that produces a fluent analysis in seconds creates demand for someone who can tell a correct analysis from a plausible one. The person who can verify has become more important precisely because fluent output is abundant.

Complementarity is not automatic. It requires that the person holding the adjacent tasks is allowed and able to move into them. An analyst who is only ever permitted to pull data will not benefit from interpretation becoming more valuable, which is why organisational design matters as much as the technology.

Running a task audit on your own role

Everything above becomes practical through a simple exercise you can do this week. Write down the fifteen to twenty-five tasks that actually fill your working month. Be concrete: "answering supplier queries about delivery windows", not "communication". Include the unglamorous ones, because they often carry the most exposure.

For each task, record its exposure (is the work mostly text, images or structured data, and can a competent person judge the output quickly?), its criticality (what happens if it is done wrong?), and whether you own the judgement around it or merely execute it.

High-exposure, low-criticality tasks are where you should be experimenting with assistance now, because the downside of a mistake is small and the time saved is real. High-exposure, high-criticality tasks are where you should learn to use models as drafters and checkers while keeping tight verification, because these are the tasks where your verification skill becomes your value. Low-exposure tasks that depend on relationships, physical presence or accountability are your anchor; invest in becoming visibly excellent at them. And any task where you execute but do not own the judgement is a signal to start moving up the bundle before someone else redraws it.