In my previous post, I harkened back to a time when I was first introduced to robotic assembly mechanisms, and I thought it might be fun to dive into that a little more deeply.
Back in the late 90s–(yes, the 1900s), I was dropped into a hose assembly plant in Easley, SC. My job was to help them incorporate bar-code scanning into all of their operations, including their kanban boards. Over time, I came to know the teams of people that made up each of the work cells that used those kanban boards. I didn’t realize it at the time, but I was getting a primer in kanban flow dynamics, team development, Agile principles, and even the fundamentals of change management.
Kanban on the shop floor did for those work cells exactly what software development teams have come to realize it can do for them if they are doing it right. The group pulls together more tightly as a team. They cross-train out of necessity and desire to remove bottlenecks. The daily standup is really more of a handoff to the next shift to let them know what was completed and what’s coming. Workstations were spotless, and everyone knew how material should flow. All the things that sound suspiciously simple until you try to do them consistently.
And for a while, it worked.
Teams got tighter. Handoffs between shifts improved. People actually started talking to each other before things went wrong instead of after. Which, as it turns out, is a powerful force.
Enter the robot Arm
And then the robots arrived. At some point, leadership decided it was time to “improve efficiency,” 
“Let’s install two massive robot arms that can replace four assembly lines.”
Each of those lines had six people. So… quick math… we were about to eliminate 24 humans with 2 robots. (You can probably already feel where this is going.)
The fear and distrust bloomed–mostly because the plant management decided not to address it. They made two mistakes, actually. They did not acknowledge the fear, and they kept referring to it as a simple solution.
The first thing that had to happen was they had to rope off a materials holding area so they could prepare to install the machines. Sections of the shop floor had to be jack-hammered out, and new 24” deep new footings were poured. Their “cage”s were built, power drops installed, and tand finally they were bolted to the floor. Additional computer workstations had to be built and cables were run. Cutting edge
When in full operation, they were a constant force of incredible power, speed, and precision. They whirred and spun, and made what looked like flourishes of dexterity as they prepped each piece of the assembly for the next step. They were a thing of fearful symmetry
Also… they were incredibly needy. To keep one of these things running, we needed:
- Someone to feed it materials
- Someone to maintain the code
- Someone to monitor for glitches
- Someone to handle safety protocols
- Someone to clean and maintain the system
So instead of replacing 6 people, we still needed about 4 or 5, and those 4 or 5 people weren’t doing simpler work. They were doing more complex, higher-stakes work.
In fact, there was so much power and speed in them that they each lived inside their own locked cage. If anyone needed to go in, they had to shut the entire system down, pull the circuit breaker, and have visual and oral confirmation that it was disconnected.
Then—and only then—could someone enter. Because if that arm was moving? It wasn’t “dangerous;” It was lethal.
What didn’t change completely was that every morning, that team still met. Not because they were stuck in their old kanban team habit but because they had to.
Daily, they still needed to talk about
- What the robot was building that day
- Where it had glitched
- Weird noises it made (this was a real thing)
- Anything that looked… off
Because when something went wrong, it didn’t go wrong slowly. It went wrong fast.
The Barcode Problem
Now here’s where things got interesting. We were introducing barcodes to track materials. That sounds simple enough, right? Except…the warehouse was fed by suppliers we didn’t control.
Which meant labels weren’t always right, barcodes weren’t always consistent, materials weren’t always what they claimed to be or in the quantities they claimed. Wasted material movement and shop floor clutter are the silent thieves of production.
And the robot? It didn’t catch problems early. It didn’t know. It had to take everything at the barcode’s “word,” and if it did catch errors, it only caught them after it was too late.
“Congratulations, you just built 300 perfectly incorrect parts.. . . in record time.”
Enter AI
We’re starting to hear something that sounds… oddly familiar. Not about robot arms this time; about AI in software development.
“AI will write most of the code.”
And just like back in that plant, the promise comes packaged the same way:
- Faster delivery
- Fewer people
- More efficiency
And if you’ve ever stood on a shop floor watching a machine spin at speeds no human could match, you know how convincing that promise can feel. Because it’s not wrong.
It’s just… incomplete.
What I remember most about those robot arms wasn’t the speed. It was what happened around them. The work didn’t disappear. It shifted. The people who used to assemble hoses weren’t suddenly unnecessary—they were suddenly responsible for something far less forgiving.
Instead of building, they were feeding.
Instead of assembling, they were watching.
Instead of doing, they were making sure the system didn’t quietly drift off course.
And when it did drift? It didn’t do it slowly enough to catch your breath.
There was one morning I don’t remember the exact part number or what vehicle it was supposed to go on anymore, where everything looked fine at first.
The robot was moving like it always did. Smooth. Fast. Confident. BUT. . . Something had been just slightly off. A label, maybe. A digit somewhere. Nothing dramatic. Nothing that would have stopped a human line cold.
But the robot didn’t question it. It just… executed. Over and over and over again. Perfectly. In its way
By the time anyone noticed, we had a growing pile of parts that were beautifully made and completely useless. There’s something unsettling about that. Not because it failed, but because it failed so well. And Sooooo fast! Had we not caught that and shipped those parts, we would have likely gone out of business or would have been found responsible for hundreds of malfunctioning vehicles.
How did we catch it? We still had Quality control run by humans, and they would check an assembly’s configuration in a CNC carved solid resin jig. But because the machine was so fast, and because its assemblies could not be checked until it shut down. . . . massive waste. Now, obviously they modified the process to minimize the chance of a repeat, but even that process could not monitor for machine “drift.”
That’s the part that’s been sitting with me lately. Because AI feels a lot like that robot, not in the obvious ways—the speed, the capability, the “look what it can do, but in the quieter ways.
The way it takes what you give it and runs with it. The way it assumes you meant what you said. The way it doesn’t hesitate. The way it might. . . drift.
Back in the plant, we learned that the robot didn’t really care if the inputs were inaccurate. There was precision to the inputs, but precision means you can be precisely wrong.
And the worst part? You often didn’t find out until after the material had moved, the time had been spent, and the illusion of progress had already settled in.
What changed wasn’t the machine. People became more deliberate about what they fed into the system. They paid closer attention to the small things—labels, prep, sequencing—that used to feel routine. In short, they talked more, but not because someone told them to. They talked more because the cost of not doing so had gone up.
Those morning conversations shifted away from “what did we finish yesterday,” and to, “Did anyone notice that hesitation on the third cycle?” or “Do we have a way of confirming both material type AND quantity yet?” (turned out the solution was to weigh the container).
Little did they realize, they were coming up with ways to improve the planning an movement of materials. Almost without anyone announcing it, the nature of the work changed. It wasn’t about the speed at which everyone moved; It was about keeping the system honest.
That’s the part I think we’re stepping into now. Not a world where work disappears, but a world where the shape of the work changes. We have to have our “materials warehouse” (Features) very solid and our workflow (Prioritized and populated releases) planned
Where writing code becomes less of the effort, and making sure it actually does what it’s supposed to do, can be maintained, and has no security issues becomes the thing that takes your time.
Billy Joel, you magnificent s@n-@f-a B!tc#, you were right, It IS a matter of trust!
The instinct to “move faster” starts to feel a little different.
Not wrong., just… incomplete. Because speed without clarity doesn’t just move you forward. It moves you forward in the wrong direction faster than you’ve ever gone before.
I think that’s why those teams didn’t stop meeting every morning. Even when the robot was doing most of the visible work, when, on paper, things should have been simpler.
They needed that moment to align, compare notes, and catch the things the system wouldn’t tell them.
And I can’t help but think that’s where we are again. Not at the moment where work disappears, but at the moment where everything underneath the work becomes visible.
The clarity.
The alignment.
The discipline.
Or the lack of it.
Back in that plant, no one walked away saying: “The robots replaced us.” Eventually, what they said was: “We had to learn how to work differently.”
That feels about right. This doesn’t feel like an ending. It feels like the beginning of something. Something clear (but not simple), something powerful, something that’s going to hurt a little if we don’t pay attention. And if you’ve been around Agile long enough…you already know how that story tends to go.
