{"slug": "are-ai-agents-our-industry-s-industrial-robots", "title": "Are AI agents our industry's industrial robots?", "summary": "AI agents in digital product development are following the same adoption curve as industrial robots in the 1980s, according to a blog post by Marcus (marcusoft.net). The post draws parallels between the fears, mistakes, and eventual winners in both revolutions, citing economists Acemoglu and Restrepo's displacement and reinstatement effects, and notes that around 1987 the reinstatement side slowed down, leading to 'so-so automation.' The author argues that AI tools, like early robots, initially replace simple tasks but require careful oversight to avoid hallucinations and ensure quality.", "body_md": "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.\n\nNow, 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)](https://www.marcusoft.net/2014/12/what-is-the-goal.html) has the robot revolution as part of the driver of the story and the problem picture.\n\nIn 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.\n\nI 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.\n\n## The industrial robot revolution\n\nIndustrial 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](https://en.wikipedia.org/wiki/Industrial_robot#History) but the real interest started in the 70-ies and during the 80-ies the real revolution started.\n\nThe 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](https://www.automate.org/robotics/blogs/the-history-of-robotics-in-the-automotive-industry). 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.\n\nIt 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](https://medium.com/timeline/robots-have-been-about-to-take-all-the-jobs-for-more-than-200-years-5c9c08a2f41d) summarizes these fears from the horseless carriages up to an important inflection point in the later 80ies.\n\nThe 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](https://www.bu.edu/econ/files/2019/05/JEP_automation_March_29_nber.pdf) (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.\n\n## Mapping to the AI revolution\n\nThe 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.\n\nSoon 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](https://martinfowler.com/articles/exploring-gen-ai/i-still-care-about-the-code.html) 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:\n\nHallucinations 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.\n\nAt 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](https://en.wikipedia.org/wiki/Code_refactoring) is a great way to learn how code works.\n\nThis 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`\n\nfiles and proto-harness setups.\n\nNow 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.\n\nThis 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.\n\n## The loud fear\n\nThere 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.\n\nNow, 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](https://www.youtube.com/watch?v=a6sYYrLTOjQ) that tells us that:\n\nwhen 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\n\nbut 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.\n\nIf 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.\n\nThese 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](https://www.marcusoft.net/2026/03/navigating-uncertainty-ai-edition.html)\n\n## The quiet fear - overproduction\n\nBut 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.\n\nThis 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.\n\nBut, as I wrote in my [blog post on throughput](https://www.marcusoft.net/2026/07/ai-flow-throughput.html), 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.\n\nLet’s go back to industrial robot revolution and see how different companies approached the challenges and opportunities. Maybe we can learn something from them.\n\nGeneral Motors went all in on robots and wanted to create [those fully-automated, lights out factories](https://www.leanblog.org/2016/06/gm-toyota-automation-failure-lean-lessons/) 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)](https://fortune.com/2025/09/03/case-study-mit-general-motors-toyota-1980s-artificial-intelligence-lesson/) results were the outcome.\n\nDuring 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.\n\nThe 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.\n\nThe GM approach creates pockets of overproduction that the bottleneck of the process cannot handle. The [theory of constraint](https://www.marcusoft.net/2026/07/ai-flow-toc.html) approach to solving this is instead to ensure that the bottleneck of the process is managed through the [five focusing steps](https://www.marcusoft.net/2026/07/ai-flow-toc.html#theory-of-constraints) to produce real value. Just producing faster because we can is not really gain, and can in many cases create problems in the process.\n\nThis approach builds on the school of thought called [ Taylorism](https://en.wikipedia.org/wiki/Scientific_management) 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.\n\nIf you are now laughing about the stupidity of this approach, consider that [Tesla also tried to create lights-out factories](https://www.fastcompany.com/40559386/elon-musk-says-humans-are-underrated-after-his-robots-slow-model-3-production), failed and even the Musk said that [“humans are underrated”](https://x.com/elonmusk/status/984882630947753984).\n\nThere’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.\n\n## Are you GM or Toyota\n\nYes - we could learn something! I knew it!\n\nIt’s quite amazing that we with a single prompt can create a user story map, that we can [one-shot Minecraft](https://www.hanselman.com/blog/the-danger-of-glamourizing-one-shots), 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?\n\nIn 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?\n\nTaiichi Ohno, creator of the Toyota Production system coined the term [“autonomation” - automation with a human touch](https://en.wikipedia.org/wiki/Autonomation) to capture how to utilize automation; where it is beneficial to the overall flow of value rather than just raw output.\n\n## Summary and in short\n\nI 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*.", "url": "https://wpnews.pro/news/are-ai-agents-our-industry-s-industrial-robots", "canonical_source": "https://www.marcusoft.net/2026/08/ai-robots.html", "published_at": "2026-08-10 07:13:26+00:00", "updated_at": "2026-08-10 07:46:36.761684+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools"], "entities": ["Toyota", "Dr. Eliyahu Goldratt", "Acemoglu", "Restrepo", "marcusoft.net", "Vic 20"], "alternates": {"html": "https://wpnews.pro/news/are-ai-agents-our-industry-s-industrial-robots", "markdown": "https://wpnews.pro/news/are-ai-agents-our-industry-s-industrial-robots.md", "text": "https://wpnews.pro/news/are-ai-agents-our-industry-s-industrial-robots.txt", "jsonld": "https://wpnews.pro/news/are-ai-agents-our-industry-s-industrial-robots.jsonld"}}