The Jobs That Get Created Are Hard to Name in Advance

"New jobs will be created" is the standard response to automation concerns, and it's usually stated without examples — which makes it sound like faith rather than reasoning. There's a structural reason the examples are hard to give, and understanding it makes the claim more credible while also limiting what you can do with it.

Why they're unnameable in advance

New roles emerge from problems created by the new capability, and those problems aren't visible until deployment is widespread enough to produce them.

Nobody could have specified "site reliability engineer" before large distributed systems existed to be unreliable. The role came from a problem that didn't exist yet — and the problem was created by the solution to a previous problem.

The same structure applies here. Roles will emerge around problems that agent deployment creates, and most of those problems haven't happened at scale yet.

What's already visible

Some are emerging now, which is the best evidence available:

Evaluation work. Building and maintaining the case sets, oracles, and measurement that determine whether a system is working. Already a distinct activity in serious deployments and already hard to staff.

Context and knowledge curation. Deciding what organizational context gets captured, in what form, so it's usable. Adjacent to technical writing, data curation, and knowledge management — and different from all three.

Agent operations. Watching deployed agents, diagnosing degradation, managing cost and quality over time. Analogous to SRE, applied to systems that fail quietly.

Verification and review at volume. Not a new job exactly, but a much larger share of existing ones, and increasingly a specialization.

Specification work. Turning intent into precise requirements. Partly product management, partly business analysis, and neither exactly.

⚠️ Note that all five are about checking, curating, and directing rather than producing. That's the pattern in what's emerging, and it's consistent with what stays scarce.

The honest limitations of the argument

"New jobs will appear" doesn't mean the same people get them. A displaced worker and a created role can be in different places, requiring different skills, on different timelines. Aggregate employment holding is compatible with substantial individual harm, and the transition costs are borne unevenly.

It doesn't mean equal numbers. Previous transitions created more jobs than they destroyed; that's a pattern, not a guarantee, and the honest position is that nobody knows.

It doesn't mean equal quality. Created roles can be better or worse than what they replaced. Both have happened historically.

It can't be planned for specifically. Since the roles aren't nameable, "retrain for the new jobs" isn't actionable — the new jobs aren't listed anywhere yet.

✅ What is actionable

If specific roles can't be named, position on the properties that the emerging ones share:

Judgment over production. Everything visible so far is about deciding, checking, and curating.

Domain plus technical. The emerging roles sit between the technology and a domain. Pure technical or pure domain fits less well than the combination.

Comfort with measurement. Evaluation, monitoring, and quality work all require being comfortable with numbers about behavior.

Tolerance for undefined work. New roles start undefined. People who can operate without a job description are the ones who occupy them first, and that's a disposition more than a skill.

💡 The most reliable signal

Watch what's currently painful in organizations using agents heavily. Today's persistent annoyance is tomorrow's job title.

The things people complain about now — nobody knows if the agent is still working well, nobody owns the eval set, the context is scattered, review is a bottleneck, cost is untracked — are exactly where roles form. That's a more useful place to look than any forecast, and it's observable from where you are.

The takeaway

New roles emerge from problems the new capability creates, which is why they can't be named until deployment produces them. What's visible so far — evaluation, context curation, agent operations, verification, specification — all sits on the judgment side. Position on those shared properties rather than on a predicted title, and watch what's currently painful in agent-heavy teams, because that's where the next job descriptions are forming.