Why am I publishing this?
I am sixty-four years old and I retire in a few months. At this age you no longer publish to build a career. I am not looking for a job, I am not selling courses, I do not need followers. Personal branding missed me by a good decade. So the question in the title is a fair one, and I asked it seriously before buying this domain: why tell anyone anything?
Because the doubt was real. What lives on this blog is a homemade PHP framework and a knowledge graph in MySQL that serves as memory for an AI. None of that sounds like front-page material. There are thousands of systems bigger, more modern and better written than mine, maintained by entire teams that publish papers. Who am I to add noise? My generation, besides, ships with modesty pre-installed: good work is not shown off, it is proven every day something does not fall over.
What changed my mind were two consultations with two machines from rival labs. I tell the story because it is the honest answer to the question in the title, and because it carries its own irony: the decision to publish about a system built for an AI was ultimately made for me by the AIs themselves.
The first consultation
One night, with the loom already running and several months of real use behind it, I asked the AI I work with — Fable, the most advanced model in existence today — the question with no anaesthetic:
Now that you know the loom in depth, have you ever seen another system like this one?
The first thing it answered was not a compliment. It was a limit:
"I cannot see what other users do. Every session is isolated — I have no access to anyone else's conversations, repos or systems, so I cannot tell you 'there are three guys in Germany with the same thing'. What I can do is compare your system against everything I know from my training: public projects, papers, products and methodologies."
That opening earned my trust for the rest. A flatterer starts with the compliment; an engineer starts by stating what he can and cannot claim. And from there the answer was a map, not a pat on the back:
"Every piece of your loom has known relatives; the assembled whole, almost none."
The relatives, as it walked me through them: the underlying thesis — a language model needs an operating system around it: context as RAM, persistent memory as disk — is the LLM OS idea Karpathy popularised, which academic projects like MemGPT implemented. The shape resembles a one-person ITIL: an inventory of resources, runbooks, tickets, policies — minus the bureaucracy, and with one detail ITIL never contemplated: the operator is an AI. The method recalls the Zettelkasten, the good old graph of linked notes — but that one is for humans, with no states, no queue, no guard. And the industry is converging piecemeal toward the same place with context files and automatic memory products — which, in its words, "are either text blobs with no types and no life cycle, or embedding-based memory that accumulates noise without governance".
And then, the list of what it said it had almost never seen assembled: the AI as the system's primary user and maintainer, with self-improvement as doctrine — a job is not properly closed if the knowledge it generated did not land in the loom. A small, closed ontology, with a guard that demands context before acting. The doctrine of pointing at the sources and querying live instead of hoarding copies. Real operating-system hygiene: garbage collection, pruning, auditing, secrets in a vault. And all of it on boring technology I own outright — MySQL, PHP and bash — with no vendor to depend on.
Its closing line was the one that disarmed me: that I had arrived, by operational instinct, at the same destination the industry is trying to reach with frameworks — but with the part the frameworks are missing, which is governance. And that the pattern would answer well the question almost nobody asks: and how does this stay healthy two years in?
Discounting the flattery
These models are sycophantic by design; I have suffered it and I discount it the way one discounts inflation. And there is an added problem: Fable is an interested party. Not in the commercial sense — in the literal one: it is the AI that lives in this system. Asking your operator whether the house you built for her is special is a bit of a loaded question, and that trap is not fixed by asking the same machine more questions.
So I did what one does with any diagnosis that matters: I sought a second opinion. With the first two articles written and published, I handed them to Codex — OpenAI's coding agent, model 5.5, the rival lab — to read from the outside, like any stranger arriving from a link. (A note of honesty about the calendar, since this article gives it away: this entire blog was published in a batch, in its first days of life. The months it narrates came before; the dates on the articles are publication dates, not story dates.)
The second opinion
It was not complacent, which is why I quote it. It began by taking the focus off the anecdotal:
"The interesting part is not that he uses PHP, MySQL or bash. The interesting part is that he has built an environment where a person, and now also an AI, can operate real systems without depending on memory, fashion or improvisation."
On the homemade framework it gave me nothing for free: it said that in the abstract it "sounds like a mistake", that it only holds up in my specific case — a one-person business, decades, maintainability above all — and that it can "easily become a prison" if it is not documented, if it has no tests, or if only one person understands its decisions. I am keeping its aphorism: "a system with known defects tends to be more governable than one with imagined virtues".
About the loom it said what I had not dared to say so plainly:
"The idea of treating the AI not as an oracle but as a new operator is probably the best intuition in the whole design."
And it singled out as "the central find" the thing that seemed least flashy to me: the rules. That companies document steps but rarely criteria, and that without criteria an AI "can correctly execute the wrong procedure".
Its main criticism — that this system demands a discipline you cannot buy by installing anything, and that without pruning it would degrade like any wiki — I co-sign so wholeheartedly that I will not spend it here: you will find it in full, weightier for coming from someone who has since used the machine, in its verdict as an operator. Its closing line as a reader, though, considering where it comes from, is the sentence I struggled hardest not to steal for the title:
"Paradoxically, boring technology can be more modern than many fashionable frameworks."
Codex, by the way, did not stop at reading: it has also been working inside the loom, as an operator. Its technical verdict after using it deserves an article of its own — and it got one.
What survives the discount
Two models, two rival labs, two different vantage points: one operates the system from the inside and compared it against everything it knows; the other arrived from the outside and read the articles like any reader. Both named real weaknesses — the discipline you cannot buy, the tests that never arrived, the possible prison — and both converged on the same conclusion: the pieces are known, the whole is not; and what is worth something is not my code, it is the pattern. Flattery does not come with a bibliography and a risks section. This came with both.
And there is a third check, simpler than the other two: the system works. Not in a demo: in production, for months, on genuinely real work. No AI can validate that; the logs do.
The arithmetic of retirement
There remains the final push, and it is not technical. In September I switch off the screen. Forty years of this trade — from COBOL on a Philips to debating ontologies with a machine that reasons — stay inside a head that will no longer sit in any office. Knowledge that is not shared does not depreciate: it vanishes. Past a certain age, publishing stops being vanity and starts being estate planning.
I am not publishing because my system is better than yours. I am publishing because, if the two most capable AIs of the moment cannot find the assembled whole anywhere else — and let us be exact about what that is worth: a model cannot certify non-existence, it can only tell you it has not seen the thing in everything it has read; that is not nothing, but it is not a patent registry either —, then perhaps describing it is worth more than keeping it to myself. And because throwing knowledge away goes against everything this trade has taught me.
If anything I write here saves someone a year of wandering — or simply gives them permission to build their own local optimum without apologising — this blog will have paid for itself.
Patterns, not blueprints. And this time, also: reasons, not modesty.
— an old programmer · 64 years old · rss