The revolution, well paradigm shift rather, we are experiencing in AI has a likening with how industrial robots made a paradigm shift in the manufacturing industry in the 80-ies. Both when it comes to how it was introduced, the fears it raised, the mistakes “we” did utilizing the power and how the winners ended up using them.
Now, I’m old but in the 1980-ies I was 10 years old and more interested in playing games on my Vic 20, soccer and riding my bike (yes, it was a simpler life). But I have read a lot about this topic since this was when Toyota started to blow the competition out of the water. Also, my all time favorite book The Goal (by Dr Eliyahu Goldratt) has the robot revolution as part of the driver of the story and the problem picture.
In this post I wanted to dive a bit deeper in the likeness of industrial robots and AI tools and see what we can learn from them. I think that my analogy holds in many areas but to keep things a bit more tangible I will keep this to digital product development in the wider sense of the word, i.e. not only coding.
I have written two posts that relates to the topic, but you don’t have to read them to make sense of this post. I hope.
The industrial robot revolution
Industrial robots have been around for a long time as machines that do some of the manual labour for humans. You could view automated hammers, or spinning rocks as a kind of robots. The term itself was coined in the 40-ies but the real interest started in the 70-ies and during the 80-ies the real revolution started.
The manufacturing industry was, unsurprisingly, where the uptake was the biggest and especially in the car manufacturing industry the hopes for what they could do was immense. Talk was soon about “lights out” factories where no humans were needed, hence no lights. Just vast arrays of robots working in the dark with a prompt set of instructions from human given once.
It almost goes without saying that throughout the history of automation machines people doing that type of job has, rightly?, been fearing that the machines would take their job. This brilliant article summarizes these fears from the horseless carriages up to an important inflection point in the later 80ies.
The fear of losing jobs was real, but the effect took time to settle. My reading of it: early automation replaced individual tasks, and humans moved up to the work machines couldn’t do — verifying, monitoring, orchestrating. Economists Acemoglu and Restrepo (yes - an AI looked that up for me. I’m not THAT well-read) call these the displacement and reinstatement effects, and for decades they roughly balanced. What changed around 1987 wasn’t that we ran out of things for humans to do — it’s that the reinstatement side slowed down. Automation kept displacing, but it stopped creating as many new human tasks to compensate. Some of it was even what Acemoglu calls “so-so automation” — good enough to replace a worker, not good enough to make the whole system meaningfully more productive.
Mapping to the AI revolution
The AI revolution (again - scoping this to digital product development) follows in the same steps, where we first saw “simpler” tasks being replaced by autocomplete or code generation of tests etc.
Soon you could prompt an agent to write individual functions, classes or pages, but we saw a lot of hallucinations and needed to care a lot about HOW the code was written to actually trust that the hallucination was something we called good or bad. Remember, a LLM is always hallucinating. Sometimes it’s good, sometimes not. Or as Birgitta Böckeler puts it:
Hallucinations are the core feature of LLMs. We just call it “hallucinations” when they do something we don’t want, and “intelligence” in the cases where it’s useful to us.
At this point I was pretty sure that I would still write a lot of code, or at least work with it. I wrote a pretty big application by having Claude 3.5 (Haiku) generate sections of code for me. As I read what was generated I refactored it into a shape that I liked better. Refactoring is a great way to learn how code works.
This modus operandi changed for me with the advent of Opus 4.5 (Nov-Dec 2025) that I for the first time saw an AI model that could create a complete application with a single prompt. And the code it generated was actually pretty good. Especially when I started to nudge the code with system instructions, CLAUDE.md files and proto-harness setups.
Now my role as developer was to make the instructions to the robot agent clearer, and ensure that the orchestration of tasks was the correct one. And review the functionality - rather than the code. Yes. There, I’ve said it. I started to care less and less about the code and more and more about the harness and features.
This shift was further deepened with multi-agent, in the spring of 2026 setups that orchestrated themselves. Now my focus was solely on harness building, verification and orchestration.
The loud fear
There you have it. And no wonder the fear of losing jobs is real in our industry - we just took the journey from the 1920-ies to the inflection point in 1987 in less than a year.
Now, I’m the first to say that I still think that we will not lose (a lot of) jobs in the long run. Partly due to Jevons paradox that tells us that:
when technological improvements that increase the efficiency of a resource’s use lead to a rise, rather than a fall, in total consumption of that resource
but also that I have seen first-hand that the higher-level thinking about architecture, ways of working, principles of building applications etc. is still very much needed to turn a great idea into something that could be useful by more than one person. This knowledge is where digital product development skills will still be needed.
If you combine that with the Jevons paradox promise it means that we will have more to do, and do higher level tasks. That sounds promising to me. And then we haven’t even tapped into potential new roles that we can’t imagine yet, as the way we are using AI so far is very much moving human tasks to robots.
These are guesses, predictions and hunches. I might be proven wrong later. Call me out then. But learning to stay on top of things, adopting a curious and positive mindset will at the very least make the journey more enjoyable. More on this in another blogpost
The quiet fear - overproduction
But there’s another problem here, that is silently leading us astray and wasting a lot of potential and human effort; overproduction. Yes - the risk of us producing things that we do not need.
This seems counter-intuitive at first since the act of creating the application (designing the UI, writing the code, testing the app etc) has often been viewed as the bottleneck of our process. Sometimes that has been the right assumption to make too.
But, as I wrote in my blog post on throughput, a feature that never reaches a user is truly useless. It becomes, in terminology of theory of constraints, inventory and unfinished items taking up focus and attention in our process. Finished items for us, throughput, are things that makes an impact in the life of a user.
Let’s go back to industrial robot revolution and see how different companies approached the challenges and opportunities. Maybe we can learn something from them.
General Motors went all in on robots and wanted to create those fully-automated, lights out factories in the 80ies. Huge investments went into this effort and very little and some embarrassing (the famous “robot painted each other rather than cars”-episode) results were the outcome.
During this time Toyota also looked into using robots, and did so in a way that created an increase in both output and quality. Interesting, they approached robot adoption in a radically different way and used fewer robots where they mattered.
The difference is one of process management and improvement culture rather than the robots themselves. Toyota always built their automation on stable processes and capable people. The GM approach took all the tasks and replaced them with automation, regardless of if it is needed or not.
The GM approach creates pockets of overproduction that the bottleneck of the process cannot handle. The theory of constraint approach to solving this is instead to ensure that the bottleneck of the process is managed through the five focusing steps to produce real value. Just producing faster because we can is not really gain, and can in many cases create problems in the process.
This approach builds on the school of thought called Taylorism where we think that if we only could break down a job to its smallest tasks and then optimize each of them we will be more productive. If you have seen Modern Times by Charlie Chaplin, you have the picture clear in your head.
If you are now laughing about the stupidity of this approach, consider that Tesla also tried to create lights-out factories, failed and even the Musk said that “humans are underrated”.
There’s a wonderful apt picture from The Goal where the bottleneck machine (a heat-treat furnace, if I remember correctly) cannot even be seen due to all the work waiting for it to treat. All the upstream work created, including the fault and non-essential items, piles up in front of the bottleneck. And after the bottleneck the workers and machines are idle waiting for the items to be painted.
Are you GM or Toyota
Yes - we could learn something! I knew it!
It’s quite amazing that we with a single prompt can create a user story map, that we can one-shot Minecraft, or that our developers now are 10x from before. But, have we got 10x more value, have our users asked for a Minecraft clone or are our Charlie Chaplin’s being worked to the extreme by us automating the non-bottlenecks?
In short, are we GM and replace tasks blindly to make each step produce as much as possible just in case? Or do we take a lean / Toyota approach and add automation where it helps humans to produce value when it’s needed just-in-time?
Taiichi Ohno, creator of the Toyota Production system coined the term “autonomation” - automation with a human touch to capture how to utilize automation; where it is beneficial to the overall flow of value rather than just raw output.
Summary and in short
I think that the industrial robot revolution in the 70ies and 80ies have a lot of commonalities with where we are now in the AI revolution. I also think that we right now are making many of the same mistakes that those that failed with robot adoption. We do so since we are focusing on producing a lot of output and miss the mark of outcome and impact.