At Some Point, Manufacturing Started Looking Like One Giant Software System

When I first got a close look at manufacturing, one thing surprised me: it didn't feel as foreign as I expected.

Machines running. Steel plate stacked up. People welding, assembling, wiring. On the surface, nothing to do with the IT work I've done for years. But peel back one layer and it was strangely familiar. The whole factory started looking like one big piece of software.

I stopped seeing steel and started seeing flow

Take a single product.

A customer requirement comes in. You design it. You calculate the materials you need and buy them. You cut and machine the steel. You assemble the parts and run the wiring. You inspect, then you ship. In manufacturing they call this the production process.

Read the same line with a developer's eyes and it shifts.

Requirements → Design → Dependency resolution → Build → Assembly → Test → Release

The overlap with software development is uncanny. Raw materials and parts are Input. Each process step is a Function, and between steps there's an Interface. The finished product is Output, inspection is Test, a defect is an Exception. Work records and sensor data are Logs and Metrics. Process improvement is Refactoring.

Once that clicked, even watching people move around the floor felt different. Less "someone is carrying a steel plate," more "why does that plate need to be at that station at that moment?" I was reading Data Flow and Process Flow before I was reading people. Occupational hazard, I guess.

Manufacturing has APIs too

In IT you don't just bolt systems together. You pin down inputs and outputs and build an interface. The API is the obvious example.

Manufacturing has the same thing under a different name. When the output of one step moves to the next, there are conditions it has to meet. What the dimensions must be. What the machined surface should look like. Which materials travel with it. Which inspections have to be done already.

Define those loosely and the next step blows up. Developers know this scene. The interface contract broke.

Except on the floor, a lot of that interface is held together by people.

"We've always passed it over like this." "Just tell Kim at the next station, he'll know." "This model's a little different, so be careful."

As a systems person, that's a fascinating thing to watch. There's logic running in production that exists nowhere in the spec, and a human is remembering it.

A master technician might be a giant legacy system

That's where the thought went one step further.

Manufacturing has master technicians. People who've spent 20, 30 years in the same domain. They hear a machine and know something's off. They look at a plate and adjust the machining slightly. They handle small problems that aren't on any drawing, from experience.

Ask why they did it that way and you sometimes get:

"You'll know once you've done it."

Flip that around in IT terms and it gets interesting. A system that's had features bolted on for decades with thin documentation. Critical business logic scattered and hidden across the code. Nobody knows exactly how it behaves once the person who owned it leaves. We call that a legacy system.

Same thing happens in manufacturing. The logic just lives inside a person instead of inside code.

Which is how you get:

"That won't work without Kim."

Seen as a person, that's Kim being excellent at their job. Seen as a system, it reads differently. Part of what keeps the company running is tied to one individual. In IT that's a dangerous shape. Single point of failure.

Honestly, my first reaction was frustration. In IT I'd have gone straight at documentation. After watching a few more days I backed off. Believing you can move the judgment inside that person's head into a few pages of docs was the naive position, not the other way around.

Then AI showed up

This used to be a hard problem. You make them write a manual. You film video. You produce a work standard. That much is doable. Capturing the experience they can't even put into words is a different matter. That's tacit knowledge.

AI is starting to shake that loose. As video AI gets better, the behavior itself becomes data.

Which part they picked up first. What order they worked in. Which spot they checked. How long they waited. What made them deviate from their usual pattern.

Bolt on sensors and you get more. Pressure, torque, temperature, current, vibration, position, cycle time. Then connect the quality inspection result at the end.

And some of what lived only in someone's head turns into this:

Situation → Judgment → Action → Result

That structure matters, I think. AI isn't just learning how people talk anymore. It's starting to learn how people work.

Connect a robot and it's a different story entirely

Up to here, AI is only observing. Then the robot arrives.

Observe the human. Accumulate data. AI finds the pattern. Robot executes. Inspect the result, feed it back into learning.

The shape is simple.

Observe → Learn → Execute → Measure → Improve

Not far off the feedback loops I've watched in IT systems for years.

With one difference, and it's a big one. Software moves data. A manufacturing system moves matter. Cutting steel, drilling holes, assembling parts, connecting wire. It gets close to software that literally executes in the physical world.

So how I learn an industry changed too

A few years ago, understanding a new industry would have taken serious time. Learn the vocabulary, study the processes, ask people on the floor, dig through documents.

Floor experience still matters. AI doesn't substitute for physics or for time spent with your hands on the thing.

But one thing definitely changed. Mapping a new field onto the knowledge structure I already have got dramatically faster.

I hit a manufacturing term I don't know, I ask AI. I hear a process explained and convert it into system structure. Electrical phenomena connect to what I know from electronics; production process connects to software architecture. Sensors read as Observability, MES as a state management system, inter-process handoffs as Interfaces, defect analysis as Debugging.

At that point learning a new field isn't memorization from zero. It's closer to mapping a new industry onto an architecture already in my head. AI is a surprisingly good translator for that.

But manufacturing is not software

Here's where you can fool yourself. Understanding manufacturing like software and manufacturing being as easy as software are completely different claims.

You fix code and redeploy. Cut a plate wrong and there's no Ctrl+Z. Copying a program costs roughly nothing; a product consumes raw material. You roll a server back; a badly machined part sometimes goes in the scrap bin.

Manufacturing has safety, tolerances, material behavior, heat, electricity, and force sitting underneath it. Physics. The real world has no rollback.

Which is exactly why laying systems thinking over manufacturing is fun. You have to hold the software mindset and the physical constraints at the same time.

In the AI era, how we look at industries may itself change

I don't think AI's biggest power is finding answers for you. What lands harder for me is how much it dropped the cost of connecting knowledge across domains.

Electrical and electronics. Mechanical and manufacturing. Software and cloud. Data and AI. These used to look like separate expert territories. Step up one level and they converge on the same questions.

What goes in. What it passes through. Where state changes. Where things break. What to measure. How to get a better result.

Standing in front of manufacturing, I was asking exactly those questions.

So at some point a factory stopped looking like just a factory. It's a big system that takes Input, runs it through a pile of Processes, and produces Output in the physical world. As AI and robots attach to it, that system is becoming more observable, more of it persists as data, and there's room for it to search for better values on its own.

The factory of the future might be more than an automated factory. A single large software system that accumulates experience, executes, measures results, and corrects itself. That's how I started seeing manufacturing. How far this view holds up, I don't know yet.

Next time I want to read the process as architecture. Why process layout is the same problem as system design, and where the bottlenecks come from.