I run a handful of personal websites. A book catalog, a blog, a few project sites. Not long ago, keeping those running the way I wanted meant one of two things. Either I did everything myself, badly and slowly, or I assembled a small team: a web developer for the layout and build, a copy editor for the writing, a graphic designer for the covers and banners. Three specialists, three sets of handoffs, and a lot of waiting on other people for a site that earns nothing.
Today I do all three jobs myself with AI assisting on each one. The layout gets scaffolded by a model, the copy gets a first editing pass from a model, the graphics get generated and adjusted with a model. None of that works unless I know enough about web development, editing, and design to describe what I want and to recognize when the output is wrong. The specialists did not get replaced by software. Their procedural work got absorbed into a wider version of my job, and what the job now requires of me is judgment across three areas instead of skill in one.
That is the real subject of this article. The conversation about artificial intelligence and work keeps asking one question: how many jobs will AI eliminate? I think that is the wrong question, and the wrong question is producing wrong answers. My argument is that we are entering a period I call the great despecialization. For roughly two centuries, productivity gains came from splitting work into narrower roles. AI reverses the incentive. When one person with the right tools can carry a piece of work across boundaries that used to require handoffs, the economics favor breadth over depth. Jobs do not vanish. They widen. And if my websites ever grow to the point where I need a team again, that team will not be specialists. It will be generalists, each owning additional end-to-end workflows toward the same goal.
I work at Dremio and spend a lot of time around data engineers, so data teams show up in the examples below. The pattern applies well beyond them.
The Substitution Story Gets the Unit of Analysis Wrong
Most AI job predictions start from a list of occupations and score each one for how automatable it looks. The method feels rigorous. It produces big scary numbers. It also measures the wrong thing.
A job is not a single activity. A job is a bundle of tasks that some organization decided to hand to one person. A data engineer writes ingestion code, debugs failed runs, sits in requirements meetings, negotiates with a source system owner, documents schemas, answers Slack questions from analysts, and estimates timelines. AI is very good at two or three of those tasks and mediocre at the rest. Scoring the job as a whole hides that variation.
The newer research has started to catch this. The 2026 PwC Global AI Jobs Barometer looked at more than one billion job advertisements across 27 countries and found a two-track market. Roles where AI automates routine tasks so that human judgment gets more emphasis are growing faster than roles that AI has made easy enough for non-experts to perform. Read that carefully. The roles growing fastest are the ones where AI removed the routine parts and left a human holding a wider set of responsibilities.
The layoff data tells a similar story. Of the roughly 1.2 million US layoffs announced in 2025, only about 4.5 percent explicitly cited AI according to Challenger, Gray and Christmas. S&P Global's purchasing managers survey put the global net employment effect of AI adoption at negative 5 points over the past year, a modest number, with process efficiency and productivity cited as the goal far more often than headcount reduction. These are real effects, but they are not the wholesale deletion the substitution story predicts.
The place where displacement is clearest is the entry level. Stanford's Digital Economy Lab measured about a 13 percent relative employment decline for 22 to 25 year olds in the most AI-exposed occupations. I will come back to that number, because it is the strongest evidence against my thesis and it deserves a direct answer. For now the point is simpler. When you measure tasks instead of occupations, the picture is not "jobs disappear." The picture is "jobs get rebundled."
What Specialization Was Actually For
To understand why AI rebundles work, you have to understand why we unbundled it in the first place.
Adam Smith opened The Wealth of Nations with a pin factory. One worker doing every step of pin-making produced maybe twenty pins a day. Ten workers, each doing one step, produced forty-eight thousand. The gain came from three sources. Each worker got better at a narrow task through repetition. Nobody lost time switching between tools and tasks. And narrow tasks were easier to turn into machines.
Every knowledge-work org chart from the last fifty years is a pin factory with laptops. We split "get data to the people who need it" into source system owner, ingestion engineer, warehouse engineer, analytics engineer, BI developer, data analyst, and data steward. Each role exists because the skill it requires takes years to build, because switching between those skills is expensive, and because narrow roles are easier to hire for and measure.
Specialization has a cost that the pin factory story leaves out. Ronald Coase won a Nobel Prize partly for pointing out that coordination is not free. Every boundary between two specialists is a handoff. Every handoff needs a ticket, a meeting, a shared definition of done, a translation between two vocabularies. The waiting I described between a developer, an editor, and a designer is pure coordination cost. No pins get made while three people wait on each other.
Organizations tolerate coordination cost because the alternative was worse. One person cannot hold enough expertise to do all seven of those data jobs well. The human brain and the human calendar have limits. So we accepted the handoffs, hired project managers to grease them, and built tooling like Jira to track them. The whole apparatus of the modern knowledge-work company is a machine for managing the cost of specialization.
That is the key insight for what comes next. Specialization was never the goal. It was a workaround for the fact that expertise is expensive to acquire and slow to switch between. Change those two constraints and the workaround stops paying for itself.
Why AI Attacks the Reason for Specialization, Not the Specialist
Here is what a large language model actually does when it helps a working professional. It lowers the cost of acquiring just enough expertise to do a task, and it lowers the cost of switching between tasks. Those are exactly the two constraints that specialization existed to route around.
Consider the switching cost first. A data engineer who needs to write a Terraform module for a new bucket used to face a choice. Spend two hours relearning HCL syntax and the provider's quirks, or file a ticket for the platform team and wait three days. In 2026 that engineer describes the bucket, gets a working module in under a minute, reads it, adjusts the lifecycle policy, and moves on. The switching cost dropped from hours to minutes. The ticket, and the handoff it represents, no longer makes sense.
Now consider the acquisition cost. Expertise has two layers. There is the layer of knowing how to do a thing, which is mostly recall of syntax, procedures, and conventions. And there is the layer of knowing what to do and why, which is judgment built from seeing things go wrong. AI has commoditized the first layer almost completely. It has barely touched the second. A model will write you a correct window function. It will not tell you that your business partner's definition of "active customer" has changed twice this year and the dashboard is quietly wrong.
This split matters because it tells you which half of every specialist role gets absorbed. The recall half. The procedural half. The half that took the longest to learn and contributed the least judgment. What remains is the judgment half, and judgment is portable across domains in a way that syntax never was.
A person with good judgment about data quality, plus an AI that handles the procedural work of five adjacent roles, can now cover ground that used to need five people. Not because the person got five times smarter, but because the five roles were mostly procedural work stacked on top of a thin layer of judgment each. Collapse the procedural work and the judgment layers stack up into one job.
That is the mechanism. AI is not competing with the specialist for the specialist's job. AI is dissolving the boundaries that made the specialist's job a separate job at all.
The Great Despecialization, Defined
Let me state the thesis precisely so it can be argued with.
The great despecialization is the shift in the economics of knowledge work from rewarding depth in one task to rewarding breadth across many tasks, driven by AI reducing the cost of switching between tasks and the cost of acquiring procedural competence in a new one. It changes the shape of jobs before it changes the count of jobs.
Three predictions follow from that definition, and each one is testable.
First, job descriptions get wider. The average posting asks for more distinct skill areas than it did five years ago, and the premium for "AI fluency" shows up as a demand for people who can apply AI across those areas rather than in one. Stanford's AI Index and Lightcast data already show AI skills appearing in about 2.5 percent of all US job postings, up 55 percent year over year, and mentions of agentic AI skills grew more than 280 percent in a single year. Those mentions are not asking for machine learning researchers. They are asking for accountants and marketers and engineers who can direct AI tools.
Second, team sizes shrink while team scope grows. The eleven-person data team becomes a four-person data team that owns more of the value chain, not less. Headcount per unit of output drops. Total output rises. Whether total employment drops depends on whether demand for output grows, which is the same question every previous productivity wave faced.
Third, the skills premium moves from "can you do X" to "can you tell whether X was done correctly." Review, verification, and judgment become the scarce inputs. This flips the traditional career ladder, where you spent years doing the thing before you were trusted to review the thing. I will get to why that flip is painful.
If you want a historical analogy, do not reach for the Luddites. Reach for the spreadsheet. VisiCalc and then Lotus 1-2-3 did not eliminate accountants. They eliminated the bookkeeping clerks who did arithmetic, and they turned every manager into a person who does financial modeling as one task among many. The number of people doing financial analysis went up. The number of people whose whole job was financial arithmetic went to zero. The job of "manager" got wider. That is despecialization, and it happened forty years ago.
The bank teller is a second example worth keeping in mind. Automated teller machines arrived in the 1970s and everyone expected teller employment to collapse. Instead the number of tellers in the United States rose for three decades, because cheaper branches meant more branches, and the teller's job shifted from counting cash to selling accounts and handling exceptions. The procedural core of the role was automated away and the role got wider. It took decades for teller headcount to finally decline, and when it did, the cause was online banking removing the branch itself rather than the machine inside it. Despecialization came first. Elimination, where it happened at all, came a generation later through a different mechanism.
What It Looks Like Inside a Data Team
Abstract arguments about labor economics are easy to nod along with and hard to act on. So let me walk through a hypothetical data team, since that is the kind of team I talk to most often.
A typical mid-sized data organization in 2022 looked something like this. Two platform engineers ran the Kubernetes clusters and the object storage. Three data engineers wrote Spark or Airflow pipelines. Two analytics engineers built dbt models. One database administrator (DBA) tuned the warehouse. Three analysts wrote SQL and built dashboards. One data steward maintained the catalog and lineage. That is twelve people, six distinct specialties, and at least five handoff boundaries between raw data and a chart a VP looks at.
Now trace a single request through that org. Marketing wants churn by acquisition channel. The analyst files a ticket because the channel field is not in the model. The analytics engineer discovers the field is not in the warehouse either. The data engineer finds the source system exposes it but the ingestion job drops it. The DBA warns the new column will blow up a partition scheme. Three weeks and four tickets later, marketing gets a chart. Every person involved did their job correctly. The system produced a three-week latency out of correct individual behavior.
Here is the same request in a despecialized team of five, each running AI agents against the platform. The analyst, who is now something closer to a "data generalist," opens an agent session connected to the catalog through an MCP (Model Context Protocol) server. MCP is an open standard that lets an AI agent discover and call tools, so the agent can inspect table metadata, run queries, and read lineage without a human copying things between windows. The agent confirms the field exists in the source, drafts the ingestion change, proposes a dbt model update, runs the query against a branch, and flags the partition concern. The generalist reviews each step, rejects the partition change in favor of a different approach, and merges. Two days, one person, zero tickets.
This is the workflow that tools like Dremio's MCP Server against an Open Catalog powered by Apache Polaris are built for, and other stacks support the same pattern. The vendor matters less than the shape: a catalog with rich metadata, an agent that can read it, and a human whose job is to direct and verify rather than to execute each step by hand.
Notice what did not happen. Nobody got fired in that story. The twelve-person team did not become a five-person team through layoffs. It became a five-person team because the next three people who left were not backfilled, and the work absorbed into wider roles. That is how despecialization actually arrives in most organizations: through attrition and scope creep, not pink slips.
Notice also what the five remaining people need to know. Each of them touches ingestion, modeling, query tuning, and governance in a single week. None of them are the deepest expert in any of those. All of them need enough judgment in each to catch an agent's mistakes. The DBA's knowledge did not disappear. It got spread thin across five people and one model.
The table below shows the shift in what each role spends time on. The percentages are illustrative of the pattern, not a survey result.
| Activity | 2022 specialist team | 2026 despecialized team |
|---|---|---|
| Writing code, SQL, and config by hand | 45% | 15% |
| Waiting on or coordinating handoffs | 25% | 5% |
| Reviewing and verifying work (own or AI's) | 10% | 35% |
| Talking to business stakeholders | 10% | 25% |
| Learning adjacent skills | 5% | 15% |
| Meetings about who owns what | 5% | 5% |
The bottom row is a joke, but only partly. Ownership fights do not go away. They change from "whose ticket is this" to "who is accountable when the agent gets it wrong."
It Is Not Only Data Teams
Data teams are the example I reach for because of where I work, but the same collapse is happening wherever a value stream got sliced into specialist roles.
My own websites are the smallest possible case. Developer, editor, designer: three roles that existed because each skill took years to build. AI compressed the procedural half of all three into tools I direct, and the judgment half of all three into one person. If the sites ever needed a second person, that person is not a specialist designer. That person is another generalist who owns a new end-to-end workflow, say a newsletter or a course pipeline, from draft to publish, and who can step into mine when needed.
Take a marketing organization. In 2022 a campaign passed through a strategist, a copywriter, a designer, a web developer who built the landing page, an email specialist who set up the sequence, and an analyst who reported on it. Six roles, five handoffs, a two-week cycle for a single campaign. In 2026 a "growth marketer" drafts copy with a model, generates and adjusts layout with a design tool, ships the landing page from a template an agent modifies, configures the email flow, and reads the results out of an agent connected to the analytics warehouse. The strategist and the analyst are often the same person. The cycle is two days. The designer still exists, but as one senior person reviewing output across a dozen campaigns rather than producing one at a time.
Take a small software company. The old shape had frontend engineers, backend engineers, a DevOps engineer, a QA engineer, and a technical writer. The new shape has "product engineers" who own a feature from database migration to documentation, with agents writing the tests and the docs and a senior engineer reviewing the architecture. The QA role did not vanish because testing stopped mattering. It vanished because testing became a task every engineer directs an agent to do, and the judgment about what to test moved into the engineer's head.
Take finance. A financial planning and analysis (FP&A) team used to have people who built models, people who pulled data, people who made decks, and people who presented. The person who presents now builds the model with an agent, pulls the data through a connector, and generates the deck. The three procedural roles compressed into one judgment role.
The pattern is identical in each case. Find the value stream. Count the handoffs. Each handoff existed because switching skills was expensive. Remove that expense and the handoffs collapse into the person closest to the outcome. That person's job gets wider, the people whose whole role was a handoff get absorbed or not backfilled, and the total number of people producing the outcome drops while the outcome's cycle time drops faster.
What changes across industries is how thick the judgment layer is at each step. Marketing has a thin one at the procedural level and a thick one at the strategic level, so it despecializes fast. Finance has regulatory sign-off at the end, so the last step stays narrow. Software has a deep specialist layer in infrastructure and security that resists. The direction is the same everywhere. The speed and the stopping point differ.
A Task Inventory You Can Run on Your Own Role
The most useful exercise I know for thinking about this is a task inventory. List everything you do in a typical month. For each task, estimate two things: how much of it is procedural (recall, syntax, following a known sequence) versus judgment (deciding what should happen and whether it did), and how much of it exists only because of a handoff to or from another specialist.
Below is a small Python script that does the arithmetic. It takes a list of tasks with rough weights and produces two numbers: how much of your current job is exposed to procedural automation, and how much is coordination overhead that disappears if the boundary around you dissolves.
from dataclasses import dataclass
@dataclass
class Task:
name: str
hours_per_month: float
procedural_share: float # 0.0 to 1.0, fraction that is recall/syntax
handoff_driven: bool # exists mainly because of a role boundary
tasks = [
Task("Write ingestion jobs", 30, 0.70, False),
Task("Debug failed pipeline runs", 20, 0.40, False),
Task("Answer analyst schema questions", 15, 0.30, True),
Task("Write tickets for platform team", 10, 0.80, True),
Task("Requirements meetings", 12, 0.10, False),
Task("Document schemas in catalog", 8, 0.60, True),
Task("Estimate timelines", 5, 0.20, False),
]
total = sum(t.hours_per_month for t in tasks)
procedural = sum(t.hours_per_month * t.procedural_share for t in tasks)
handoff = sum(t.hours_per_month for t in tasks if t.handoff_driven)
judgment = total - procedural
print(f"Total hours: {total:.0f}")
print(f"Procedural (AI-absorbable): {procedural:.0f} ({procedural/total:.0%})")
print(f"Judgment (stays human): {judgment:.0f} ({judgment/total:.0%})")
print(f"Handoff overhead: {handoff:.0f} ({handoff/total:.0%})")
print(f"Hours freed for wider scope: {procedural + handoff * 0.5:.0f}")
Run it with the sample numbers and you get 100 hours total, 49 hours procedural, 51 hours judgment, and 33 hours of handoff-driven work. The last line estimates hours freed for wider scope by assuming AI absorbs the procedural work and half of the handoff overhead evaporates once you can do the adjacent task yourself.
Walk through what each part means. The procedural_share field is the honest question: when I do this task, how much of the time am I remembering how versus deciding what? Writing ingestion jobs is mostly how. Requirements meetings are almost entirely what. The handoff_driven flag asks whether the task exists because someone else owns the next step. Writing tickets for the platform team is pure handoff. If you owned the platform change, the ticket disappears.
The output is not a prediction of your job's survival. It is a map of which hours are about to become available and which hours are the reason your employer still needs a human. The engineer in the sample has roughly half their month in judgment work. That half is the seed of the wider role. The other half is what gets refilled with adjacent tasks.
Try running it against your own month. If procedural comes out above 70 percent, the honest read is that your current role is mostly a bundle of recall tasks and the bundle is going to be repackaged. If judgment comes out above 60 percent, you are already doing generalist work and the shift is going to feel like getting more tools rather than losing ground.
What Breaks: The Failure Modes of the Generalist Shift
I am making an optimistic case, so I owe you the parts that go wrong. Despecialization has real failure modes, and some of them are already visible.
The apprenticeship ladder collapses first
This is the strongest objection and the one I take most seriously. That Stanford figure, a 13 percent relative employment decline for 22 to 25 year olds in AI-exposed occupations, is the sound of the bottom rung breaking. The traditional path into expertise ran through years of procedural work. You wrote the boring SQL for three years, and while writing it you absorbed the judgment that let you review someone else's SQL in year four. AI takes the boring SQL. So where does the judgment come from?
There is no clean answer yet. The National Association of Colleges and Employers reported in spring 2026 that just over a quarter of employers say AI has reduced the need for tasks entry-level workers performed, while more than half are in active discussions about it. The generalist role is a great destination and a terrible starting point. A 23-year-old asked to direct agents across ingestion, modeling, and governance has never seen any of those go wrong and cannot tell a plausible agent output from a correct one.
Organizations that want a pipeline of future generalists have to build apprenticeship deliberately, since the work no longer provides it for free. That means pairing juniors with seniors on review work, not just execution work. It means giving juniors ownership of small end-to-end slices instead of narrow tasks. It costs money in the short term and most companies are not doing it.
The jagged frontier eats the unwary generalist
Ethan Mollick at Wharton coined the phrase "jagged frontier" for the fact that AI capability is uneven in ways that do not match human intuition. A model that writes flawless Python fails at a date calculation a child gets right. A generalist working across five domains is, by definition, not deep enough in any one of them to always know where the frontier sits.
The failure looks like this. The generalist asks the agent to add a column to an Iceberg table and update downstream models. The agent does it and reports success. What the agent did not know, and the generalist did not know to check, was that the table used a partition transform on a column that a downstream engine reads in a version-specific way. The change was syntactically correct and operationally wrong. A specialist DBA catches it on sight. A generalist finds out in production.
The mitigation is not "become a specialist in everything." It is building verification habits: test in a branch before merging to main, use catalogs and formats that make changes reversible, and treat every agent output as a pull request from a confident junior rather than a finished product. Apache Iceberg's snapshot model is a real asset here, because a bad table change is a rollback rather than a restore-from-backup.
Depth erodes when nobody is paid to maintain it
If every team despecializes, who keeps the deep knowledge alive? Somebody has to understand Parquet encoding at the byte level, or query planner internals, or the edge cases of a specific regulatory regime. Generalists consume that knowledge through AI tools. They do not produce it.
I think the honest answer is that deep specialists do not go away. They get rarer and more concentrated. They cluster in the companies that build the tools, in open source projects, and in a smaller number of very senior roles at large organizations. The specialist-to-generalist ratio in the average company drops from something like one-in-two to one-in-ten. That is a real shift in what a specialist career looks like, and it means fewer specialist jobs at typical companies even if it means more specialist jobs in aggregate at the platform layer.
Accountability does not despecialize
When an agent-directed generalist approves a change that corrupts three months of financial data, whose fault is it? The answer today is the generalist's, and that is a heavier load than the old specialist carried, because the specialist only owned one step. Wider scope means wider blast radius. Organizations that widen roles without widening the review process, the rollback tooling, and the psychological safety to say "I am not sure about this one" are setting up their generalists to fail loudly.
Coordination cost does not vanish, it moves
The pipeline meeting with eleven people goes away. In its place comes a new coordination problem: five generalists each running agents against the same catalog. Two of them change the same model in the same afternoon. The agent-to-agent conflicts are a new class of problem with immature tooling. Catalogs with branching, like the Iceberg REST catalog implementations that support it, help. So do conventions borrowed from software engineering: feature branches, required reviews, protected main. Most data teams have not adopted those conventions yet. They are about to be forced to.
Where Specialists Still Win
I do not want to overstate the case. There are places where depth beats breadth and AI does not change that.
Licensed and legally accountable roles keep their shape longest. An auditor signs an opinion. A physician signs a chart. A structural engineer stamps a drawing. The signature carries legal weight that a generalist directing an agent cannot substitute for, and regulators are not going to change that quickly. These roles will use AI heavily and stay narrow.
Roles where the frontier is the job stay specialized too. If your work is pushing the boundary of what is known in a field, whether that is query optimizer research or protein folding, AI is a tool for a specialist, not a replacement for one. The model knows what has been written. The specialist knows what has not been written yet.
Physical work is the obvious third case. Despecialization is a knowledge-work phenomenon. The electrician and the surgeon are not being asked to also do the plumbing and the anesthesia because a chatbot got good at reading manuals.
The fourth case is subtler: roles where the cost of being wrong is catastrophic and detection is slow. Security engineering is a good example. A generalist who is 90 percent as good as a specialist across five domains is a wonderful thing in most contexts. In security, the 10 percent gap is the breach. Some functions will resist despecialization purely because the organization cannot afford the tail risk.
The pattern across all four is the same. Specialization survives where the judgment layer is thick, the accountability is personal, or the error cost is extreme. It dissolves where the procedural layer was thick and the error cost is a rollback.
How to Prepare, as a Person and as a Manager
Prediction is cheap. What should you actually do?
If you are an individual contributor, stop optimizing for depth in your current role and start optimizing for judgment across adjacent ones. Concretely, that means spending time on the tasks upstream and downstream of you. If you are an analytics engineer, learn enough about ingestion to review an agent's ingestion change and enough about BI to review the dashboard that consumes your model. You are not trying to become the best at either. You are trying to be able to say "that looks wrong" with reasons.
Build a verification practice. Write down what "correct" looks like before you ask an agent to do something. Test against a branch. Keep a personal list of the mistakes agents have made in your domain, because that list is the beginning of the judgment that used to take years of procedural work to acquire. The generalists who thrive are the ones with the best error catalogs, not the best prompts.
Learn the open standards rather than the vendor interfaces. Iceberg, Parquet, Arrow, MCP, and SQL itself are the shared vocabulary that lets one person move across tools. Vendor-specific expertise was a fine specialist asset. It is a weak generalist asset, because the whole point is to move across systems without relearning each one.
If you manage a team, resist the temptation to treat despecialization as a headcount exercise. The gains come from removing handoffs, and removing handoffs requires rethinking scope, not just cutting the fourth engineer. Redraw roles around end-to-end ownership of a value stream. Give a person the churn dashboard, source to chart, with agents to do the procedural work and a review process to catch their mistakes. Then measure cycle time, not utilization.
Invest in the apprenticeship problem before it invests in you. In three years you will need senior generalists and there is no longer a natural pipeline producing them. Pair juniors on review. Rotate them through the full stack in months rather than years. Accept that they will be slower and make more mistakes than an agent, because the mistakes are the curriculum.
Fix your platform for multi-agent concurrency now. A catalog that supports branching, a table format with snapshot rollback, and a review workflow that treats agent changes like pull requests are table stakes for a team of generalists. Without them you get five people stepping on each other and blaming the tools.
Warning signs you can watch for
You do not have to wait for a reorg to see despecialization arriving in your organization. The leading indicators show up months earlier.
Ticket volume between teams drops while output stays flat or rises. That means people are doing adjacent work themselves instead of asking for it. Backfill requests stall in the budget process, not because the budget is tight but because the hiring manager cannot articulate what the narrow role does that the existing team is not already covering. Job postings from your own company start listing four or five skill areas where they used to list one. Senior people spend more of their calendar on review and less on execution, and they say so in one-on-ones. And the loudest complaints shift from "I am waiting on another team" to "I approved something I did not fully understand."
That last complaint is the one to act on immediately. It is the sound of scope widening faster than judgment, and it is fixable with review pairing and better rollback tooling. Ignore it and the next signal is an incident.
Finally, be honest with your team about what is happening. The people on it can see that the tickets are drying up and the scope is widening. Naming the shift, and describing what the wider role looks like and how they get there, does more for retention than any amount of reassurance that "AI will not replace you." They know it will not replace them. They want to know what it is turning them into.
Where This Is Heading
The World Economic Forum's Future of Jobs Report 2025 projected 170 million new jobs and 92 million displaced by 2030, a net gain of 78 million and about 22 percent structural churn. I hold that projection loosely, because every such projection has been wrong in the specifics. I hold the churn number more tightly, because churn is what despecialization looks like from the outside. Roles get deleted and recreated with wider definitions. The person often stays. The job title changes.
Three things I expect to see by the end of the decade.
Job titles stop describing tasks and start describing domains. "Analytics engineer" and "data engineer" merge into something like "data owner for marketing" or "revenue data lead." The title tells you what business outcome the person owns, not which layer of the stack they touch, because they touch all of them.
Agent orchestration becomes a general professional skill, like email or spreadsheets, rather than a job. The 280 percent growth in agentic AI skill mentions in postings is the leading edge of this. Within a few years it stops being listed because it is assumed, the way "proficient in Microsoft Office" quietly disappeared from postings once everyone was.
The productivity gains show up as smaller companies doing bigger things rather than big companies doing the same things with fewer people. S&P Global's data already shows small firms forecasting net positive employment effects from AI while large firms trend negative. Small firms use AI to expand what a small team can cover. Large firms use it to remove handoffs they no longer need. Both are despecialization. They just feel different from inside.
The bear case for my thesis is that the judgment layer turns out to be thinner than I think, and agents get good enough at judgment that the generalist directing them becomes unnecessary too. I do not dismiss that. I think the timeline is longer than the loud voices suggest, because judgment in a real organization is inseparable from context, relationships, and accountability that models do not hold. But if I am wrong about that, I am wrong about the endpoint, not the shape of the next decade. Even in the bear case, the path runs through despecialization first.
Conclusion
The question "how many jobs will AI eliminate" assumes that jobs are fixed containers and AI either fills them or empties them. Jobs are not fixed. They are bundles of tasks that organizations assembled under a specific set of constraints, and the biggest of those constraints was that expertise was expensive to acquire and slow to switch between. AI relaxes both constraints at once.
The result is not empty containers. It is fewer, wider ones. Work that used to need a chain of specialists connected by tickets now fits inside one person directing agents across the chain. That person needs less recall and more judgment. They need to know what wrong looks like in five domains rather than what right looks like in one.
That is a harder job in some ways and a better one in others. It is harder because the blast radius is wider and the apprenticeship path that used to produce judgment is broken. It is better because the coordination overhead that ate a quarter of every specialist's week is gone, and because the work is closer to the outcome.
The three-person team I once needed for a personal website is already gone, replaced by one person with wider judgment and better tools. The eleven-person pipeline team is going the same way, replaced by a smaller group of generalists who each own a slice end to end. Our job, as individuals and as the people who run teams, is to make sure that person exists, knows how to check the agent's work, and is not a 23-year-old who has never seen a pipeline fail.
Keep Going
If this piece was useful, I have written a lot more on how AI reshapes work and the economics behind it. My book on AI and labor economics goes much deeper into the task-versus-job framing and what it means for careers and policy, and you can find it at a.co/d/06SeOKw8. You can find every book I have written, across lakehouse architecture, Apache Iceberg, Apache Polaris, and AI, at books.alexmerced.com.
Top comments (1)
The breadth point is right, but I would separate task ownership from skill ownership. AI makes it cheaper for one person to carry the project across boundaries, while the expensive part becomes knowing when a specialist judgment is actually binding. That feels less like the end of specialization and more like specialists becoming escalation paths instead of default handoffs.