Here’s an unpopular opinion from someone who helps companies adopt AI for a living: many AI projects I see today shouldn’t be AI projects at all. It’s like using a nuclear bomb to kill flies. It works, but it’s expensive, and very often it’s simply the easy way out.
I didn’t come to this conclusion in a meeting room. I came to it in front of a loom built two hundred years ago, which was reading a program punched into cardboard.
I was in Żyrardów, a small town west of Warsaw, during an integration trip with Biznes Klub Polska. BKP is a business club that helps its members with business, but it also takes them to really inspiring places. This time it was the Museum of Linen Industry, located in the halls of an old flax factory. I expected a nice afternoon with some local history. I left with one of the best arguments about automation I’ve heard in years.
A program written in cardboard
For anyone who has ever written code, the main attraction of the museum is the Jacquard loom.
Around 1804, Joseph-Marie Jacquard solved a problem that had kept master weavers busy for centuries: complex patterns. Before him, weaving a detailed pattern needed a skilled weaver and an assistant who lifted the warp threads by hand, row by row. Jacquard moved this knowledge from people’s heads onto a chain of punched cards. One card was one row of the pattern. A hole, or no hole, decided if a given thread went up or stayed down.
In other words, Jacquard separated the program from the machine. You change the cards, and the same loom weaves a different pattern. Binary logic, stored instructions and reusable hardware, more than a hundred years before the first electronic computer.
People who came later noticed it. Charles Babbage planned to use punched cards for his Analytical Engine, and Ada Lovelace wrote that “the Analytical Engine weaves algebraic patterns, just as the Jacquard loom weaves flowers and leaves”. Later, Herman Hollerith used punched cards to process the 1890 US census. The count took six months, while the 1880 census had taken more than eight years to complete (IBM history). His company later became part of IBM. The cards in Żyrardów are distant relatives of the device you are reading this on.
But the Jacquard loom was not intelligent. It was dedicated. It did one job, it did it the same way every time, and it was very hard to get it wrong. Keep this in mind, because it’s the main point of this article.
From a field to fabric
The loom is the star, but the whole process behind it impressed me even more.
Making linen takes a very long time. Flax is sown, and then pulled out of the ground instead of cut, so the fibres stay long. Then it is retted, which means it is left to partly rot so the fibres come away from the stem. Then breaking, scutching and hackling slowly turn a hard plant into soft, combed fibre. Only after that can it be spun, woven, bleached and finished. Each step has its own tools, its own problems and its own experts.
Flax was also very hard to spin by machine. In 1810 Napoleon offered one million francs to anyone who could build a flax spinning machine. A French engineer, Philippe de Girard, built one, but he never got the money, because the Empire fell first. He later came to Poland, and the factory town built around his technology still has his name: Żyrardów comes from Girard.
Looking at it as an IT consultant, I was struck by how this process was automated. Nobody tried to build one universal machine to “do linen”. Each step got its own solution, built for that one job and connected to the next step in a clear, predictable way. Today we would call it a chain of specialised, deterministic components. Or simply good architecture.
The machine that knew when to stop
The automation went further than I expected. Some machines handled their own failures.
At the end of the 19th century, the Northrop loom stopped when a warp thread broke, and when the shuttle ran out of thread, it replaced the empty bobbin with a full one without stopping. Thanks to this, one operator could run 16 or more looms instead of eight.
In 1924 Sakichi Toyoda in Japan finished his Type G automatic loom. It had a device that stopped the machine as soon as the weft thread broke or ran out.
This small device became a whole philosophy. In Japanese it’s called jidoka, often translated as “automation with a human touch”. The machine should notice a problem and stop, instead of quietly producing defects. Toyota’s own history says that thanks to this device, nobody had to watch the machine all the time, so one worker could run several looms. Jidoka later became one of the two pillars of the Toyota Production System, and so of lean thinking.
Long before anyone spoke about observability, guardrails or human-in-the-loop, engineers built machines that knew their limits. The machine didn’t try to fix a broken thread in some creative way. It stopped and called a human. Success was predictable, and so was failure.
Let’s not romanticise it
I want to be fair here, because it’s easy to get nostalgic in a nicely restored factory hall.
Work in factories like the one in Żyrardów was extremely hard. Self-stopping machines didn’t free people from the factory floor. They let one person look after more machines. As our guide at the museum told us, one weaver supervised six to eight looms at the same time. She walked between them for the whole shift, in the noise, heat and humidity that linen needs, and reacted every time one of them stopped. Automation and very hard human work existed together.
So the lesson is not that the industrial age was a golden age. The lesson is smaller and, I think, more useful: even when there were plenty of cheap workers, engineers still asked how to make the process itself reliable. Cheap labour was not an excuse to skip the engineering.
We still speak weaving
There is one more thing I kept noticing during the visit: how much of our everyday language, and of IT language, comes from this world.
In Polish, the word “wątek” means the weft, the thread that goes across the loom. The same word is used for a thread in software, a thread on a forum and the plot of a story. When Poles tell a long story, we say “snuć wątek”, which means to spin out a thread. English works in a very similar way. You can lose the thread of a conversation, start a new thread on Slack, or run code in many threads at the same time.
And it goes deeper. The words “text” and “context” come from the Latin texere, to weave. The same old root, meaning “to weave” and also “to fabricate”, is behind the word “technology”. Even the “line” in “a line of code”, “online” or “pipeline” goes back to the Latin word for linen thread, from linum, flax. The same plant they processed in Żyrardów. Then we have the web, the network, the data fabric, and systems that are “woven together” from many parts.
Some of these words are thousands of years old, others came with computers. But they all show the same thing: for a very long time, weaving was how people thought about structure, order and connecting small pieces into something bigger.
We kept the words. But I think at some point we lost the habit behind them.
Why did we stop thinking like this?
For decades many companies solved process problems by adding people. Cheap labour, outsourcing, offshoring. If a process was messy, you hired someone to deal with the mess. Copying data from system A to system B, checking invoices against purchase orders, typing the same information into three applications. It worked well enough, so nobody fixed the process underneath.
Now we have a new and much more impressive way to avoid fixing the process: put AI on top of it.
Don’t get me wrong. AI is a great tool and I use it every day. But more and more often I see companies using large language models for tasks that have one correct answer, clear rules and structured data. In other words, tasks that are basically a punched card. They pay for a probabilistic system to do something that a deterministic one would do faster, cheaper and more reliably. And then they are surprised when the model is right 97% of the time and fails in strange ways the other 3%.
A Jacquard loom never “hallucinated” a flower. It wove exactly what was on the cards.
Many business processes today could still be solved with classic automation: a good integration, a rules engine, a simple script or old-school RPA. It’s not something you show in a keynote, but it works every time.
AI as a bridge, not a destination
That doesn’t mean AI has no place in automation. Often it is a very good first step.
When a process is poorly understood, lives only in people’s heads and is full of exceptions and unstructured data, AI helps you start quickly. It can deal with the mess while you learn how the process really works. It can show you which decisions need judgement and which are just rules nobody wrote down. It can be your prototype and your discovery tool.
But scaffolding is not the building. Once you understand the pattern, it is often worth turning it into something dedicated: a script, an integration, a classic automation with clear rules and a clear stop when something unexpected happens. In many cases AI is part of the road to a reliable system, but it’s not the place where you should stay.
A framework I use a lot here is Incremental Determinism, described by Mike Taylor in his article “You Are the Most Expensive Model” on Every. The idea is simple: each time you repeat a task, move it closer to being deterministic, which means code that always gives the same output for the same input. You start with an AI chat, turn it into a reusable skill, add tests that check quality, and finally replace the model with scripts wherever intelligence adds no value. You keep the expensive intelligence only for the parts that really need judgement, like interpretation, tone or unclear decisions.
The key question of this framework is one I’d like every team to ask before starting an AI project: how much intelligence does this task really need? Usually the answer is: less than we think.
The loom test
Before reaching for AI, it helps to run a quick check. Let’s call it the loom test:
Does the task repeat? If it happens hundreds of times a month in the same form, it deserves a dedicated solution, not a clever prompt.
Is there one correct answer? If yes, you want determinism. Randomness can help in creative work, but in accounting it’s a bug.
Is the data structured? If the data is already in a system, connect the systems. Don’t ask a model to read screenshots of them.
What happens when it fails? If an error should stop the line, like in Toyoda’s loom, you need predictable failure, not a confident wrong answer.
Does it really need judgement? If the task needs context, interpretation or weighing options, this is where AI, or a human, is worth the cost.
If most answers point to repetition, rules and structure, you are probably looking at a punched card, not at a problem that needs intelligence.
Back to Żyrardów
Standing in that factory hall and listening to a working Jacquard loom, I kept thinking how modern it all felt. Program separated from hardware. Specialised parts in a long process. Machines that detect their own errors and stop. One person supervising many automated machines. We describe our best systems today in almost the same words.
The engineers who built these machines didn’t have AI. They had something we sometimes forget to use: the patience to understand a process well enough to make it reliable.
AI is a powerful new tool, and I’m really excited about what we can build with it. But a tool this powerful makes it tempting to skip the hard thinking and throw intelligence at problems that only need some good engineering.
So my question to you is: what in your organisation could be a punched card instead of a prompt?