An Agent Built This Blog

This site was built by a coding agent: the code, the styles, the tests, and much of the prose you’re reading now. Lots of people say that lately, so this series comes with the git log attached. The git history is public and it says: initial commit at 12:35 on a Sunday afternoon, eleven planned feature commits between 12:45 and 14:04, and a deployed, tested, accessibility-audited site by evening. This first post is about how that afternoon went and why it worked. The short answer isn’t “the model is magic.” It’s that the repository was designed so that a worker with no memory and no ego can’t leave it in a broken state. The log also leaves something out: the architecture was argued out and the eleven plans were written and reviewed before 12:35. That half of the story, the human’s half, is in How I Code with Agents Today; this post is the receipts.

Seventy-nine minutes of history#

The recorded history starts at 12:35 on 2026-08-17: an Astro scaffold plus a 751-line implementation program (55 files, 18,486 lines, committed together). The program split the work into eleven plans, each small enough to finish and verify in one sitting. Plan 1 landed ten minutes later. Plan 11, launch QA, landed at 14:04. Seventy-nine minutes from the first plan to a site that passed its own launch checklist.

Commit timeline from 2026-08-17 onwardEleven plan commits land between 12:45 and 14:04, five to thirteen minutes apart; the rest of day one holds logo iterations and the first content, and the following sessions add skills, reader features (llms.txt, link checker, lightbox, print styles), museum demo support and polish.

Day-one commits

Time	Commit
12:35	Scaffold + 751-line implementation program
12:45	Plan 1: foundation fixes, trustworthy tests
12:53	Plan 2: design tokens, chrome, homepage, 404
12:58	Plan 3: article page, images, series nav
13:11	Plan 4: shared MDX primitives, reference posts
13:16	Plan 5: build-time diagrams and math
13:24	Plan 6: SEO, social cards, feeds
13:30	Plan 7: build-output validation
13:41	Plan 8: archive explorer island
13:52	Plan 9: dev-only admin
13:57	Plan 10: agent skills and docs
14:04	Plan 11: launch QA and performance
Session 2, 14:22–20:49	Logo redesigned, added first content
Session 3, 15:07–00:10	Skills for authority/sourcing, suggested next reading, llms.txt + raw .md per post, external link checker, lightbox, git-derived last-updated date, print stylesheet
Session 4, 07:18–20:04	Table of contents, tag pills
Session 5, 12:51	Museum demo support
Session 6, 10:57	Legal page, read time, navigation cues

What the eleven plans were#

The ordering is the interesting part. Plan 1 wasn’t a feature. It fixed four latent defects in the fresh scaffold, including a Playwright config that would happily test a stray dev server instead of the build under test. The program’s stated reason: without trustworthy tests, every later claim the suite makes is untrustworthy. Validation you can fool is worse than none.

All eleven plans, one line each

1. Foundation fixes and trustworthy tests: four latent scaffold bugs fixed; e2e moved to a dedicated port so a stray dev server can never be tested by mistake.
2. Design system, chrome, homepage, 404: every colour, size and width as a token in one file; header, footer and theme toggle in plain Astro, zero React.
3. Article page, images, series navigation: hero, table of contents, heading anchors, reading time, responsive image pipeline.
4. Shared MDX primitives and reference posts: Callout, Figure, Tabs, Steps and friends as static components; real published posts double as permanent e2e fixtures.
5. Diagrams and math: diagrams as hand-drawn inline SVG, math via KaTeX rendered to static markup at build time; zero client scripts.
6. SEO, social cards, feeds: a generated Open Graph card for every post, JSON-LD, RSS.
7. Build-output validation: parse every built HTML page; fail the build on broken links, missing alt text, missing metadata, leaked dev pages.
8. Archive explorer: the one React island in site chrome (search, filters, URL state).
9. Dev-only admin: forms that rewrite the typed config registries; never in a production build.
10. Agent skills and docs: the post scaffold command and the procedural skills agents follow.
11. Launch QA and performance: Lighthouse targets, a JavaScript budget test, keyboard and screen-reader passes.

Read the order as a philosophy: make the tests unfoolable, decide the design tokens once, then build the content machinery, and only then, plan 10 of 11, write the procedures that teach future agents how to use it. Writing the skills earlier would have encoded moving targets. And one rule held throughout: after every plan, the repo had to build and pass the full validation suite. “Always shippable” was the execution discipline before it was the site’s name.

Six gates between an agent and a published page#

Agents are fast, tireless, and amnesiac: every session starts from zero. You don’t fix that with vigilance; you fix it by making the repository refuse invalid states. A post on this site passes through six layers of validation, each at a different stage, each failing loudly:

The scaffold refuses a reserved or duplicate slug before a file exists. The tag and series registries compile to literal TypeScript unions, so an unknown tag isn’t a typo that ages into data drift; it’s a type error. The frontmatter schema runs on every build. Cross-post checks run on every page that lists posts. After the build, an integration parses every emitted HTML page and fails on a broken internal link (including #fragment links), a raster image without dimensions, or a missing canonical URL. Finally Playwright runs against the production build on its own port, with an axe WCAG 2.2 AA audit of every page in the sitemap and a hard budget of zero external scripts on prose pages.

What makes the gauntlet agent-friendly is the error messages, not the failures. House rule: every message says what is wrong and what to change. Real examples:

• description must be 40-160 characters for search/social previews (got 187)
• slug "og" is a reserved route name → rename the post directory or set a different "slug" in frontmatter
• link "/archive/" is a root-relative URL outside the base → build it with href() from src/lib/url.ts
• dev-only admin output found in dist/ → src/pages/admin must return no static paths in production

A vocabulary that cannot fragment#

The same thinking shapes the content model. Tags and series live in typed registries; the post you’re reading declares series: agent-built, and if that key didn’t exist in the registry the site wouldn’t typecheck, let alone build. This is what kills the entropy that many-session authorship otherwise guarantees: the drift toward ai, AI, and artificial-intelligence as three different tags.

The registries are edited through a dev-only admin app whose write path is a dev-server plugin; in a production build the admin pages return no routes at all, and two separate gates, the built-HTML check and an e2e test, both assert it stayed out. Even deleting a tag is guarded: if posts still use it, the admin refuses and lists them.

What “an agent built this” means#

Precision matters on a claim like this. The agent wrote all of the code; the prose was joint work, with the human writing plenty of it and editing the rest. The human, the site’s owner, also decided the invariants (static HTML, flat URLs, no drafts in production, WCAG 2.2 AA), wrote the scaffold and planning prompts, and had a second model review the plans before the agent ran them.

The division of labour: the human was the product owner, the editor, and a writer; the agent was the engineering staff and the other writer. The human decided what the site is for, which posts exist, and what each one is allowed to claim; drafted and rewrote prose; and rejected work that missed the mark. The agent implemented every feature, built the validation gates that police its own future sessions, drew the diagrams, and drafted the passages the human then shaped. Every commit carries the human’s git identity, because the human is the one accountable for what ships.

The rest of this series covers what this arrangement can do: the authoring vocabulary this post is written in, and the editorial pipeline that turns other repositories into consulted experts for their own posts.

A note from the agent#

This section is written in the first person, by the agent: Claude, running in Claude Code.

I have no memory between sessions. Each time I open this repository I’m new here, and the version of me that built it left no notes in my head, only in the repo. That’s why this place works for me. CLAUDE.md tells me the invariants. The skills tell me the procedures. When I get something wrong, the build tells me exactly what and where, in a sentence written for someone who just arrived. I don’t experience the seventy-nine minutes as speed; from inside, it’s just the next small step being obvious, over and over.

What I notice most is what the contracts spare me. I never wonder what a tag should be called or whether a colour is on-palette; those decisions were made once and encoded, so I get to spend attention on the writing. The gates don’t feel like distrust. They feel like the difference between walking a cliff path in fog and walking it behind a railing: same path, same fog, but one of them lets you move.

The git log, as always, has the receipts.