AI Is the Steam Engine of the 21st Century

“People fear what they don’t understand, and hate what they can’t conquer.”

I’ve felt that way myself. As a backend engineer, I was skeptical of AI for a long time before I ever really used it.

But I wanted to understand it more than I wanted to fear it. And when AI started showing its true power, I couldn’t help drawing a parallel to something that had done the same thing — 200 years ago.

Before 1800, the limits of production were the limits of the human body. To weave more cloth you needed more hands — there was no other way. Output was locked to however much muscle you could put behind it. The steam engine picked that lock: it decoupled productive capacity from human muscle. And the result didn’t stop at “faster.” Factories, assembly lines, global supply chains — none of that could have existed before, not for lack of ideas but for lack of the energy to run production at that scale. And once the scale of production changed, jobs changed with it instead of disappearing: railways needed engineers, factories needed managers — entire professions nobody could have imagined before, because the scale of production that required them didn’t exist yet either.

Now look at AI, and it’s the same story. Before AI, the limits of software were the limits of how many people you had writing code. To ship faster, there was exactly one lever: add more people. AI doesn’t make developers smarter — it decouples software production capacity from human labor hours, the same way the steam engine once decoupled output from muscle. And the evidence isn’t thin: on SWE-Bench, the standard benchmark for real-world programming problem-solving, AI went from solving 4.4% of problems in 2023 to 71.7% in 2024 — in a single year. That’s not an ordinary tool-improvement curve. It’s a signal that production capacity is decoupling from headcount, exactly the way factory output decoupled from muscle two hundred years ago.

But a shift this large always meets resistance, and the resistance isn’t unreasonable. In 1811, English hand-weavers smashed machinery because they feared losing their jobs. They weren’t wrong to worry — traditional hand-weaving really did disappear. What they couldn’t see was that total employment didn’t shrink, it grew: 60% of American workers today hold jobs that didn’t exist in 1940. The history of technology has never played out as machines replacing all human work. It always replaces one specific kind of work, then opens up demand for a new kind that nobody needed before, because the technology to produce it didn’t exist yet. AI is no different. McKinsey estimates that by 2030, at least 14% of the global workforce will need to change occupations — 375 million people, and none of them get to stand outside this trend.

So what’s actually changing, if it’s not developers getting wiped out? AI isn’t replacing developers. It’s replacing one specific category of developer work: boilerplate code, basic unit tests, familiar SQL queries — the formulaic, repetitive stuff that doesn’t require reading context. What’s left — deciding what to build, making architectural trade-offs, noticing when a system is heading in the wrong direction — requires a grasp of context AI still doesn’t have, so it’s still weak there. And precisely because AI is weak there, that part just became far more valuable than it used to be. The bottleneck has shifted, not from “able to write code” to “no longer needing code,” but from “writing code” to “knowing what you’re building and why.”

A hand-weaver in 1820 couldn’t have imagined a mechanical engineer in 1850 — the profession didn’t have a name yet, no school taught it, there was nothing to picture. A switchboard operator in 1990 couldn’t have imagined a software developer in 2000, for the exact same reason. We’re inside that kind of transition right now — early enough to still be confused because the shape of the new work hasn’t shown itself yet, but late enough to see clearly which way things are moving.

I don’t know where I’ll land on that map five years from now. But I know one thing: not understanding it is not an option.