Who Owns the Machine?

The Automation Revolution

We may be living through the early stages of something comparable to the Industrial Revolution. Maybe bigger. AI systems and robotics are encroaching on tasks that seemed securely human just a decade ago: driving vehicles, interpreting medical images, generating text at industrial scale, sorting and assembling in warehouses. The disruption raises a question economists have been dancing around for years. If machines can produce abundance with minimal human labor, what happens to the people whose work is no longer needed? And more to the point, who ends up with the gains?

The Promise of Automation

The historical argument for automation isn’t complicated. More productive machines mean more output for the same effort, which in principle means more for everyone. Agriculture went from employing nearly the entire workforce to under 2% of workers in developed economies. Manufacturing productivity climbed for decades while living standards rose alongside it. These are real achievements.

The current wave extends into territory that felt different until recently. Language models write, computer vision interprets images, robotic systems handle complex physical tasks. What seemed years away is suddenly available. In principle, this is good news. If machines can produce more with less human effort, there is more to go around.

The problem is that “in principle” does a lot of heavy lifting.

The Distribution Problem

When a company automates a task, the productivity gains land primarily with the owners. Workers whose jobs disappear end up competing for whatever remains, which tends to push wages down. This isn’t a new observation. Since the 1970s, productivity in most developed economies has continued rising while median wages have stagnated. The tight link between productivity and pay broke sometime around then and hasn’t really come back.

Technological progress and broad-based prosperity are related, but the connection doesn’t maintain itself automatically.

Historical Lessons

Previous waves of automation did eventually produce widely shared prosperity. The route was neither automatic nor quick. The Industrial Revolution brought generations of displacement and hardship before the gains reached ordinary workers. It took labor movements, social insurance programs, legislation, and sustained political struggle to make the technology serve the majority rather than just the few who owned the machines.

The eight-hour workday wasn’t a gift. Neither was the weekend, nor workplace safety law, nor the prohibition of child labor. These came through decades of strikes and organizing. The current moment differs in many ways from that period, but that particular dynamic probably isn’t one of them.

The Acceleration of Change

What’s distinctive now is speed. Earlier technological transitions unfolded over decades, long enough for industries to adjust, for workers to retrain, for institutions to evolve. The current pace of AI development is compressing that timeline in ways that make adaptation genuinely difficult.

Retraining programs assume people have time to retrain. Institutional adaptation assumes institutions can keep up. When change moves faster than those mechanisms allow, the disruption is real even if the eventual destination looks manageable. A retraining initiative that takes eighteen months doesn’t help a worker whose field disappeared last quarter. The policy tools designed for slower transitions may simply not be adequate here, and it’s worth saying that plainly.

Automation in Security and Defense

Cybersecurity illustrates the dual nature of automation as clearly as any domain I know. Security operations centers once ran on human analysts reviewing logs, correlating events by hand, trying to spot patterns across systems that generated far more data than any team could meaningfully process. Automated platforms now handle millions of events per second, flagging anomalies in network traffic or identifying SQL injection attempts in HTTP access logs within milliseconds. No human review process could match that throughput.

The same distribution dynamics apply, though. Sophisticated threat detection infrastructure is expensive. Organizations with resources deploy enterprise-grade platforms; those without remain exposed to threats the better-resourced can block automatically. The automation of security hasn’t leveled the playing field. Critical infrastructure operators, small municipalities, hospitals running on thin margins: they often lack the budget for what larger organizations treat as baseline protection. Meanwhile the same automated capabilities that defend well-resourced systems are fully available to sophisticated attackers. The asymmetry compounds over time.

Open source security tools offer a partial answer. When detection logic and playbooks are freely available, defensive knowledge reaches administrators who couldn’t afford commercial alternatives. The choice between proprietary tooling and open approaches in security is ultimately a choice about who gets to benefit from defensive capabilities, and the stakes are higher than they might appear from the outside.

Infrastructure as Code

System administration has gone through its own version of this transformation. Configuration management tools let administrators define desired system states in code and apply those configurations across entire fleets of machines. An Ansible playbook handling auditd rules, firewall policies, and kernel hardening parameters can be tested, versioned, and applied consistently in a way that manual administration never allowed. The reduction in configuration drift alone justifies the investment.

The efficiency gains are real. Work that once took hours of repetitive effort across dozens of systems takes minutes. Security benchmarks that would be practically impossible to implement by hand become achievable when encoded as automation.

Those gains follow the same distribution patterns. Fewer administrators are needed to manage more infrastructure. The skills required for infrastructure-as-code aren’t trivial to develop, and the window for transition isn’t always generous. There’s also a structural shift underneath all this worth naming. Large cloud providers offer managed services that abstract away infrastructure entirely, which is convenient and also concentrates control over critical computing resources in a small number of companies. Organizations that depend on those platforms trade autonomy for efficiency. That tradeoff gets less deliberate consideration than it probably deserves.

The Developer’s Position

Software developers occupy a strange position in this landscape, and it’s something I find myself thinking about more lately. We build automation that displaces labor in other fields, and the same logic is increasingly pointing at our own work. Language models generate code, review pull requests, explain complex systems. The tools we used to automate others are being trained on what we produce.

There’s a recognizable pattern here. People tend to find particular cause for concern when the productivity logic reaches their own occupation. The case for sharing automation’s benefits doesn’t change based on which field is affected.

Developers do have real choices about what they build and how. Code can concentrate power or distribute it. Open source contributions make capabilities broadly accessible; proprietary development restricts them. These are choices about who benefits from automation, made constantly by technical workers, even when they’re not framed that way.

Rethinking Work and Value

Automation also surfaces an old awkwardness in how we think about work and value. Caregiving, teaching, and the kind of community work that holds neighborhoods together: these contribute enormously to social wellbeing and are compensated poorly. Financial engineering pays extremely well. The market measures many things, but social value isn’t reliably among them.

If machines handle more routine economic production, there might be an opening to redirect human effort toward work that matters and is currently starved of resources. Elder care, early childhood education, ecological restoration: the need is obvious and the investment is chronically insufficient. Getting there requires deciding that the gains from automation belong broadly, which is as much a political question as an economic one.

Policy Considerations

Education and retraining programs help when the pace of change allows time for them to function. The social safety net needs to be robust enough that technological displacement doesn’t mean destitution during the gaps between roles. Reducing working hours is an underrated option. If the same output requires less labor, distributing that labor more broadly while maintaining employment levels makes straightforward sense. The 40-hour workweek wasn’t decreed by nature; it was a policy choice, and it can be revisited.

Progressive taxation can redirect some of the gains from automation toward public goods. Profit-sharing structures give workers a stake in the productivity increases that their work helped generate.

None of this happens without political pressure. The interests that benefit from the current distribution have resources, organization, and direct access to policy. The broader population that would benefit from a different arrangement is fragmented and often reactive. Progress has historically required sustained effort over long periods. The eight-hour day came from decades of strikes and political action. That history isn’t particularly soothing, but it does suggest that the direction of travel is a choice.

The Post-Scarcity Question

Some observers imagine that automation might eventually make markets obsolete. I’m skeptical. We already produce enough food to feed every person on Earth, and hunger persists anyway because distribution is a political problem, and has always been. Abundance doesn’t automatically become access.

What matters is control: who decides what gets produced and on what terms it reaches people. Automation can increase productive capacity significantly without changing who holds power. It can concentrate power further, in fact, since those who own the automated systems capture the gains. Material abundance combined with concentrated ownership could look more like a new form of feudalism than any kind of liberation.

Technology and Choice

Technological development isn’t something that happens to us like weather. It’s shaped by decisions about what to build, how to deploy it, and who benefits. Individual choices, corporate strategies, and public policy all feed into those outcomes. They can also be shaped by collective action and democratic participation, when there’s the will and the organization to do it.

The automation revolution doesn’t have a fixed destination. The same trajectory could lead to broadly shared prosperity or to a situation where a small number of people own the systems that produce most of what everyone consumes. Fatalism about technology tends to serve people who benefit from the current direction. The idea that AI development follows its own natural logic, rather than being built by humans making specific decisions, forecloses exactly the kind of deliberate intervention that might change the outcome.

The challenges posed by automation won’t be resolved by any single policy or innovation. Progress requires the same iterative effort that characterized previous transitions: identifying what works, scaling it, adjusting when it doesn’t.

The technology to create abundance exists. Whether that abundance gets shared is a question about power, and it won’t be settled by the people who currently benefit from concentration. Progress in the past came from sustained effort by people with far less institutional power than their opponents. That’s not exactly comforting. It’s probably accurate.

I’m not optimistic by default. The forces favoring concentration are strong, organized, and well-resourced. Those pushing toward broader distribution are not. The outcome isn’t predetermined. It depends on decisions made by many people, most of them without significant institutional power. The conversation about automation needs to be a conversation about what we value and what kind of society we want to build. I don’t have complete answers to those questions. Leaving them entirely to technology companies and their investors, though, is no answer at all.