Why developers won't disappear because of AI

"In five years we won't need developers anymore." It's the line you hear at every new AI model release. The logic seems airtight: if a machine writes code, why pay someone to write it?

The problem is we've heard this exact argument before. Word for word, roughly two hundred and fifty years ago, aimed at a different trade: the weaver. The machine could weave. So the weavers, people said, would disappear.

They didn't. They became something else — and produced a hundred times more. More importantly: the revolution that transformed them followed a specific logic, and that same logic is now working on developers, in the opposite direction.

When James Hargreaves patented the Spinning Jenny in 1764, and Edmund Cartwright built the first working power loom in 1785, the British textile industry changed in ways we struggle to grasp today. In the following seventy years, UK raw cotton consumption grew from 6 to 663 million pounds. More than a hundred-fold.

The popular story says machines "stole the work" from weavers. The historical reality is more interesting. The number of people employed in textiles grew during those decades, it didn't shrink. What changed was the kind of work they did.

The artisan weaver who produced two metres of cloth a day on a hand loom did disappear. But new roles emerged in their place: the power loom operator (supervising five or ten machines at once), the maintenance technician, the textile engineer, the industrial pattern designer, the production manager, the large-scale merchant. Jobs that didn't exist before, because the problem they solve didn't exist before.

The machine didn't replace the weaver. It replaced the physical act of weaving. The weaver's knowledge — understanding yarns, reading patterns, spotting quality issues, intervening when something goes wrong — was amplified, not eliminated.

Something very similar is happening today, with software. An AI assistant can write hundreds of lines of routine code in seconds: forms, REST endpoints, database schemas, standard UI components, API integrations, basic unit tests.

That whole portion of the job that developers call "boilerplate" — repetitive, predictable code that has to be written but isn't where the value lies — is exactly the equivalent of the physical act of weaving. It's the work the machine can amplify by a factor of 10, 50, 100.

But writing code was never the real job of a developer. The real job is understanding what needs to be built, why, for whom, under which constraints, which trade-offs to accept, how to integrate it with the rest, how to make it maintainable, how to evolve it. AI doesn't do any of this — not because it isn't "smart enough", but because it requires context, conversations with real people, implicit knowledge of the business, intuition about risk.

What's changing, and changing fast, is the distribution of a developer's time. Fewer hours writing routine code. More hours talking to whoever will use the product, designing architecture, evaluating alternatives, guiding the AI toward the right solution — because, just like a loom, an AI assistant needs someone who knows what to make it do.

This is where the two revolutions part ways. And the difference isn't marginal: it's structural, and it defines the kind of value AI in programming is unlocking.

The mechanization of textiles had a very clear goal: produce the same fabric at scale, at radically lower cost. Total standardization. A thousand metres of calico identical to another thousand metres of calico. Millions of identical shirts. The economic value lived in uniformity: same product, huge scale, collapsed unit cost.

AI in programming does the exact opposite. It doesn't reduce the cost of producing the same software — it reduces the cost of producing different software every time, tailored to a specific problem.

It's a massive difference, and to grasp it you have to look at the software market of the last twenty years. The SaaS industry was born precisely because building custom software was expensive, slow and risky. The solution: one product sold to thousands of companies, each one adapting as best it could. It was our textile model: mass production applied to code.

With AI, that calculation shifts. Building an application tailored to a single business process — previously unthinkable under 50,000 euros — can now be done in timeframes and budgets that make it competitive with a multi-year SaaS subscription. Not for every case — but for many more than most companies imagine.

If the revolution were the "textile" type, developers would be right to worry: value would shift toward a few large players capable of operating at scale, and most technical work would become commodity.

But since the direction is opposite — toward mass customization, not mass standardization — the reverse happens. Value shifts toward whoever can understand a specific problem and translate it into a system that solves it. And that capability, today, is still deeply human.

Three things, concretely, are changing for people who build software professionally.

First: the entry threshold to "custom" is dropping. Projects that used to be economically impractical become sustainable. Companies that had resigned themselves to an approximate SaaS start asking whether they can afford something built specifically for them. Demand for bespoke software, far from shrinking, is growing.

Second: the craft moves upstream. The part of the work worth most isn't writing the code — it's understanding the client's domain, identifying processes that deserve a dedicated application, designing the architecture, making trade-off decisions. The pure developer who wrote code as an "executor" is the modern version of the artisan weaver. The developer who designs systems is the modern version of the textile engineer.

Third: quality of judgement becomes the main asset. When AI can produce three plausible solutions in thirty seconds, value shifts to whoever can pick the right one. Recognizing an architecture that won't scale, a badly designed API, a trade-off that will cost you dearly two years from now — no model does this, and probably won't soon.

"Will AI make programmers disappear?" is the same — wrong — question people were asking about weavers in 1790. The answer is the same: no, it will create different kinds, probably more of them. But of a different kind.

The right question, whether you're a developer or a company figuring out how to move, is another: if building custom software is becoming ten times faster and cheaper, which of my business processes really deserve an application built specifically for them — instead of yet another monthly subscription?

Because that's exactly where, in the new space that just opened up, the game is being played. And as it did two and a half centuries ago, the winners won't be those afraid of the machine — but those who figure out, before others do, what to do with it.