Which parts of this work are most exposed

A test you can apply yourself

Forget predictions. Ask three questions about any task:

1. 1Is it well specified? Could you write down what a correct result looks like before starting?
2. 2Are there many examples of it being done? Millions of instances of this exact task, publicly available.
3. 3Can correctness be checked in seconds? By a test, a compiler, a rule, a quick glance.

Three yeses means heavily exposed. Three noes means durable for now. Most real work is a mixture, which is why jobs change shape rather than vanishing.

The most exposed work is the newest work

This is the part people find surprising. Much of the work created by the first wave of AI is what the second wave absorbs: writing large numbers of prompt variations, simple labelling and annotation, routine data cleaning scripts, first-draft dashboards, boilerplate glue code, straightforward report queries.

Also exposed: the traditional bottom rung. "Write the SQL for this report." "Turn this spreadsheet into a chart." "Summarise these tickets." Well specified, abundantly exampled, quickly checked.

That is the honest problem for a beginner. The exposure lands hardest exactly where people used to enter.

What holds up

Accountability. Someone has to be answerable when the number is wrong, the model refuses a legitimate customer, or the pipeline reports a loss that did not happen. Organisations do not assign that to a tool. This is why evaluation work is more durable than prompt work: deciding what "good enough" means is a responsibility, not a task.

Undocumented context. Why the Mexico numbers are always late. Which of the three customer tables anyone actually trusts. Why finance recalculates revenue differently in Q4. This lives in people's heads and in three-year-old chat threads, and it is most of what makes a competent employee competent.

Work that touches the real organisation. Getting access approved. Persuading a team to change how they record something. Running an incident at 2am. Negotiating what data may lawfully be used.

Systems work under constraints. Latency, cost, permissions, failure modes, data that arrives late or twice. Specifying it correctly is nearly as hard as building it.

Say the honest thing about timing

Nobody knows the timeline. People confidently claiming mass unemployment within two years and people confidently claiming nothing will change are both guessing, and both are usually selling something. What can be observed is direction: tasks meeting the three-yes test are getting cheaper quickly.

The realistic effect is not that a job disappears but that one person does what four or five did, which reduces hiring volume at the bottom before it touches anyone senior.

What to do about it

Do not try to out-type the tools. Move toward the parts they cannot own.

• Become the person who can tell whether an output is *correct*, not just whether it looks plausible. That skill needs domain knowledge and a habit of checking, and it is the scarcest thing on most teams.
• Take jobs where you sit near the mess and near the decision, even if the title is modest.
• Learn one domain properly — health, logistics, agriculture, lending, education. Context is the moat.
• Use the tools heavily. Being slower than a colleague who uses them well is a real risk, and a nearer one than the abstract fear.

And stay usefully sceptical. Anyone certain about this field in either direction is telling you about their business model, not the future.