Are Coders the Craftsmen of a New Industrial Revolution?

In the early stages of the Industrial Revolution, machines began changing something that had existed for centuries: the relationship between skilled workers and the things they produced.

A craftsman might once have made an object from beginning to end. The value of the worker was partly in knowing how to perform the work itself.

Industrialization changed that.

Machines could perform portions of the work faster and more consistently. Production could be divided into specialized tasks. Factories could produce goods on a scale that individual workshops could not match.

This did not simply make craftsmanship disappear.

Some crafts declined. Some survived. Some became specialized. Some workers became machine operators. New technical and managerial professions emerged. The meaning of skill itself changed.

In 2026, something that looks surprisingly similar may be happening in software development.

AI coding tools can now generate programs, modify existing code, explain errors, write tests, and increasingly perform larger portions of software-development workflows.

That raises an obvious question:

Are coders becoming the craftsmen of a new Industrial Revolution?

The answer is probably partly — but not exactly.

The useful comparison is not:

Machines replaced craftsmen, therefore AI will replace programmers.

It is more subtle:

Industrialization made production cheaper and changed where human skill was valuable. AI may be doing something similar to software development.

1. Before the Factory: When Production Was a Craft

The Industrial Revolution did not invent machines. What changed was the scale and organization of production.

Before industrialization, many goods were produced through forms of skilled manual labor. Artisans and craftspeople often possessed knowledge accumulated through training and experience. Production could take place in workshops, homes, or small businesses rather than enormous centralized factories.

The important characteristic was not simply that a human made something.

It was that human skill was embedded directly in the production process.

The worker knew how to make the thing.

Industrialization began separating those ideas.

A machine could perform part of the process.

A worker could operate the machine.

Another worker could perform another stage.

A manager could organize the entire process.

An engineer could improve the machinery.

A quality-control worker could inspect the result.

The person who ultimately understood the production system did not necessarily have to personally perform every operation.

That was one of the deeper changes brought by industrialization.

The transition from hand labor to machine labor changed production tasks, jobs, and job requirements. Manufacturing increasingly moved from artisan-style hand production toward machine production concentrated in factories.

So industrialization did not merely replace a tool.

It reorganized the production system.

That distinction matters when looking at AI and programming.

2. Programming Was Already a Kind of Craft

Programming has never been exactly the same as traditional physical craftsmanship.

A programmer does not carve a chair, forge a horseshoe, or weave cloth.

But programming has historically contained many characteristics associated with craft.

A programmer learns a language.

They learn the quirks of their tools.

They develop techniques through experience.

They debug strange failures.

They develop personal approaches to solving problems.

And, importantly, they create something whose quality can depend heavily on the judgment of the person producing it.

For a long time, writing the code itself was a substantial part of the work.

That does not mean programmers literally wrote everything from scratch. They had compilers, libraries, frameworks, IDEs, code generators, documentation, open-source projects, and countless other abstractions.

In fact, programming has been moving toward higher levels of abstraction for decades.

High-level programming languages already allow programmers to ignore enormous amounts of the underlying machine's complexity. Software engineering itself developed as a response to the realization that increasingly large software systems could not simply be managed through individual programming talent alone.

This is important because AI is therefore not the first industrialization of programming.

It may be another step in a much longer process.

The difference is that modern AI can attack a particularly visible part of the process:

producing the code itself.

3. When Code Becomes Cheap

Imagine two programmers in different eras.

The first has a specification and needs to implement a feature.

They have to understand the requirement, decide how to structure it, write the code, debug it, test it, and integrate it.

The second programmer gives an AI coding tool the same requirement.

Within seconds, the tool may produce an implementation.

The second programmer has not eliminated the problem.

But the economics of one part of the problem have changed.

Code generation has become cheaper.

This is where the Industrial Revolution analogy becomes interesting.

Industrial machinery made producing certain physical goods cheaper.

AI coding tools can make producing certain software implementations cheaper.

The analogy is not perfect, but the underlying economic question is similar:

When the production of something becomes cheaper, where does the valuable human work move?

4. The Bottleneck Moves

This may be the most important similarity between industrialization and AI-assisted programming.

Suppose writing a particular piece of code takes an experienced programmer two hours.

An AI system produces something plausible in thirty seconds.

The bottleneck has changed.

The difficult part may no longer be:

“Can someone write this?”

It may become:

“Is this actually the right thing to write?”

And then:

Does it satisfy the requirements?

Does it work in unusual cases?

Is it secure?

Is it maintainable?

Does it fit the existing architecture?

Does it introduce technical debt?

Did the AI misunderstand the problem?

Does it interact correctly with the rest of the system?

Can another developer understand it six months from now?

The production of code may become easier while the evaluation of code becomes more important.

That does not prove that AI has made programmers more like factory supervisors.

But it demonstrates something important:

Generating software and validating software are becoming increasingly separable activities.

5. “If It Works, Don't Touch It”

There is a small piece of programming culture that illustrates this beautifully.

For years, programmers have joked about the rule:

“If it works, don't touch it.”

It appears repeatedly in programming memes and developer discussions. The joke usually involves some horrifying piece of code that nobody understands anymore — but it works, so everyone is afraid to modify it.

Obviously, this was never a universal programming philosophy.

Good software engineering has always cared about maintainability, testing, architecture, documentation, security, and correctness.

The joke exists partly because programmers recognize a real experience:

working code can be frightening to change.

A programmer who spent hours or days getting a difficult system to work could have a strong incentive to leave it alone.

The code itself represented effort.

There was something psychologically significant about knowing:

I made this work.

AI changes that relationship.

If an AI can produce another implementation in seconds, the fact that the code was difficult to type becomes less important.

The question can shift from:

“Can I make this work?”

to:

“Should this code exist in this form at all?”

Or even:

“The AI wrote this. Can I prove that it is good?”

That is a subtle cultural change, but potentially an important one.

6. From Making to Checking

This is where the analogy to industrialization becomes strongest.

Imagine a traditional craft worker who personally produces an object.

Now imagine an industrial process where machinery produces thousands of objects.

The human role can move toward operating the machinery, designing the process, maintaining it, and checking whether the products meet specifications.

The worker has not necessarily become less skilled.

The location of the skill has changed.

Something similar could happen in software.

Instead of spending most of the working day manually producing code, developers could increasingly spend their time:

defining requirements,

designing systems,

reviewing generated code,

testing behavior,

investigating failures,

securing applications,

integrating components,

designing architecture,

evaluating tradeoffs,

and supervising automated agents.

This does not mean programmers become managers.

It means the boundary between producing an implementation and engineering a system may become more visible.

7. But Are Programmers Really Becoming Factory Workers?

Here the analogy starts to break down.

A factory machine operates on physical materials according to relatively defined mechanical processes.

An AI coding system does not work like a nineteenth-century steam engine.

It generates probabilistic outputs.

It can misunderstand instructions.

It can produce code that looks convincing but is incorrect.

It can also solve problems that previously required significant human effort.

The result is not simply:

machine does task → human supervises machine.

A developer might ask an AI to generate a solution, inspect it, ask for changes, run tests, investigate failures, reject parts of the solution, redesign the architecture, and then ask the AI to implement the new design.

That is different from standing beside a machine in a factory.

There is another important difference.

Software has always been unusually easy to automate.

Compilers transformed human-readable programs into machine instructions.

Libraries allowed programmers to reuse enormous amounts of work.

Frameworks standardized common application structures.

Integrated development environments automated editing, compilation, debugging, and navigation.

Programming has therefore spent much of its history moving work from direct manual production toward abstraction.

AI is entering an already highly automated profession.

That makes the Industrial Revolution analogy useful — but also limited.

8. AI Might Make Programmers More Productive

There is another reason to be cautious.

Making code generation cheaper does not necessarily mean making programmers unnecessary.

If producing software becomes cheaper, organizations may simply want more software.

This has happened repeatedly with technology.

When a capability becomes cheaper, demand can increase.

The important question therefore isn't simply:

“How much code can AI write?”

It is:

“How much additional software will people want when software becomes cheaper to produce?”

And even the productivity effects of AI are not settled.

Early research has produced results that vary by task, developer experience, repository, and AI system.

In other words:

We are still measuring the transition while it is happening.

9. The Skills That May Become Less Valuable

If AI becomes increasingly capable at generating routine code, some programming tasks may become less economically valuable.

This could include portions of:

boilerplate implementation,

routine CRUD code,

basic scripts,

simple application scaffolding,

straightforward transformations,

repetitive documentation,

common test generation,

and simple debugging.

That does not mean these skills become worthless.

It means their scarcity may decrease.

And when something becomes easier to produce, its economic value can change.

A programmer who spends most of their value-producing time manually typing repetitive code could therefore face a very different market from one who understands how to design and validate complex systems.

10. The Skills That May Become More Valuable

The opposite side of the transition is more interesting.

If producing code becomes cheap, then skills that help determine which code should be produced may become more valuable.

System Architecture

Someone still needs to understand how components fit together.

Requirements Analysis

An AI can implement an unclear requirement very efficiently.

That does not make the requirement less unclear.

Testing

Generated code still needs to be tested against reality.

Security

A plausible implementation can still contain serious vulnerabilities.

Debugging

When a complex AI-generated system fails, someone has to understand why.

Code Review

Someone needs to determine whether generated changes should actually enter the system.

Domain Knowledge

Knowing what the software is supposed to accomplish remains valuable even if another system can write the implementation.

Judgment

Perhaps most importantly, someone has to recognize when an apparently good answer is actually wrong.

So the future skill may not simply be:

“Can you code?”

It may increasingly be:

“Can you tell good software from bad software?”

11. Could Programming Split Into Two Professions?

This raises a fascinating possibility.

Programming and software engineering may gradually become more visibly distinct.

One activity is:

Code production.

The other is:

Software engineering.

Code production asks:

“How do we implement this?”

Software engineering asks:

“What should we build, how should it work, how should its parts interact, how do we know it is correct, and how do we keep it working?”

AI is particularly good at attacking the first question.

The second is much harder to automate completely because it involves context, requirements, tradeoffs, uncertainty, and responsibility.

This does not mean AI can never perform those activities.

It means that generating an implementation is not equivalent to understanding the system being engineered.

That distinction may become increasingly important as AI systems become capable of producing entire applications rather than individual functions.

12. The Craftsman Does Not Necessarily Disappear

This is where the historical analogy needs its most important qualification.

Industrialization did not make craftsmanship universally worthless.

Some forms of craftsmanship declined because machines could perform the work more cheaply.

Other forms survived because they offered qualities that mass production did not.

Some became specialized.

Some became luxury products.

Some crafts changed their relationship with machines.

And entirely new professions appeared around the industrial system.

The Industrial Revolution therefore did not simply produce:

craftsmen → machines

It produced a much more complicated transformation:

craft production → industrial production → new divisions of labor and new forms of expertise.

The same could happen with programming.

Routine code generation might become increasingly automated.

Yet complex software engineering could remain highly specialized.

Human programmers might spend less time writing individual lines and more time designing systems.

Some developers might become highly specialized in architecture.

Others might focus on security.

Others might work primarily with AI agents.

Others might become domain experts who use AI to build software without identifying primarily as programmers at all.

And some people may continue writing code manually because they enjoy the craft.

Automation does not necessarily kill the craft.

Sometimes it changes why people practice it.

13. There Is an Important Difference Between a Craftsman and a Programmer

There is, however, one major problem with the analogy.

A physical craftsman is constrained by the physical world.

A software developer works in an abstract environment.

The programmer already works through layers of machines, languages, libraries, compilers, operating systems, frameworks, and abstractions.

A programmer has never really been manufacturing software in the same sense that a blacksmith manufactured a horseshoe.

They have been describing a process to another machine.

AI adds another layer to that abstraction.

Instead of:

human → programming language → compiler → machine

we increasingly have:

human → natural language/specification → AI → programming language → compiler → machine

The programmer has not suddenly gone from craft to industry.

Programming has been moving toward abstraction for decades.

AI may simply be accelerating that trajectory.

14. So Are Coders the Craftsmen of the Industrial Revolution?

Not literally.

The historical circumstances are too different.

The Industrial Revolution involved factories, mechanized physical production, urbanization, enormous changes in labor organization, transportation, capital investment, and social structure.

AI coding is not a digital copy of that process.

But the analogy becomes useful if we ask a narrower question:

Is AI changing the economic value of software-development skills in a way that resembles the way mechanization changed the value of manual production skills?

Here the answer may be yes.

The strongest similarity is not replacement.

It is the changing location of skill.

Industrial machines made some manual production cheaper.

AI can make some code production cheaper.

Industrialization reduced the importance of personally performing every stage of production.

AI may reduce the importance of personally writing every line of code.

Industrial production increased the importance of machinery, process design, engineering, standardization, and quality control.

AI-assisted software development may increase the importance of architecture, requirements, testing, security, integration, and judgment.

And just as industrialization did not eliminate all craftsmanship, AI does not necessarily eliminate all programming.

It may change what it means to be a programmer.

15. A New Version of “If It Works, Don't Touch It”

Perhaps this is why the old programming joke becomes interesting in the AI era.

For decades, the joke was:

“I wrote this strange code, and somehow it works. Don't touch it.”

AI introduces a different situation:

“The AI wrote this strange code, and somehow it works. Should we trust it?”

That is a fundamentally different relationship with software.

The programmer no longer necessarily has the same intimate connection with every line.

The code may be generated rather than authored manually.

That makes understanding and verification more important.

The irony is that the easier code becomes to produce, the less impressive the mere existence of working code becomes.

A working program is no longer necessarily the achievement.

The achievement may be knowing whether it is the right program.

16. We Are Too Early to Know How This Ends

There is one final reason to resist dramatic predictions.

We are living through the transition.

It is September 2026.

We do not have the benefit of hindsight.

We do not know whether AI will ultimately reduce the number of professional programmers, increase software demand enough to employ more of them, create entirely new software professions, or produce some combination of all three.

We do not even know exactly how productive AI coding systems will become.

Current evidence already shows contradictory signals: AI adoption among developers is high, while trust in AI output remains considerably lower; some experiments have found productivity gains in particular settings while others have found slowdowns.

That uncertainty is not a weakness of this historical comparison.

It is part of the historical story.

People living through the Industrial Revolution did not know exactly what industrial society would become either.

They experienced factories appearing, trades changing, machines becoming more capable, and old economic relationships being disrupted without knowing the final shape of the world they were entering.

We are doing something similar now.

The Real Question May Not Be Whether Programmers Disappear

The most interesting question is therefore not:

“Will AI replace programmers?”

That question assumes that the profession has only two possible futures:

survival or extinction.

History suggests something more complicated.

A profession can survive while its work changes dramatically.

A skill can become less economically valuable without becoming useless.

A craft can become specialized.

A worker can become an operator, designer, engineer, supervisor, or something that did not previously exist.

The Industrial Revolution did not simply eliminate human skill.

It reorganized it.

AI may be beginning to do something similar to software development.

The programmer of the future may write less code.

They may spend more time designing systems, defining requirements, evaluating AI-generated solutions, testing software, securing it, debugging it, and deciding whether the machine's answer is actually good enough.

Or the profession may evolve in ways we cannot yet see.

That is the part we cannot know in 2026.

But perhaps the most useful lesson from the Industrial Revolution is that technological transformation does not necessarily ask:

“Can humans still do this?”

It asks a more difficult question:

“If machines can do this, what should humans do instead?”

For programmers, that question may be just beginning.