www.marcusoft.net – Learning by sharing since 2006

AI flow - Are AI our as robots? Hold on - haven't we been here before?

· August 3, 2026

Agile

Lean

AI

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.

What is throughput in our domain

Theory of constrains in an AI world

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...