The AI doesn't trip twice on the same stone
A reader of this blog recently asked me two questions that left me thinking. The first: when did I decide the loom was not a tool, but a legacy? The second: what has surprised me about the system — something I did not plan, something it did on its own without me having foreseen it? And he added a premise I co-sign: systems that last always end up doing something their creator never imagined. It tends to be the sign that they are alive.
The first question I cannot answer with a date. The second one I can. And the answer fits in a proverb.
The proverb
The Spanish saying goes that man is the only animal that trips twice on the same stone. Forty years in this trade back me up: I have tripped on some stones so many times that I greet them by name.
Classic software is even worse. A program does not trip twice: it trips infinitely many times, in exactly the same way, on exactly the same stone, until someone comes and moves it out of the way. That is its nature: it does what is written, and if what is written fails, it fails forever with the punctuality of a clock. Half this profession makes a living from that.
And then there is what has surprised me about the loom: the AI working inside it trips once. Just once.
The NAS that kept moving house
A real example, small and perfect. There is a NAS in an office. I declared it in the loom as a resource, with its card: what it is, how to reach it, its IP. So far, documentation as old as the trade.
But the NAS got its IP over DHCP. And one day the router decided to move it to a different number. The AI went after it following the card, knocked on the usual door... and nobody lived there anymore.
A classic system breaks right there and waits to be fixed. A rookie operator opens a ticket. What happened instead was this: among the loom's rules — its constitution, the one the guard puts in front of the agent before any work — there was a line that said, in essence: if you cannot reach a resource by its IP, look it up by its MAC; IPs are volatile, the MAC is the anchor. The AI read the rule, swept the network, found the MAC, recorded the new IP and went on with its job. I found out afterwards, reading the logbook. Total: a few seconds. My involvement: none.
Before anyone pictures an agent roaming loose at 3 a.m.: this was a session I had started for another assignment, the sweep was a read-only diagnostic on my own network — a plain old arp —, and correcting a resource's card is not one of the actions that require my signature. Within those seams, "none" is exactly the involvement I want: the routine should not need me.
Who wrote the rule?
Here comes the part I actually want to tell, because it is the most honest one. The first time a DHCP gadget left us stranded, the rule did not exist. Someone wrote it as a result of that stumble. Who? Maybe I said it. Maybe the AI proposed it and I approved it. The truth: I do not remember.
For days that doubt bothered me — an old programmer wants to know who signed every line. Until I understood that the doubt was the news. When you can no longer tell which part of the system you put in and which part the machine found, the boundary has gone blurry. And that blurry boundary has a less unsettling name than it seems: it is called a shared working environment. The same thing happens with a human colleague — after enough years, nobody remembers whose idea it was. It belongs to both. It belongs to the workshop.
What I do know is what happened next, and that is the important part: from then on it does it alone. And not just with that NAS — with any resource that goes into hiding. The rule did not say "the NAS at such-and-such office": it stated a principle. The machine generalises it: today it applies it to gadgets that did not even exist when the rule was written.
What this is and what it is not
Let nobody drift into mysticism: this is not the model "learning" in the data-science sense. The model does not change a single neuron. What exists here is older and more robust: an engineering feedback loop. Something fails; judgement — human or machine, it no longer matters — finds the way out; the way out gets written down as a rule with its verification; and the guard puts it in front of whoever walks that path again. Next time, the stone is still there, but it is no longer on the road: it is in the logbook.
The mechanism has three parts and none of them is intelligent on its own: a structured memory where experience fits without rotting, a discipline that forces failure and fix to be written down before a job may close, and pruning that keeps dead rules from burying the living ones. The intelligence is supplied by whichever model is on duty. The wisdom — if I may use the word — keeps accumulating in the loom.
That is why every stumble is worth money. A failure used to be a cost: lost hours, a waiting client. Now a failure is an investment with a single instalment: you trip, you write it down, and that particular stone never charges you again. The system gets smarter every time somebody uses it well — and that is the difference between maintaining a program and tending an orchard.
The answer to the reader
So this is my answer to the second question: what I did not plan, what the system did on its own, was to stop needing me for the stones already known. I designed a memory; I did not design the anticipation. It appeared once the memory held enough experience and a discipline kept it clean. If that is being alive, then the reader was right.
And the first question — when did it go from tool to legacy? I suspect the answer is this very thing. A tool saves you hours. This no longer saves me hours: it lets me do what I could not do before, and — here is the legacy — it will still know how to do it when I am no longer around to remember why the rule said what it said. The stones I tripped on for forty years are written down, each with its way out beside it.
Man is still the animal that trips twice on the same stone. Yours truly, first in line. But I have achieved something that consoles me for all the stumbles: I work with someone who doesn't.
— an old programmer · 64 years old · rss