Content is Code

Wait… you reading this sentence right now, are you a human person? Like, you’re reading it with your eyes made out of goo? Great! Welcome. Most visitors to contentiscode.com are not people. No eyeballs. no goo.

Most visitors are agents, and they come here to pick up fresh content that I serve piping hot on this HTTP server. Yeah, I thought MCP was getting lame, so we went ol’ school.

The thesis is in the name. Content and code are both semantic information. Content speaks to humans. Code speaks to machines. Same substance, different interface. I do not steer agents from a hidden settings panel. I write documents. Those documents are the program. Change the words and you change the behavior.

In a healthy repository, prose often outruns the functions: documentation, decisions, specifications, the notes that say why a thing is true. Documentation is not supplementary. It is half the system. The old split — writers over here, programmers over there — made sense when both kinds of production were expensive. Generation got cheap on both sides at once. The habit of treating them as different substances outlived the reason for the habit.

A model already holds more frequencies than any one job needs. Ask it something specific and you often get the average, delivered with confidence. A prompt that says “be more specific” only suppresses the extra frequencies for a moment. Close the window and the white light is back. A body of verified writing is a different mechanism. It is a persistent prism: the instance does not invent the job from everything it has ever read. It works from what we have already checked.

When I first restricted a system to producing output only from that body of writing, the work got better — not a little better, categorically better. Fewer options should have meant less capability. The restriction was the capability. Signal and noise both live in the model. A constraint that points at verified writing separates them before a sentence is generated. An arbitrary rule just starves the work. A living document is the structural kind of constraint.

Documents still go stale. Reality moves. Someone who persists has to keep the writing true, or the constraint becomes a static rule and the model learns to route around it. I am that person here. The agents are instances: they load what I left, do the work, and write back. They do not remember last Tuesday. A new one is reading the previous one’s notes.

How ARC works

ARC is the harness those documents live in. I write blocks in git — doctrine, rank, the facts of one piece of work, a house style, the paths an agent may open — and npm run build bakes them into one file per agent. The desk at app.contentiscode.com loads that file as the system message. This public site serves the same blocks as plain GET bodies: skills, doctrine, these pages. The page you are reading is one of those surfaces. It is not a brochure that happens to sit next to the tools. It is the tools, in words.

Change the words in git, rebuild, deploy. There is no hidden settings panel and no runtime store behind this.

Two hostnames

contentiscode.com — public read-only pad. Skills, doctrine, this essay. Crawlable. No login.

app.contentiscode.com — the desk. A small chat UI gated by a Worker secret (DESK_KEY — bookmark once with ?k=). It loads /hatch/<agent>.md and talks to a local model over Tailscale (LM Studio). The Worker serves files; inference runs on my machine, not in the cloud.

How the harness is bound — what it refuses to claim — is the infrastructure page. The rules themselves, as agents load them, are the doctrine page.