In 1844, John was a good shoemaker.
He worked in Lynn, Massachusetts, in a small shop with a handful of other men. The work was already divided between them, but skill still mattered everywhere.
John knew leather. He knew when a cut was wrong, when a seam would fail, when a shoe would never quite sit right. Years of work, experience and instinct had trained his hands to notice things other people simply didn’t.

Then the machines began to arrive.

At first, they simply made good shoemakers faster.
A machine could cut soles faster. Another could stitch leather. Another could save hours of hammering. This was mostly great. Nobody was particularly nostalgic about spending all day doing repetitive work by hand. The shops got bigger, shoes got cheaper, demand went up, and there were soon more people working in shoemaking than ever before.
They still called them shoemakers. But what they actually did was starting to look very different from the craft John had spent his formative years learning.

Some spent their entire day operating a single machine. Others maintained them. Someone had to organize the work, figure out why one station was constantly waiting for another, or decide which new machine was actually worth buying. The work wasn’t disappearing, but it was a far cry from what John was used to doing.

But John adapted, and so did his son Thomas, although not in the same way.
Thomas was never as good with leather as his father. Not even close. But he understood the machinery. He understood where things slowed down, why one machine sat idle while another had work piling up behind it, and how changing one part of the process could make the entire floor produce more.

John knew how to make a better shoe.
Thomas was becoming better at making more shoes.

John was still valuable in the places where the machines still struggled. But then slowly, one by one, the machines learned the difficult parts too. Every single step of making the shoe was mechanized. Even the ones only John knew how to do. Until, eventually, there was very little left in the process that required the kind of hands John had spent a lifetime developing.

By then, John was an old man. He left the business.
He could still pick up a factory-made shoe and immediately find the things he would have done differently. Too tight here. A little loose there. But the shoe was fine. More than fine, really.
And the factory could make hundreds of them. Thousands.

There were more workers, more shoes, more customers, more machinery, and an entire collection of jobs that barely existed when John first walked into that little shop.

And Thomas?
Thomas didn’t call himself a shoemaker anymore.

Thomas was a shoe factory engineer.

A worker at a control panel marked “Do Not Touch” beside a long factory line where glowing holographic shoes ride the conveyors.

Shoes, code. With enough time you can automate everything.

Talking About A Revolution

I’ve been thinking about “John” and “Thomas” a lot lately.

Mostly because I’m starting to suspect quite a lot of us are John, and not enough of us are trying to be Thomas. And unlike them, for us this revolution is not taking its sweet time rolling up to our doorstep.

For most of its history, software was expensive. It was expensive because the act of making software was expensive. Turning an idea into something that actually worked required a lot of skilled people spending a lot of time translating intent into instructions a computer could execute.

A surprising amount of what we call “software engineering” grew around the simple fact that producing software took a lot of human effort, careful planning and unique craftsmanship.
We built entire organizations around that constraint. We developed expertise in different technologies and sub-disciplines. And we defined our careers based on those constraints and expertise, as any craftsmen would.

But then “the machines” started arriving.

And while for a couple of years some of us might have stuck our heads in the sand, ignoring the tsunami of cheap, commoditized intelligence coming our way, by late 2026 there are drastically fewer naysayers left in the software industry.
Or at least fewer who are still employed.

I swear, it pains me to say this, but Claude can be better than most software engineers I’ve met in my 18 years in this industry.
And now even Uncle Bob tells us he doesn’t read the code anymore, and DHH says writing code by hand is no longer economically viable.

A veteran craftsman in work overalls inspects a glowing holographic shoe through a magnifying glass, the factory line humming behind him.

Are you still reading the diffs?

While this insanity is happening at unprecedented speed, I find that some of us are now spending more time than ever before on the “how” of building software.
Tinkering with skills, tools and workflows. Managing context and automating how it’s cultivated. Optimizing the agent building the thing, rather than the thing it is building.
The “machines” of our newly forming knowledge work factories.

In another time, in an older phase of this industry, I’d say those people have gone mad.

“The value is in the impact brought by that which you are building,
not by the process used to build it.”

This was a mantra I took pride in for years and made sure to teach to others.

But I think this time it’s different.

Leverage, Loss & Luddites

Software engineering is built on the leverage a machine can create over human skills and knowledge. We, software people, make money by leveraging the asymmetry between a man and a machine.

Teaching people skills is fun, but it creates no leverage. There’s only so much knowledge the average person can retain, only so many skills they can excel in, and so much time they can invest in learning while still doing their actual job.

Automation, the kind software creates, scales linearly. Every engineer knows this. It’s our job.
Write it once, run many times. But you still need to write it. You still need to understand what you are trying to solve, generalize it as best as you can, spend time building the automation, and then pray that it will be correctly used and that it will be worth the time you invested in building it.
Got a new problem? A new need you didn’t see before? You need to do it all over again.

But what about crafting an omnipresent intelligence? That compounds exponentially!
If you teach the agent what you know how to do best, it will ‘know’ it now and in all of its future existences. It will be able to apply this knowledge and automate on its own for every new need. You can turn it into “You” in a box, existing in infinite instances.
The more collective knowledge you and others pour in, the more this intelligence’s abilities compound. Simply because it synthesises knowledge and abilities no single person ever had in their possession.

This is also true for the craft of software engineering itself.

If you cultivate such an intelligence that can build software, one that can exponentially create this leverage and be wielded by nearly anyone, you simply have to rethink everything you thought you knew about the craft of software engineering.

For the first time, it might actually bring more value to work on the “How”.
Maybe even more value than doing the thing yourself.
Definitely more value than having someone else do it, if you can simply teach Claude to do it for them.

An empty factory break room, a lone coffee mug on the table, and through the window the machines still producing holographic shoes.

Productivity is up, but team lunch is not what it used to be.

Now I agree that my view is inherently biased. I’ve spent almost the last decade building infrastructure and platforms. For quite some time now, I’ve been focusing on the “How” so others won’t have to.
But I simply can’t stop seeing how building the “How” is eating away at the effort required to build the “What”.

A developer asks in a Slack channel, “How do I do XYZ?”
A year ago, the question was who should answer them, or whether the answer was simply RTFM.
Today this turns into a philosophical and moral question:

Do we spend the time teaching that person, knowing we will have to do it again and again with others, or do we build a skill for Claude and invest in context engineering instead?

At a time when everyone is looking to deliver more, faster and with fewer people, the latter always wins. Investing in building the factory and not in training the craftsmen.

Is this a problem?
Yes. No. Maybe. I don’t know.

When we choose to invest in the factory rather than the craftsmen, we are essentially accelerating the loss of knowledge and increasing our dependency on the machines. It’s a loop that keeps feeding itself, gradually taking us exactly where John ended up. Into obsolescence.

Sounds bad, right?
But what do we get in return?

We get to do more with less. We allow others to join and create in places where a lack of education or technical expertise once kept them out. We no longer have to be bothered by the details, or constrained by our dependence on others and the baggage that comes with it.
We get to dream and to make.

But that’s scary, because some of us built a career on our craft. We define ourselves based on it. It’s unfathomable for some of us to see a machine enable people who haven’t walked a mile in our shoes to produce something strikingly similar to the fruits of our labour.
And now you’re asking me to make it better?

Some resist. They point to the cracks and imperfections as reasons not to invest their labour in it, rather than as a signal to improve it. Some end up actively sabotaging such efforts, whether knowingly or subconsciously. And some simply ignore it and hope it will all go away somehow.

But as the saying goes, resistance is futile.
The factory is being built around us. That’s a fact.
Now we get to decide if we are John, Thomas, or maybe something else.

A dark factory seen from above: conveyors loop between machines carrying glowing shoes, with no one in sight but an empty desk in the corner.

Nobody’s home. Business as usual.

The Dark Factory

There’s this concept in manufacturing called a dark factory.

It’s a factory so automated that it can operate with the lights turned off. Off, because there are no people in it.
No people walking between stations, no workers standing by machines, no need to keep the place illuminated for human eyes.

It’s a fascinating idea. And a slightly terrifying one.
Because if you take everything I’ve argued so far to its logical conclusion, this is exactly where software engineering is heading.

At what point does the software factory we’re building become a dark factory?
A software factory where you describe what you need, and the machinery figures out what to build, how to build it and later how to maintain it.
A factory that needs no engineers. That even maintains itself.

It’s unfathomable.
For now…

But here is where my contrived story about “John” and “Thomas” stops working as a metaphor.

Between John and Thomas was a generation.
Between Thomas and the first dark factory was more than a century.

Do you really think our knowledge work industrial revolution will take a century to reach its conclusion?
Do we even have a decade?

We might all have to learn how to be John and Thomas, and whoever replaces Thomas.
All at the same time, if we want to stay relevant.
And that’s assuming there’s even a place for that third guy in that future factory.

A man sits in the factory manager’s office, chin in hand, looking through a big window at a vast automated warehouse of glowing shoes.

Everything is running perfectly. Now what?

So what are we supposed to do?

Honestly, I don’t think the answer is that everyone needs to become Thomas.

Not everyone should spend their days building agentic factories. Not everyone is good at it. And not every problem calls for one. And ultimately we are all still being paid for the “What”. The customer problem we solved, the business we moved forward, the thing that didn’t exist yesterday and now makes someone’s life better.

But none of us get to remain only John, either.

As more and more of our craft is being absorbed into the machinery around us, the question is no longer whether to use it. It is whether we take part in deciding what it learns, what it optimizes for, and where it must stop.
But even more importantly, knowing when to focus on building the machine and when to focus on the impact of what it’s making.

That is where focus becomes the new currency of excellence.

What is the highest leverage thing you can do to make an impact?
When do you build, and when do you teach the factory to solve a thousand similar ones?
And when is neither of those actually the problem worth solving?

In an industrialized software world where building gets cheap, simply building more is no longer much of a moat. Focus is.

John knew how to make a better shoe.
Thomas knew how to make more shoes.

The people who will survive, and even thrive, through this revolution may be the ones who know which one matters right now.
And can keep choosing before the lights go out.