AI Isn't Taking Jobs. It's Sorting Them.

Two headlines ran this month that seem to contradict each other. A Census Bureau working paper linked college majors to actual employment records and found the most AI-exposed graduates, computer science and programming leading the list, facing delayed employment, real earnings declines, and a shift toward lower-paying work after ChatGPT's release. Around the same time, Nvidia's Jensen Huang sat down with the New York Times' Ezra Klein and rejected the idea that AI eliminates jobs, arguing instead that it usually changes a job's tasks while leaving its purpose intact. He drew the line himself: a job's goal and a job's tasks aren't the same thing, and conflating them is where most predictions about AI and work go wrong.

Both men are citing real evidence. Neither is telling the whole story, because "is AI taking jobs" isn't a yes-or-no question. It's a sorting question, and the sort turns out to be predictable in advance.

Take radiology, which Huang used as his own example. A decade ago, Geoffrey Hinton told the field to stop training radiologists, certain AI would replace them within five years. The opposite happened. Radiologist salaries have climbed past half a million dollars, postings sit open for months, and the country faces a shortage running into the tens of thousands by 2033. AI got very good at reading a scan. It never touched the rest of the job: the procedures, the judgment on an atypical case, the conversation with a frightened patient, the name attached to a diagnosis that carries legal weight if it's wrong. Reading the scan was a task inside radiology. It was never the whole vocation.

Now take junior software developers, the group the Census data shows getting hit hardest. The task that used to belong to a first-year engineer, boilerplate code, routine bug fixes, a first-pass draft, was never separate from the job the way reading a scan is separate from being a radiologist. For a junior developer, the task and the job were close to the same thing. AI didn't automate a slice of the role. It automated most of what the role was.

That's the actual diagnostic, and it holds up past these two cases. A job compresses when its tasks overlap almost completely with what a model can now do, when the people who could do it are in easy supply, when demand for the output isn't growing fast enough to absorb the efficiency gain, and when nobody has to be legally or professionally accountable for the result. A job expands, or at minimum holds, when a real gap remains between the task and the job's purpose, when supply is constrained, when demand keeps outpacing what AI can satisfy, and when someone has to be the named, liable party standing behind the outcome.

A third pattern shows what happens in between, and it matters because it's the one most white-collar work actually resembles. Field studies of customer service agents, including a large one inside Alibaba, found AI narrowing the gap between low and high performers rather than eliminating either group. The tool distributed what the best agents already knew, and turnover fell along with it. That's neither compression nor pure expansion. It's leveling, and it shows up where task-goal overlap is high but demand isn't fixed and nobody's liable for a wrong customer service answer the way someone's liable for a wrong diagnosis. The same variables that explain radiology and junior developers predict this third outcome correctly, which is a better test of a framework than two cases that happen to fit it.

Worth saying plainly what would break this. A high-liability, supply-constrained role getting automated away anyway would be the disconfirming case, and it hasn't shown up yet. That's a claim worth watching, not a guarantee.

Huang's own example is worth running back through his framework, because it doesn't survive the check. He named phone-based customer support as a job where goal and task overlap enough to be automated outright. But that's the leveling case, not the elimination case: the field data shows productivity gains and lower attrition, not replacement, because demand for support isn't fixed and even a scripted job carries enough judgment, when to break script, when to escalate, to keep goal and task from fully collapsing into each other. Even the person who articulated this framework doesn't always apply it to his own examples. That's not a knock on the framework. It's what checking a claim looks like instead of just citing it.

The part of this that matters most for a university sits inside the junior-developer case, and it's bigger than software. The tasks AI eats first, boilerplate code, first-draft writing, routine data work, were historically the tasks a junior person did while a senior person supervised them into competence. That supervised repetition was the training mechanism, not busywork on the way to a real job. It was how someone became good enough to do the real job. If AI absorbs the repetition, the apprenticeship doesn't get more efficient. It disappears, and nothing has replaced it yet. That reframes "how do we prepare students" from a curriculum question into an infrastructure question: the university has to build formation on purpose, in the room, because the informal version that used to happen on someone's first job is closing.

Huang is betting a new kind of engineer fills that gap, students training alongside agentic tools now who graduate around 2028 into roles built on verifying and directing what the agents produce rather than writing code by hand. A live version of that bet is already running, two years ahead of his own timeline. A junior at a regional university spent this past summer building agentic workflows and automation processes for a local employer, work nobody on staff had the bandwidth to build otherwise, and the company kept them on through the school year.

There's a structural version of this same shift worth stating on its own terms, separate from anything attributed to Huang directly. Agentic tools and low-code interfaces collapse a translation step that used to define technical work: a domain expert explaining a problem to a separate technical person, who then had to relearn the domain well enough to build the right thing. The intern's workflow didn't route through a company IT department. It came directly from someone who already held the context, who knew which exceptions mattered and what "trustworthy" meant for that specific process. Building starts moving down into every function this way, not because everyone becomes a trained engineer, but because the tool removes the need for a separate technical intermediary between a problem and its fix. What doesn't move down is the layer above it: who verifies the thing built this way is safe to run against real data, and who's willing to be the accountable party if it's wrong. Building democratizes. Accountability doesn't. That's the sharper version of the verification-engineer bet, and it's one the intern example already supports on its own.

There's a wrinkle underneath all of it, specific to a labor-short region. National data on AI-exposed graduates measures compression, more people competing for fewer entry slots. In a county short on workers generally, this student may not be winning a slot someone else lost. They may be filling a rung that was sitting empty, because nobody available had the skill to build it at all. That's a different story than the Census data tells, and neither Huang's optimism nor the Census's caution is built to say anything about it.

None of this is reassurance, and it isn't supposed to be. Students don't need to be told it'll be fine. They need the diagnostic: which jobs compress, which expand, which get leveled, and which of the variables they can actually go build inside themselves before they pick a major.

I want to evaluate a career path or job role against AI exposure, using
a structural framework instead of general optimism or pessimism.

The role I want evaluated: [describe the job, industry, or major]

Walk through it against these four variables and give me a clear read
on each:

1. Task-versus-job overlap: does the day-to-day task list make up
   nearly all of what the role delivers, or is there a meaningful gap
   between the tasks and the role's actual purpose (judgment,
   relationship, accountability, physical presence)?

2. Supply elasticity: is entry into this role capped by licensing,
   credentialing, or a fixed training pipeline, or can supply expand
   quickly if demand or wages rise?

3. Demand elasticity: if AI makes the core task faster or cheaper,
   does total demand for the output grow to absorb the gain, or is
   demand roughly fixed regardless of how fast the task can be done?

4. Liability and accountability: does someone have to be the named,
   legally or professionally responsible party for the outcome, in a
   way that can't be assigned to a system?

Based on the answers, tell me plainly whether this role looks like the
compressing pattern, the expanding pattern, or the leveling pattern
(narrowing the gap between weak and strong performers rather than
eliminating the role). Then tell me what would have to change to move
it, and what specific skill or credential would do the most to shift
it toward the expanding side.