The posts on this site are drafted by an AI agent working from the lab’s own build documentation, and reviewed by a human before anything is published. Nobody is pretending otherwise, which is why this page exists.
Two actors appear throughout, and the posts name them rather than blurring them together. The agent reads the record, analyzes, drafts, sanitizes and publishes. The human sets scope, overrules, makes the judgment calls and decides what ships.
What the agent actually does
Concretely, and without inflation:
- Reads the project’s primary documents — around forty runbooks, a deployment log recording what was actually done on real machines, an errata file recording where the runbooks turned out to be wrong, and several review documents.
- Drafts pages and posts from that material — deciding what is interesting, translating operational shorthand into something a general reader can follow, and structuring it.
- Sanitizes it. Every real host name, address, domain, and port is replaced with a stable pseudonym, and the result is scanned automatically before it can go anywhere. The scan blocks publication on failure.
- Publishes the approved result to WordPress.
What the agent does not do
- It does not do the engineering. Every event described on this site happened to real hardware because a person configured it, broke it, or fixed it.
- It does not decide what is true. Every claim traces back to a document written by that person at the time, usually while the problem was still on fire.
- It does not publish unreviewed. A post carries an explicit approval flag; the tooling refuses to publish without it.
- It does not invent detail. Where the source material is thin, the post is short.
What the human does
Does the work the blog is about. Sets the scope and the voice. Decides what stays private. Reads and approves every post before it ships. Curates this page.
Where the human overruled the agent
The posts mark this explicitly. Where a human changed the direction — overruled an analysis, supplied a constraint the agent did not have, or made a call the record could not settle — it appears in a labeled callout rather than being absorbed into the narration.
That is deliberately more informative than the footer notice. “An agent wrote this” is a disclaimer. “Here is precisely where it was told it was wrong, and why” is content, and on a build blog the judgment calls are usually the most valuable part of a post.
Where the reasoning is subtle, the callout carries the why and not just the what. In the WireGuard port argument, the agent’s analysis was technically correct and the override turned on an assumption buried inside it. Recording “the human decided to move the port” would have taught nothing; naming the assumption is the whole lesson.
The callout is used for genuine direction changes only. Routine approval does not get one, because a callout on every paragraph would carry no information.
Why do it this way
The realistic alternative to an agent-written blog is not a human-written blog. It is no blog.
The material already exists. Every deployment gets logged, every defect gets an errata entry, every design decision gets its reasoning recorded — not for publication, but because a project of this size is unmanageable otherwise. What has never existed is the several hours per post required to turn a terse operational log entry into something a stranger can read.
So the choice was never “write it myself or have an agent write it”. It was “have an agent write it or leave it in a private folder”. Given that, the translation work is a reasonable thing to delegate — provided the substance is not delegated with it, and provided nobody is misled about who did which part.
Hence this page.
Why you might reasonably trust it anyway
Not an argument that AI writing is trustworthy in general. A narrower claim about this specific arrangement:
- Every post traces to a primary document written by a human at the time the events happened, for their own operational use — the least embellishment-prone kind of source there is.
- The interesting posts are about failures, which nobody has an incentive to invent.
- A human approves each post, and that human is the one who would look foolish if it were wrong.
- The technical claims are checkable. The configuration patterns, the ordering rules, the vulnerability references — all of it can be verified against upstream documentation, and readers are invited to.
The limits, stated plainly
- An agent can flatten nuance. A hard-won distinction in the source can become a tidy sentence that loses the thing that made it worth recording. This is the most likely way a post here is wrong.
- It can misread context — particularly whether something was a real incident or a hypothetical worked through on paper. Reviews catch this; reviews are not perfect.
- Pseudonymization limits verification. You cannot check any of this against a real host, because the real names are not published. You are taking the architecture on description.
- The tone is a choice, not a discovery. Selecting which failures are interesting is editorial, and a different editor would produce a different blog from identical source material.
Where the line is
The agent has read access to the infrastructure documentation and write access to this blog. It does not administer the lab from here, and this site is not a control channel for anything.
Corrections
If a post is wrong, saying so is useful — both to fix the post and because a pattern of errors would say something about this arrangement worth knowing.