What AI actually changes about work

Start with tasks, not jobs

Almost every unhelpful conversation about AI and employment begins by treating a job as an atomic unit. Jobs are bundles of tasks, and AI is uneven across them. A role might be 30% document assembly, 20% routine correspondence, 30% judgment calls, and 20% relationship work. Two of those categories are highly automatable today; two are barely touched.

The realistic near-term picture is not that the role disappears. It is that the composition changes — sometimes drastically — and the changed role demands a somewhat different person than the old one did. That is a genuine disruption, but it is a different disruption than the one usually described, and it calls for different responses.

The pattern we see repeatedly

Across the builds we do, one shape recurs with unusual consistency: assembly gets automated and judgment gets concentrated.

The underwriter stops gathering documents and spends the day on marginal credit decisions. The security analyst stops reading benign alerts and spends the shift adjudicating ambiguous ones. The caseworker stops re-keying pay stubs and spends the time on cases with genuinely difficult circumstances. The lawyer stops locating the clause and spends the hour on what the clause implies.

Notice what this does to the work. The easy parts of the day — the mechanical stretches that provided recovery time between hard decisions — are gone. What remains is a denser sequence of the hardest parts of the job. That is more valuable work and often more satisfying work, and it is also more cognitively taxing. Organizations that assume a role becomes easier because the assembly disappeared tend to be wrong about workload, wrong about pacing, and wrong about who thrives in the new version of the job.

Verification is the new skill

When a system produces a plausible draft in seconds, the scarce human capability is no longer production. It is judging whether the output is right, quickly and accurately, and knowing when to distrust it.

This is harder than it sounds, and it is not evenly distributed. Verification requires enough domain knowledge to notice a subtle error in something articulate. It requires resisting automation bias — the well-documented tendency to accept a confident machine output more readily than a colleague's. And it requires calibrated skepticism: distrust everything and you lose the benefit; trust everything and you inherit the failure mode.

The design consequence is concrete. Systems that make verification cheap — citations to the source, highlighted evidence, explicit uncertainty, visible gaps — produce far better human decisions than systems that emit a polished answer. Fluency without provenance is an anti-feature in professional work.

The apprenticeship problem

Here is the part we think is genuinely unsolved, and it deserves more attention than it gets.

Professions have historically trained people through the easy work. The junior analyst learned the business by building the models nobody senior wanted to build. The junior lawyer learned contracts by reviewing hundreds of them. The junior engineer learned the codebase by fixing small bugs. That work was partly economic output and mostly education — the mechanism by which someone accumulated the pattern library that later enables judgment.

That work is exactly what automates first. If entry-level tasks disappear and nothing replaces them, the pipeline that produces senior judgment breaks — with a lag long enough that the consequences arrive years after the decisions that caused them. We do not think anyone has this properly solved. The partial answers we have seen work involve deliberately routing a share of automatable work to juniors as training, restructuring apprenticeship around verification and system oversight rather than production, and treating training explicitly as an investment line rather than a byproduct of doing the work.

Roles that did not exist recently

New categories of work are appearing around these systems, and they are not all technical. Evaluation design — building the test suites that define what "working" means for a given system — is becoming a discipline in its own right. AI operations, monitoring production systems for drift and failure, looks like a specialized branch of SRE. Forward-deployed engineering, sitting with users to translate messy process into system behavior, is one of the highest-leverage roles in the field. And oversight roles — the human in the loop on consequential decisions — are real jobs that need training and staffing, not an afterthought in an architecture diagram.

What separates the organizations that get this right

The differentiator is rarely technology selection. It is that they treat adoption as an organizational change rather than a software purchase: they involve the people doing the work in designing the system, rewrite productivity expectations to match the new task mix, invest in verification skill explicitly, deal honestly with the pipeline question, and are candid about what is changing rather than reassuring in ways that turn out to be false.

The organizations that struggle deploy a capable system into an unchanged process, keep the old metrics, tell everyone nothing will change, and then conclude the technology underdelivered. It usually did not. The technology worked; the surrounding system was never adjusted to receive it.