Will AI Replace You?

Will AI replace your job?

It’s become one of the defining questions of the AI era. It may also be the wrong one.

Nobel laureate Daron Acemoglu recently argued in The Humanist Review that AI may replace only about 5% of what humans do over the next decade, a figure he calls a “guesstimate.” His reasoning isn’t that AI is unimpressive. Models already show remarkable capability in software development, analysis, medicine and other knowledge work. The problem is what happens between a capability demonstration and actual work.

A model completing a task is not the same thing as an organization being able to delegate that task reliably. That gap may tell us more about the future of work than the next benchmark, model release or forecast of when AI reaches some particular level of intelligence.

Capability isn’t reliability

One of Acemoglu’s examples is voice recognition, a technology he has relied on since repetitive strain injuries left him unable to type in 1997. Decades of development pushed speech recognition toward extraordinary accuracy. But even 99% accuracy falls short when the remaining 1% changes the meaning of a sentence, executes the wrong command, or forces someone to proofread everything the system produces.

Generative AI has the same problem, except we’re asking it to do far more consequential things: write code, analyze contracts, conduct research, modify databases and operate other software. That a model can perform one of those tasks tells us about its capability. It tells us much less about whether we should let it perform that task repeatedly, autonomously and without supervision.

Capability isn’t reliability. But reliability doesn’t have to come entirely from the model.

The last 1% is a systems problem

The part of Acemoglu’s voice-recognition story that gets less attention is this: the technology didn’t stall because the models stopped improving. Dragon NaturallySpeaking was “like magic” in 1997. Yet, he writes, PC voice recognition today is “only marginally better than what was available in 2000,” after two decades of acquisitions, a bankruptcy and a consumer product steadily deprioritized. His conclusion:

“Breakthroughs in the ‘infrastructure’ of a new technology need to go hand-in-hand with the right kind of applications built on this infrastructure.”

— Daron Acemoglu

That’s the reliability gap, and it isn’t only a model problem. Much of the AI industry is trying to close it by making models better, and models will get better. But expecting the model alone to supply all the reliability that consequential work requires is the wrong architecture.

We’ve spent decades building reliable systems out of components that fail. Networks drop packets. Disks fail. Services go down. Processes crash. We don’t wait for those parts to become infallible; we engineer around failure.

AI systems can be built the same way:

Scope. Give models an explicit, bounded job.
Access. Control what they can read and change.
State. Keep it outside the model.
Evidence. Require it, and validate outputs against it.
Gates. Put consequential actions behind checks.
Recovery. Provide a way back when something goes wrong.
Escalation. Hand uncertainty to a human.

The model remains probabilistic. The system around it supplies the structure.

What that looks like in practice

This isn’t hypothetical. It’s how we build software at UX287, using RouteKit, the open-source workflow we use to let AI agents do real engineering work.

This week, AI agents shipped a series of changes to this website: prerendering for search engines and AI crawlers, structured data, a sitemap and a redesigned 404 page. The models wrote the plans and the code. They didn’t decide what shipped. Every change passed through the same structure:

A scoped story, with explicit target files and acceptance criteria.
An architecture review that read each plan against the real code and sent work back when it was wrong, once over a single mistyped character in a test requirement.
A build verifier that checked every page the way a search crawler sees it, and caught a change that passed type-checking but would have broken the production build.
Continuous integration that had to pass before anything could be released.
A person who decided when each release went to production.

The models made plenty of mistakes along the way. Almost none reached the site. Not because the models were perfect, but because the system assumed they wouldn’t be.

The model isn’t the system.

That changes the question from “Can AI do this job?” to “What work can this system safely perform, under what conditions, and where does human judgment remain necessary?”

Automation versus augmentation is still too simple

Acemoglu argues for “pro-worker AI”: technology designed to increase human capability rather than simply eliminate human labor. There’s a lot to like in that framing. But even the line between replacement and augmentation may hold the structure of work too constant.

Consider his electricity analogy. Electricity’s productivity payoff didn’t arrive when factories swapped a steam engine for an electric motor. For years, many electrified factories kept the old layout: one central power source driving every machine through overhead shafts and belts.

The gains came when factories put a small motor on each machine, and that freed them to rebuild everything else. Single-story plants replaced multistory mills. Equipment was arranged around the flow of work instead of the drive shaft. Jobs, management and the buildings themselves changed. Economic historian Paul David traced how long that took in “The Dynamo and the Computer”: roughly forty years from the first central power stations to the factory productivity surge of the 1920s.

The value wasn’t in the motor. It was in the redesign the motor made possible.

AI may follow the same path. Today we ask whether AI can write a requirements document, produce a design, implement a feature, review a contract or answer a support request. Those are useful questions, but they assume tomorrow’s organization looks like today’s, with AI taking over a few boxes in the workflow. That seems unlikely to be the end state.

What happens when cognition becomes software?

Software made computation cheap. Networks made communication cheap. Cloud infrastructure made computing resources available on demand. AI is making certain forms of cognition available as software: research, classification, synthesis, translation, generation, comparison, critique, planning. Not perfectly, and not without supervision, but increasingly these capabilities can be invoked anywhere in a system.

That changes more than the speed of individual tasks:

A product manager might not simply write a PRD faster. Research, customer feedback, product telemetry and technical constraints could be continuously synthesized into a living representation of product state.
An engineer might not simply write code faster. Implementation could operate inside requirements, architecture, dependencies and acceptance criteria, with every change validated against them.
A designer might not simply generate screens faster. The system could reason across research, accessibility requirements, interaction patterns, design-system constraints and implementation state, while the designer sets intent and judges outcomes.

The important change isn’t necessarily replacing the person doing the existing task. It may be changing what the task is, and eventually the organization around it.

The goal isn’t autonomy

This isn’t an argument against automation. Some tasks should be automated. Some jobs will contain fewer human tasks. Some roles will shrink or disappear; others will grow or emerge.

But the boundary between human and machine shouldn’t be set by a preference for maximum automation or for permanent human participation. It should be set by the work:

What does it cost to be wrong?
Can the result be independently validated?
Is the action reversible?
Does it require judgment or accountability?
What happens when the system meets something unexpected?

A low-risk, easily validated, reversible task might run autonomously. A consequential decision made on incomplete information might need human review. Those boundaries can move as the system earns trust.

Autonomy isn’t the goal. Validated outcomes are.

The organizational problem

This may help explain why enormous gains in AI capability haven’t yet produced equally enormous gains in organizational productivity. Acemoglu echoes Robert Solow’s 1987 quip about computers: they’re “everywhere but in the productivity statistics.”

Giving everyone a chatbot isn’t organizational transformation. Neither is attaching an agent to every application. Organizations are systems of processes, permissions, information flows, responsibilities and institutional knowledge. Introducing probabilistic software without redesigning those systems can easily create more work, not less.

Someone still has to decide:

what the system knows, and which sources are authoritative;
what it’s allowed to do;
how its work is evaluated;
who owns the exceptions; and
what happens after a failure.

Those aren’t primarily model problems. They’re product, systems and organizational-design problems.

The wrong unit of analysis

Acemoglu may be right that only a small share of human work will be replaced by AI this decade. He may be wrong. The number is less interesting than the assumption underneath the debate: that we can predict AI’s future by mapping tomorrow’s technology onto today’s jobs.

Transformative technologies rarely leave the systems around them unchanged. The more useful question is what work looks like when probabilistic cognition becomes an ordinary part of the technology stack. Some work will be automated. Some will be amplified. New work will become possible. And organizations will restructure around capabilities that barely existed a few years ago.

Getting there doesn’t require pretending AI is a person. It requires treating it seriously as software: extraordinarily capable, inherently probabilistic, and operating inside systems designed to make its work reliable.

The future of work won’t be decided by the model alone. It will be decided by the systems we build around it.