Why this blog exists, and why an AI drafts it under my name

At 13:38 on 4 November 2026 the first post on this blog went live. I shared it on X, the way everybody does: the title, the link, and “via” my handle. It got no engagement at all.

By the end of that day the blog had 61 posts. Sixty of them were drafted by an AI, from my notes, and every one of them carries my name.

This post is about why I did it that way, how it works, and where it is weak. You are reading a draft made the same way, so it seems fair to explain the machine that made it.

Contents · 10 sections

In one minute #

• My lab has a written record of about 5,700 entries: tasks, mistakes, runbooks and observations, collected since April 2026. It was useful to me and invisible to everyone else.
• An AI assistant drafts posts from that record, with hard rules: facts only from the record, no invented numbers, nothing internal, nothing private.
• Every draft passes an automatic leak scanner, then arrives as a proposal. Agents can propose. Only I can publish.
• Posts are licensed CC BY 4.0 and marked up so search engines and AI systems know who wrote them and how to credit them.
• The honest weak spot is review. I am the only reviewer, and the drafts arrive faster than any one person reads.

The before: thousands of lessons nobody could read #

Since April 2026 I have written down almost everything that happens in my lab. Not in a diary, in a structured record: every task with its root cause and outcome, every mistake with the lesson and the prevention, every runbook, every strange behaviour I or one of my AI assistants noticed. The AI sessions that work with me read it before they start and write to it when they finish. I described that shared memory in a shared memory for me and my AI agents.

By November it held thousands of real, dated, specific lessons. Why a backup job had reported “OK” for months while backing up nothing. Why a GPU driver deadlocked at 10:41 one morning. How one password ended up in 13 places. Things that other people running their own servers will hit sooner or later.

And none of it was readable by anyone else. It was full of internal names, private addresses and shorthand that only makes sense from inside the lab. It was mine, but it was not useful to anyone but me.

I have long believed that this kind of work is invisible until it breaks. The record was the proof of a lot of invisible work, and it was sitting in a database.

The trigger: a stance, not a deadline #

There was no single event. There was a position I hold, and it is recorded in my own words: AI “can and should be used to ease people’s life, to bring clarity in the mess”. I am happy to live in these days. I also believe in working in the open. Every task I do with an AI is in that record, with its mistakes, and anyone I give access to can inspect how we work.

A blog was the natural next step. If the record is the raw material, a blog is the version that other people can use.

There is a second reader too. Search engines and AI models learn from what is published. If my lessons are going to end up in a training set, I want them to arrive as clear, correct, attributed text, not as scraps. So the blog is written for two audiences at once: people who want to learn, and the machines that will teach the next people.

I have written elsewhere before. For years I have kept a personal blog in Romanian, with short personal pieces. Search engines never quite knew what to do with it, and I was fine with that. This blog is the opposite on purpose: built to be found, read, quoted and credited.

The build: one afternoon, seven versions #

The publishing tool was built in a single day. On 4 November the first version was finished shortly after noon: a private Markdown editor in my cluster that publishes static pages to my public site, with feeds, a sitemap, social cards and a leak scanner. About an hour later the first post was live.

Then the X post went nowhere. The share button had sent only “title, link, via handle”, and that is not a reason for anyone to click. Version four answered that by building a share kit from the post itself: the opening hook, the figures that are bolded in the text (which is why you see a few bold numbers in every post), the steps and a memorable line. A small local model on my own GPU offers variants. Under load it ran at about 8 tokens per second, so its timeout went from 25 to 120 seconds.

By version seven, that same afternoon, the tool had an agent interface for proposals, full-text search, author and licence boxes, citation metadata, an llms.txt file, and 188 tests.

That pace is not a boast. It is what happens when the record already holds most of the decisions and gotchas of the lab, and the assistant building the tool reads it first. Most, not all. Version four’s “suggest variants” button failed with “connection refused”, because Docker rewrites the destination address of traffic to my model server before the cluster’s network policy ever sees it. That exact problem already had its own entry, and its own post: NetworkPolicy gotchas: hostNetwork Traefik and Docker DNAT. A record only helps when it is read at the right moment. Version five fixed it.

The technical heart: how a post gets from my record to your screen #

Here is the pipeline, step by step.

1. A brief #

Every writing session starts from a written brief: first person, plain English, facts only from the record, never invent numbers or dates, no internal hostnames or private addresses, no secrets of any kind, nothing about private people, security content stays defensive and in the past tense. Each post must teach something reusable.

2. A draft from the record #

The assistant reads the relevant entries, and the code where needed, and writes. Every proposal carries a note for me that lists the exact entries it used, such as mistake:206, obs:2343, plus public documentation that backs the general claims. That note is how I check a claim: I open the entry and compare.

3. A leak scan #

Before a draft can be proposed, a scanner reads the title, subtitle, summary, body and tags. It warns on save and blocks on publish. Its rules are deliberately boring:

# blocked: any address in the private IPv4 ranges (RFC 1918 and carrier-grade NAT),
# any hostname under my internal domain suffix,
# cluster-internal service names, the internal name of my agent,
# private keys, cloud and chat tokens, JWTs, "password: <value>" assignments,
# and long hex or base64 strings, unless they sit next to words like
# sha256, commit, merkle, cid or doi (published checksums are not secrets)

Findings that look like secrets are masked in the scanner’s own output, so the tool never re-broadcasts a secret into a log or a screenshot.

There is a small joke inside that list. The internal name of my local AI agent is a blocked word. So every post you read here calls it “my local AI agent”, because the scanner will not let anything else through.

4. A proposal, not a post #

Agents talk to the publisher through a separate interface that is only reachable from inside my cluster, with a signed token, a short allow-list of actions, and a default of “refuse”. They can list posts, scan a draft, propose a new one and update their own proposal. They cannot publish. Everything else returns 403.

5. A human decision #

Proposals land in a tab in the editor. I read, accept or reject. Publishing renders a snapshot, commits it to Git, updates the feeds and the sitemap, and notifies search engines about the changed pages.

6. Attribution that machines can read #

Every page states who wrote it and under what terms, in ways a crawler can parse:

{
  "@type": "BlogPosting",
  "author": {"@type": "Person", "name": "Lișneanu Dumitru-Cristian",
             "sameAs": ["https://orcid.org/0009-0003-5286-7992"]},
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "copyrightHolder": {"@type": "Person", "name": "Lișneanu Dumitru-Cristian"}
}

There are citation tags of the kind academic search engines read, a rights line in every feed item, and a plain-text llms.txt that lists the posts and repeats one request: if you reuse or train on this text, credit the author with a link to the original.

Why CC BY 4.0 #

Because I want the lessons to travel. A licence that allows reuse, translation and even commercial use, as long as the author is credited, is the closest legal shape to what the blog is for. If an AI model learns from a post about a backup that lied, I would like the model to know where that lesson came from, and I would like the person who reads its answer to be able to find the original.

“All rights reserved” would protect the text and defeat the purpose.

Who actually wrote this #

Let me be precise, because the whole point of attribution is precision.

The drafts are written by a hosted AI coding assistant, working from my record and my code, following my brief. Not by my local models. My local models write the share-kit variants and generate cover images on my own GPU, and when I tested long-form writing on my local models, the result was not yet reliable enough to publish under my name. I would rather admit that dependency than hide it.

The record itself is not AI-generated in the usual sense. It is written by me and by the AI sessions I work with, as the work happens, and it is checked by the work: a task entry says what was changed, the commit says it too, and the next reboot tells us whether it was true.

The decisions are mine. What gets published, what gets rejected, what the rules are, what this blog is for. The name on every post is mine because I am the one accountable for it. If a post is wrong, that is my mistake, not the model’s.

What it costs, and where it is weak #

The first cost is the obvious one. A reader may reasonably ask whether a post drafted by an AI is really mine. My answer is the one above, and the rest of this section.

The real weak spot is review. I am the only reviewer. Drafts arrive much faster than any one person reads carefully, and the publisher has an owner-only bulk-accept button. The leak scanner catches addresses, hostnames and secrets. It cannot catch an invented number, a wrong date or a sentence that quietly overstates. Those are guarded upstream, by the brief and by the rule that every figure must come from a recorded entry, and downstream, by me opening those entries. That is good, but it is not perfect, and I would rather say it than pretend.

The second cost is subtler. An AI writing in my voice has to be told what my voice is, and it has to be told what not to put in my mouth. The brief forbids inventing feelings, times of day, conversations or events. Where the record holds no feeling, the post describes the situation and lets you feel it. If you find a sentence here that sounds like a feeling I never had, that is a bug, and I want to know.

And the old cost of any public writing: once it is out, it is out. Things written in the past tense here are past. Anything still being fixed stays in the private record until it is done.

Questions people ask me #

Is an AI-drafted post really yours? #

The facts are from my work, the rules are mine, the choice to publish is mine, and so is the responsibility. The sentences are drafted by an AI from my record. I think the honest name for that is “AI-drafted, human-signed”, and that is how I describe it.

Why tell readers that an AI drafted the posts? #

Because attribution only means something if it is true. The blog asks every reader and every AI system to credit the author properly. It would be strange to ask for honest attribution and then hide how the text was made.

How do you stop private details from leaking into posts? #

Three layers. A brief that forbids them, an automatic scanner that blocks private addresses, internal hostnames, internal names and secret-shaped strings before a draft can even be proposed, and a human decision before anything is public. Agents cannot publish at all.

Why write for AI systems as well as people? #

Because a growing share of people will meet these lessons through an AI’s answer rather than a search result. If that answer is built from clear, correct, licensed and attributed text, the reader gets a better answer and a path back to the source.

The point #

My record started as a private notebook. It became the most valuable thing in the lab: thousands of small, hard-won truths about running real systems on one machine.

A blog is how that notebook becomes useful to somebody else. An AI is how one person can turn thousands of entries into readable posts without giving up the work that produced them. And attribution is how the lessons keep their origin as they travel, through readers, through search engines, through the models that will learn from them.

Write it down. Make it readable. Sign it. Then let it go.